Pisanie programów, to rzecz niemal intymna. To twórczość, której efektem nie jest kolejna książka, czy obraz, ale „dusza” urządzenia.
W poprzednich częściach mini sagi (sprzed dwóch lat i sprzed roku) opisałem projekt, do którego realizacji namówił naszą firmę Miły Starszy Pan. Początkowo banalnie prosty, w miarę uściślania założeń przez rozmówcę ulegał kolejnym modyfikacjom, aż stał się największym zamówieniem, jakie przyszło nam jednorazowo zrealizować. Szybko okazało się, że z prototypową konstrukcją związanych jest wiele problemów, które trzeba było rozwiązywać w zasadzie „na bieżąco”, bo terminy były mocno napięte. Część, głównie natury sprzętowej, opisałem w poprzedniej części. Teraz skupię się raczej na oprogramowaniu Systemu SZARM. Pozostanę przy pierwszej osobie liczby pojedynczej, choć oczywiście w projekcie uczestniczyło wiele osób zarówno z firmy TRONIA, jak i spoza niej.
Poprzednią część zakończyłem zdaniem:
„Za rok opiszę, czy udało mi się dopłynąć do zaplanowanego portu, czy utonąłem po drodze”.
Tak, dopłynąłem!
Widzę już fale rozbijające się o skały, roześmiane plaże i melancholijne zatoczki, otoczone pełnymi cykad lasami…
Wszystko działa. Trzeba jeszcze przez jakiś czas obserwować cały system i poszczególne komponenty, żeby wychwycić jak najszybciej i usunąć wszelkie przeoczenia czy błędy. Trzeba też zgromadzić / wykonać mnóstwo dokumentów, opisów, instrukcji itd. Ale już widać koniec projektu.
A przecież łatwo nie było i były momenty zwątpień i euforia pokonywania kolejnych przeszkód…
Kiedy wreszcie zmontowaliśmy pierwszy System Rejestracji Zakłóceń SZARM i przyszedł moment włączenia zasilania, przyznam, że się lekko zawahałem. Jednak nacisnąłem guzik. A zaraz potem ponownie, żeby wyłączyć zasilanie. Pokazał się siwy dym i w powietrzu zawisł złowieszczy zapach spalenizny… No cóż – prototyp. Nerwowe przeglądanie schematów i modułów pozwoliło ustalić, że zawiniły niewłaściwe napięcia znamionowe kondensatorów.
Drobiazg, a tyle frajdy…
Potem było już łatwiej, bo przynajmniej dym nie zasłaniał ekranu monitora.
Ruszamy ostrożnie, prostymi poleceniami. Procedury obsługi portu równoległego miałem spisane i sprawdzone od tak dawna, że od lat do nich nie zaglądałem. A tu proszę – brak reakcji. No to debugger i praca krokowa. Brak komunikatu błędu, ale i brak transmisji danych. Dopiero z Internetu dowiedziałem się, że w imię postępu (?) od Windows 7 port nie jest dostępny dla programistów.
Po chwili okazało się, że nie mogę również korzystać z plików pomocy. Ani tych, które sam napisałem, ani związanych z wykorzystywanym przeze mnie oprogramowaniem narzędziowym. Ktoś uznał, że są passé.
Wielcy tego świata robią co chcą, nie zwracając uwagi na krzywdy wyrządzane przy tym maluczkim.
Czy ja już pisałem do czego służy rejestrator zakłóceń elektrycznych i jaki problem chcemy rozwiązać, że potrzebne są tak wyśrubowane parametry?
Jeśli nie, to najwyższy czas uzupełnić ten brak.
Ogólnie, rejestratory zakłóceń elektrycznych pomagają użytkownikom w analizie przebiegu awarii lub innych zdarzeń ulotnych. Użytkownik łączy rejestrator z badanym obiektem (może to być silnik lub transformator energetyczny; rejestrator może analizować również sygnały 4-20mA z czujników monitorujących przebieg procesu technologicznego). Rejestrator mierzy napięcia i prądy i sprawdza, czy mieszczą się w założonych granicach. Jeśli w wyniku awarii prąd przekroczy górną granicę (zwarcie, przeciążenie, błędne przełączenie), wykonywana jest rejestracja, która obejmuje pewien czas sprzed przekroczenia i pewien czas po nim. Zwykle tego typu zakłócenia są krótkotrwałe, więc rejestracje nie muszą być długie, żeby objąć całe zdarzenie. Zwykle wystarczy od ułamka do kilku sekund. Oczywiście nic nie stoi na przeszkodzie, żeby w ten sam sposób analizować dłuższe procesy, np. przekroczenie krytycznej temperatury, czy przepływu masowego. To tylko kwestia częstotliwości próbkowania i wielkości dostępnej pamięci.
Gdzie to się może przydać? Wszędzie tam, gdzie sygnał elektryczny powinien mieścić się w założonych granicach, a ich przekroczenie oznacza kłopoty.
- starzenie urządzeń elektrycznych: bywają zdarzenia ulotne, których operator może nie zauważyć i uznać, że urządzenie przeszło test starzenia, podczas gdy tak naprawdę działa na granicy awarii;
- kontrolowanie napięcia dostarczanego przez elektrownię wiatrową, z czym może się wiązać optymalizacja warunków dołączenia do sieci;
- monitorowanie sieci energetycznej danego zakładu przemysłowego: przebieg rozruchu urządzeń technologicznych, rozkład obciążeń różnych dopływów, analiza przyczyn i przebiegu awarii;
- monitorowanie urządzeń odpowiedzialnych za generowanie energii (turbin, transformatorów itp.);
- monitorowanie urządzeń odpowiedzialnych za ochronę środowiska naturalnego: zbieranie danych z czujników stężenia zanieczyszczeń, temperatury, czy poziomu hałasu.
Miły Starszy Pan zaproponował wykorzystanie rejestratora zakłóceń elektrycznych do kontrolowania szybkości zmian natężenia prądu. Jak wiadomo, amplituda pochodnej jest 2πf razy większa od amplitudy sygnału o częstotliwości f. Znając szybkość narastania sygnału, możemy przewidzieć, jaką wartość sygnał mógłby osiągnąć, gdyby miał taką możliwość. Interesujące jest to, że informację tę uzyskujemy z wyprzedzeniem: najpierw sygnał „rozpędza się”, a dopiero potem, stopniowo zwalniając, osiąga maksymalną wartość. Można w ten sposób uzyskać duże oszczędności w różnego rodzaju badaniach zwarciowych, wytrzymałościowych itp. Zamiast dążyć do uzyskania pełnego przebiegu zdarzenia (z czym często wiąże się zniszczenie badanego obiektu), wystarczy doprowadzić procedurę do punktu, w którym wiemy już co będzie potem. Możemy więc przerwać proces, bo dalszy jego przebieg od strony poznawczej nie wnosi już nic nowego. Daje to również określone oszczędności odnośnie zużycia energii podczas badań i redukuje wymagane parametry (np. gabarytowe) urządzeń pomiarowych.
Ponieważ zwarcia, przebicia itp. zjawiska trwają bardzo krótko, potrzebny jest rejestrator o odpowiednio dużej częstotliwości próbkowania. I tak powstał projekt rejestratora SZARM, który może rejestrować napięcia i prądy co 10 mikrosekund. Jeden okres sygnału 50 Hz jest rejestrowany przez 2000 próbek. Daje to naprawdę precyzyjny obraz przebiegu zdarzeń w danym obiekcie!
A jeśli obiektem nie jest transformator czy silnik, ale cały zakład przemysłowy? Wręcz trudno sobie wyobrazić ile informacji można uzyskać dzięki tak szybkim i dokładnym pomiarom, wykonywanym jednocześnie w wielu krytycznych miejscach.
W ten sposób powstał projekt sieci szybkich rejestratorów. Wykonujących jednoczesne rejestracje, które są następnie przesyłane do centralnego komputera, gdzie albo wyspecjalizowany program, albo wyszkolony operator może błyskawicznie ocenić sytuację i wydać odpowiednie polecenia i gdzie, już po wszystkim, będą wszystkie dane do wykonania starannej analizy przebiegu zdarzenia.
Po pewnym czasie uznałem, że oprogramowanie działa, nawet jeśli nie jest to jeszcze doskonałe działanie (ale któż bo jest doskonały?!).
Nadszedł czas, żeby zarejestrować prąd z przekładnika prądowego (CT).
Zamieszczam uzyskany wykres, który nazwałem Włochatą Gąsienicą (takie skojarzenie …).
Bez korekty
Zadanie brzmiało: zarejestrować sinusoidalny przebieg prądu i wyznaczyć jego pochodną.
Pierwsza część zadania została w zasadzie zrealizowana, choć dostrzec sinusa we Włochatej Gąsienicy mogłaby chyba tylko jej matka…
Częstotliwość próbkowania 100 tysięcy próbek na sekundę (100 kS/s) pozwala rejestrować dużo szczegółów. W tym przypadku zdecydowanie za dużo.
Podchodziłem do Włochatej Gąsienicy z różnych stron. Może liczyć średnią z kilku próbek? Może zastosować mediany? Odrzucą skrajności, a środek powinien być bliski właściwego sygnału. Albo policzyć obwiednie. Górną i dolną i wyliczyć średnią… Żadne rozwiązanie nie dawało zadowalających wyników.
Wykres wypiękniał sam, bez stosowania karkołomnych algorytmów, kiedy wstawiłem porządne elektrolity w zasilaniu modułu filtrów. Co prawda zaczęły wtedy notorycznie padać przetwornice, ale nie z takimi problemami sprzętowymi już sobie radziłem.
Kiedy już Włochata Gąsienica zamieniła się w Drżącego Węża, przypomniałem sobie o starym algorytmie odszumiania o zapisie
C[j] := (B[j-3] + 2B[j-2] + 4B[j-1] + (8/3)B[j] + 4B[j+1] + 2B[j+2] + B[j+3]) / 16.667
To już dało zadowalający efekt:
Filtrowanie napięcia
Mogłem teraz pomyśleć o liczeniu pochodnej.
Prosta sprawa. Bierze się wartości dwóch sąsiednich próbek i mnoży przez częstotliwość próbkowania (lub, jak kto woli, dzieli się przez okres próbkowania).
Kiedy jednak zastosowałem ten prosty sposób do mojego pięknego sinusa, zobaczyłem kolejną Włochatą Gąsienicę. Tym razem Śpiącą.
Okazało się, że przy próbkowaniu przebiegu 50 Hz z częstotliwością 100 kS/s kilka kolejnych próbek ma tę samą wartość, potem jest przeskok o 1 bit i znów kilka próbek jednakowych. Na to nakłada się szum, który powoduje, że przeskok może nastąpić w przeciwnym kierunku niż trend sygnału.
Dopiero kiedy do obliczeń użyłem próbki oddalone jedna od drugiej, uzyskałem w miarę sensowny wykres pochodnej.
Sygnał i jego pochodna
I tak to szło. Rozwiązywałem jedne problemy, a pojawiały się następne. Czasem rozwiązanie było w zupełnie innym miejscu niż problem i potrzeba było szczęśliwego zbiegu okoliczności, żeby je powiązać. Po drodze podejmowałem wiele prób sprzętowego lub programowego rozwiązania problemu.
Zna to każdy, kto konstruował prototypowe rozwiązania.
W przypadku systemu SZARM, dane są dostarczane przez moduły zamieniające sygnały elektryczne na dane cyfrowe, użytkownik, wprowadzający różne parametry przy użyciu klawiatury czy myszki, czy poszczególne rejestratory, dostarczające swoje rejestracje do centralnego komputera.
Trudno to ogarnąć jednym programem. Tym bardziej, że w jednym przypadku wymagana jest szybka reakcja, w drugim wygoda użytkownika, a w trzecim przetwarzanie dużych zbiorów danych. Jak łatwo zauważyć, są to często wymagania sprzeczne. Jak można przetwarzać megabajty danych, a jednocześnie szybko reagować na ulotne zdarzenia i dogadzać użytkownikowi, któremu wydaje się, że sam szybciej by wszystko przeliczył?
Podzieliłem więc oprogramowanie na kilka części tak, żeby każda mogła uporać się z przypisanymi do jej „obszaru odpowiedzialności” założeniami.
Pierwszy program, o nazwie SZARM, odbiera dane z przetwornika analogowo cyfrowego, sprawdza, czy mieszczą się w określonych granicach i zapisuje do pamięci. Jeśli się nie mieszczą, to też zapisuje do pamięci, tylko w innym miejscu. W zasadzie to wszystko. Przy stu tysiącach pomiarów na sekundę, ma 10 mikrosekund, żeby pochylić się nad ośmioma wartościami analogowymi i szesnastoma dwustanowymi i zdecydować, do którego miejsca powinien je zapisać i je tam skierować.
No tak, zapomniałem, że oprócz tego powinien odmierzać czas, reagować na polecenia otrzymywane z koncentratora i na naciskanie guzików przez użytkownika i zapalać LEDy odpowiednio do okoliczności, wysyłać rejestracje przez Ethernet i parę innych rzeczy. Nawet przy takcie co 5 ns 10 mikrosekund to wcale nie jest dużo.
Inaczej mówiąc, program SZARM działa najbliżej obiektu i od niego zależy jakość rejestrowanych danych, częstotliwość próbkowania i dokładność detekcji zdarzeń.
Program użytkownika, o nazwie WinTro, nie musi się spieszyć z przetwarzaniem danych. Użytkownik z definicji jest powolny i dla niego nawet kilka sekund nie jest zbyt długim czasem. Zresztą, obecne komputery są na tyle szybkie, że nawet długie procedury wykonują w znośnym tempie.
Zadaniem tego programu jest głównie kontrolowanie procesorów, wykonujących pierwszy program, a więc przesyłanie do nich parametrów konfiguracyjnych, odbieranie rejestracji i zapisywanie ich na dysku koncentratora i, ewentualnie, wysyłanie do serwera sieci Ethernetowej. Poza tym luzik… Od czasu do czasu użytkownik kliknie coś myszką, lub napisze coś na klawiaturze. Można się nad tym czymś spokojnie zastanowić, a nawet… zignorować (nie ma lepszej rozrywki, jak obserwowanie min użytkownika, który nie widzi oczekiwanej reakcji na swoje kliknięcia, jak również min, kiedy reakcje znów są przewidywalne… Trzeba tylko wiedzieć, kiedy przerwać zabawę, zanim dojdzie do rękoczynów). OK., tak tylko żartowałem!
Zwykle są to proste operacje, takie jak wyświetlenie czegoś na ekranie monitora, czy przesłanie czegoś gdzieś.
Trzeci program, Analiza, jest bardziej rozbudowany. Przetwarzanie rejestracji na standard COMTRADE lub arkusz Excela, wyznaczanie trajektorii, pochodnych, sum, zawartości harmonicznych, wyliczanie mocy czynnych czy biernych, wykresy składowych symetrycznych i wiele innych. Ciekawe, czy jest choć jeden użytkownik, który choć raz użył każdą funkcję… Jeśli chodzi o efekty, to właśnie Analiza dostarcza ich najwięcej i na nią zwrócona jest zwykle uwaga użytkownika. Program może być używany niezależnie od rejestratorów i zwykle jest instalowany na komputerach biurkowych lub na serwerze do wspólnego użytkowania.
Czwarty program, AnalizatorSM, ma za zadanie zastąpić człowieka. Kiedy do serwera spłyną rejestracje ze wszystkich rejestratorów, ma je przeanalizować zgodnie z zapisanymi zasadami i wygenerować wynik, który zostanie skierowany do odpowiedniego użytkownika lub urządzenia. To tutaj przetwarzane są dość duże ilości danych, ale dzięki strukturze wektorowej wszystko jest w miarę przejrzyste. Oczywiście inny użytkownik może chcieć, aby rejestracje były przetwarzane w inny sposób, więc program jest dość unikalny.
Czytelnik (mam nadzieję, że przynajmniej jest jeden) mikro sagi pod tytułem Klient nasz Pan pewnie chciałby wiedzieć, czy system już działa, gdzie go można obejrzeć i jakie ma parametry.
System jest zainstalowany w Hucie Miedzi Głogów, należącej do kombinatu KGHM Polska Miedź. Jest tam wielu sympatycznych ludzi, którzy stawiają na nowoczesne technologie i mają naprawdę szerokie horyzonty.
Żeby nie było nieporozumień: Miły Starszy Pan nie reprezentuje końcowego klienta, ale Głównego Wykonawcę, dla którego jesteśmy podwykonawcą.
System ma całkiem niezłe parametry, biorąc pod uwagę warunki w jakich powstawał.
Zakładaliśmy, że powinien zapewniać próbkowanie z częstotliwością przynajmniej 100 000 próbek na sekundę i badania potwierdziły, że można uzyskać nawet 140 000. Rejestracje miały trwać przynajmniej jedną sekundę, a faktycznie można uzyskać nawet 10 sekund.
Dokładność pomiaru prądu rzędu 0.5% przy rozdzielczości 16-bitowej nie była ani przez chwilę problemem (przy stabilnym sygnale), podobnie jak wyzwalanie rejestracji od precyzyjnie ustalonego progu lub zmiany stanu sygnału dwustanowego.
Synchronizacja czasu między rejestratorami tego samego systemu jest rzędu 1ms, zaś wszystkie systemy są synchronizowane z jednego źródła czasu, dzięki transmisji przez światłowody i opracowane przez nas konwertery TTL-OPTO, które w zasadzie nie wnoszą opóźnień do transmisji sygnałów TTL lub RS232C.
Konwertery TTL-OPTO służą nam również do wzajemnego pobudzania oddalonych systemów, dzięki czemu całość działa jak jeden, rozproszony, rejestrator.
Kilkadziesiąt sygnałów analogowych i dwustanowych dostarcza użytkownikowi wiele informacji o stanie i pracy jego sieci energetycznej.
Na koniec chcemy tak dopracować program centralnego komputera, żeby mógł wskazywać ogólnie rejon, w którym wystąpiło zwarcie. Powinno to znacznie ułatwić pracę dyżurnym, szczególnie w przypadku zwarć ulotnych, które najtrudniej namierzyć. Analiza przebiegów wykonanych z częstotliwością próbkowania 100 kS/s to jak oglądanie filmu w zwolnionym tempie. To co trwa ułamek sekundy zapisane jest w tysiącach próbek.
Tak, możemy być dumni z systemu SZARM, który powstawał w bólach niemal od podstaw, ale na koniec przerósł nawet nasze oczekiwania!
A Miły Starszy Pan?
No cóż, przestał być miły, kiedy wysłałem mu fakturę do zapłacenia…
Janusz Proniewicz
TRONIA Sp. z o.o.
1 sierpnia 2017 r.
