HES-NG – nowoczesna i otwarta platforma akwizycji danych

Wychodząc naprzeciw nowym wyzwaniom regulacyjnym innogy Stoen Operator oraz innogy Polska IT Support stworzyły autorski system akwizycji danych pomiarowych – HES New Generation.

Każdy operator systemu dystrybucyjnego stoi przed tym samym wyzwaniem: jak zarządzić procesem pozyskiwania danych pomiarowych w sposób maksymalnie efektywny? Nieliczne, istniejące na rynku systemów do obsługi sektora Utilities, rozwiązania informatyczne stworzone do realizacji zadań akwizycji, obarczone są wysokim wskaźnikiem TCO (Total Cost of Ownership) lub mają nadmiarową z punktu widzenia OSD funkcjonalność, która jest swoistym narzutem obniżającym wydajność systemu, bądź też utrudniającą jego modyfikację. Doświadczenia zdobyte w trakcie eksploatacji i utrzymania systemów skłoniły współpracujących na co dzień informatyków z innogy Polska IT Support oraz specjalistów systemów pomiarowych innogy Stoen Operator do podjęcia próby uruchomienia własnego systemu akwizycji danych.

W założeniach system ten miał posiadać następujące główne cechy:

  • własność specyfiki rozwiązania (projekt, architektura, kod źródłowy) pozostaje w dyspozycji zamawiającego,
  • realizuje wyłącznie trzy zadania: akwizycja danych pomiarowych, ich udostępnianie do nadrzędnego systemu zainteresowanego nimi oraz sterowanie urządzeniami pomiarowymi (zmiana taryfy, sterowanie stycznikiem czy też ogranicznikiem mocy etc.),
  • możliwość nieograniczonego skalowania,
  • modułowa architektura – awaria jednego komponentu nie może wpływać na pracę pozostałych,
  • zapewniać automatyzację realizowanych procesów.

Wszystkie wyszczególnione założenia początkowe spełniono, a w trakcie realizacji projektu niektóre z nich twórczo rozwinięto.

Podejście projektowe

Pierwsze pomysły wytworzenia systemu akwizycji własnymi siłami pojawiły się w zespole IT nieco przypadkiem. Rzucone luźno w trakcie rozmowy hasło „zróbmy to sami!” po pewnym czasie przerodziło się jednak w zupełnie realną próbę zderzenia się z codziennością, jaka towarzyszy specjalistom innogy Polska IT Support przy utrzymaniu i rozwoju obecnie eksploatowanych systemów.

Początkowo nacisk położono na próbę wytworzenia prototypu systemu (ang. POC, skrót od Proof-Of-Concept). W założeniach POC miał zapewnić następującą funkcjonalność:

  • wytworzenie modułu komunikacji DLMS,
  • odczyt za jego pomocą wartości chwilowych oraz profilowych z jednego z eksploatowanych przez innogy Stoen Operator typów liczników energii elektrycznej,
  • zapis odczytanych wartości do bazy danych.

Całość rozwiązania zawierała mechanizmy komunikacji z serwerem kolejek, zapewniając asynchroniczną pracę interfejsu przyjmującego zlecenia akwizycji z modułem aplikacji, który je realizował.

Trwająca kilka tygodni realizacja POC zakończyła się sukcesem, zarówno w obszarze technicznym, jak i finansowym. Udało się bowiem potwierdzić, że w długim czasie system ma szanse stać się rozwiązaniem, które w wyważony sposób może łączyć koszty rozwojowe i operacyjne, zaś zespół projektowy IT uzyskał niezbędną wiedzę, którą mógł zaprezentować kolegom z innogy Stoen Operator. Prezentacja rezultatu prac zaowocowała uruchomieniem projektu rozwojowego, który za zadanie postawił sobie zaprojektowanie, wytworzenie i uruchomienie docelowego systemu akwizycji, realizującego postawione przed nim wyżej wymienione cele. Do współpracy zaproszono programistów z zewnętrznego software house’u, którzy wnieśli niezbędne kompetencje deweloperskie.

Projekt rozwiązania

HES New Generation wytworzono w architekturze mikroserwisów. Kilka współpracujących ze sobą usług przeznaczonych do realizacji części funkcjonalności tworzy nowoczesny i wydajny system akwizycji danych, który od samego początku był projektowany jako autonomiczny, techniczny komponent aplikacyjny, minimalizujący konieczność ręcznej ingerencji operatora w jego codzienną pracę. Wydzielone komponenty, pracujące niezależnie od siebie, zapewniają:

  • elastycznie konfigurowanego zakresu pozyskiwania danych pomiarowych z liczników energii elektrycznej oraz sterowania licznikami,
  • integrację z systemami IT w obszarze przyjmowania informacji o zmianach na instalacjach klienckich – system automatycznie otrzymuje informacje o montażach, demontażach czy też wymianach liczników,
  • integrację z systemami klasy MDMS na polu przekazywania danych odczytowych do ich późniejszego wykorzystania, np. w procesie billingowym,
  • integrację z systemami IT automatycznego pozyskiwania informacji o zleceniach OT (np. zdalnej zmiany taryfy),
  • dostarczenie niezbędnej, centralnie zarządzanej konfiguracji dla wszystkich modułów systemu,
  • zarządzanie realizacją zadań harmonogramowych,
  • rejestrację zdarzeń w systemie dla celów późniejszej analizy jego pracy.

Całość spina uproszczony interfejs użytkownika, zapewniający możliwość ręcznej konfiguracji urządzeń w systemie, realizacji odczytów na żądanie (zarówno wartości chwilowych, jak i profili danych), generowania i przeglądania raportów oraz dostarczający panelu wykresów z syntetycznymi informacjami dotyczącymi pracy systemu. Aplikację zaprojektowano tak, aby szczególne różnice w budowie urządzeń pomiarowych nie miały wpływu na dane, które z nich pozyskuje. W tym celu zaimplementowano warstwę abstrakcji biznesowej, która zakłada, że HES-NG pracuje opierając się na jednolitym modelu obiektów biznesowych, a wszystkie dane pozyskiwane z różnego typu urządzeń dostarczanych przez rozmaitych producentów są w trakcie odczytu przekształcane i zapisywane do jednolitego modelu danych. Zapewnia to potencjalną możliwość obsługi i integracji w systemie przeróżnych, nawet najbardziej „egzotycznych” typów urządzeń. Na szczególną uwagę zasługuje komponent realizujący zadanie komunikacji z licznikiem. W zaprojektowanej architekturze może on zostać dowolnie, niemal w nieskończoność skalowany. Zapewnia to, przy dostarczeniu odpowiednich zasobów sprzętowych, możliwość realizacji w systemie zadań odczytu dowolnej liczby liczników w założonym czasie. Każda instancja takiego modułu jest dodatkowo parametryzowana liczbą wątków, które obsługują zadania w sposób równoległy. Posłużmy się następującym przykładem:

  • liczba wątków pracujących w ramach pojedynczej instancji modułu komunikacji – 150.
  • liczba instancji modułów komunikacji – 8.

Z prostego wyliczenia wynika, że jednoczesna liczba urządzeń, dla których wykonywane są równolegle zadania akwizycyjne wynosi 150 * 8 = 1200.
Jeżeli okaże się, że zadania są realizowane zbyt wolno w stosunku do potrzeb, możemy zwiększyć liczbę: wątków w ramach pojedynczej instancji modułu komunikacji, instancji tych modułów – oczywiście przy założeniu, że wykorzystywana do uruchomienia systemu infrastruktura serwerowa wytrzyma zwiększone obciążenie – lub poddać modyfikacji oba te parametry naraz. Gdy jednak nie będzie możliwości rozszerzenia wydajności systemu w ten sposób, można uzupełnić zasoby sprzętowe o następny serwer i uruchomić na nim kolejne instancje modułów komunikacyjnych, zwiększając w ten sposób pojemność systemu (skalowanie poziome).

Baza danych pomiarowych

W trakcie prac rozwojowych pojawiło się pytanie: w jaki sposób zaadresować problem różnorodności konfiguracyjnej danych profilowych? Profile obciążenia, konfigurowane przez dostawców liczników w procesie produkcyjnym (choć nie tylko: taka konfiguracja może być również wykonana przez służby techniczne OSD), okazały się na tyle różne, że szybko pytanie zmieniło swoją treść: w jaki sposób zapewnić możliwość elastycznego zapisu dowolnie zdefiniowanego zestawu danych bez degradacji wydajności systemu?

Odpowiedź pojawiła się wraz z propozycją użycia bazy danych typu NoSQL. Odejście od modelu relacyjnego otworzyło możliwości elastycznego podejścia do zapisu danych w postaci dokumentów kolekcji bazy MongoDB. Dokument reprezentuje pojedynczy zestaw danych z tym samym znacznikiem czasowym – innymi słowy przechowuje pojedynczy rekord profilu danych lub zestaw wartości chwilowych odczytanych w tym samym momencie. W ten sposób system potrafi przetwarzać dane profilowe z dowolnym okresem rejestracji: 15-, 60-, 10-minutowym oraz innymi. Dokumenty te mają wspólne atrybuty, wśród których wyróżniamy daty pozyskania odczytu, zatrzaśnięcia odczytu czy też dane identyfikacyjne licznika. Same wartości odczytanych rejestrów są przechowywane w postaci listy o zmiennej liczbie elementów; jesteśmy tym samym w stanie, pod postacią jednego dokumentu, przechowywać i przetwarzać dowolnie zdefiniowane profile danych, niezależnie od tego, czy posiadają w swojej definicji 2, 5 czy 13 różnych rejestrów. Odczyt czy przetwarzanie różnej liczby danych trwa wówczas przez porównywalny okres.

Środowisko pracy systemu

Poszczególne moduły systemu są uruchamiane jako kontenery w środowisku Docker Engine. Samo środowisko jest zbudowane jako klaster Kubernetes, którego zarządzanie wspiera manager Rancher. Poszczególne moduły, o ile system tego wymaga, mogą być skalowane zgodnie z potrzebami biznesowymi dotyczącymi przetwarzania zadań akwizycji danych.

Architektura mikroserwisów umożliwia w prosty sposób modyfikację odpowiednich fragmentów całości, jak również rozszerzanie systemu o nowe moduły. Zarządzanie zmianami w systemie zautomatyzowane jest zgodnie z dobrymi praktykami procesów CI/CD (Continuous Integration/Continuous Delivery). Kod rozwiązania zarządzany jest przez lokalne repozytorium GitLab, procesy budowania paczek instalacyjnych oraz dostarczania obrazów kontenerów realizowane są przez dedykowany proces gitlab-runner i umieszczane w prywatnym repozytorium, skąd trafiają na odpowiednie środowiska za pomocą managera Helm. Tak zdefiniowany proces zapewnia relatywnie niski czas TTM (Time-To-Market) przy wdrażaniu zmian na środowisko produkcyjne.

Teraźniejszość i plany na przyszłość

Projekt miał na celu uruchomienie akwizycji dla kilku typów urządzeń, które komunikują się opierając na protokole DLMS i modelu obiektów COSEM, zdefiniowanym w normie PL-EN 62056-61. System realizuje to zadanie opierając się na jednej, generycznej instancji drivera DLMS obsługującego oba typy interfejsów: WRAPPER oraz HDLC, wszystkie tryby uwierzytelnienia oraz szyfrowania transmisji. Konfiguracja zapewniana jest na poziomie typu urządzenia oraz każdego licznika z osobna – daje to możliwość niezależnego testowania różnych konfiguracji dla urządzeń tego samego typu. Architektura, uwzględniająca wspomnianą warstwę abstrakcji biznesowej, pozwala jednak w prosty sposób uzupełniać system o drivery dla urządzeń komunikujących się w inny sposób, np. opierając się na protokole IEC. Otwarte wydają się również kolejne ścieżki rozwoju: łatwo wyobrazić sobie modyfikację implementującą mechanizmy komunikacji z urządzeniami innego rodzaju, np. falownikami instalacji fotowoltaicznych czy koncentratorami danych. Przy relatywnie niewielkim nakładzie pracy system może służyć także jako narzędzie akwizycji danych dla innych mediów, np. wody czy gazu.

Podsumowanie

Podejście, zakładające główny udział w projekcie wewnętrznych zasobów IT innogy, wsparte merytoryczną wiedzą specjalistów innogy Stoen Operator, jak również kompetencjami programistycznymi partnera – firmy Execon, zmaterializowało się w postaci pozbawionego ograniczeń innych rozwiązań, łatwego w zarządzaniu, skalowalnego i przede wszystkim bardzo wydajnego systemu informatycznego, ściśle dopasowanego do potrzeb OSD, stworzonego do realizacji precyzyjnie zdefiniowanego zakresu funkcjonalnego. W rezultacie HES-NG szybko stał się platformą, na której OSD planuje oprzeć w przyszłości realizację zadań, wynikających z ustawowych regulacji, którym podlega (m.in. wsparcie procesu bezpiecznej i niezawodnej wymiany danych dla dodatkowych 800 tys. urządzeń w ramach inicjatywy 80 proc. liczników AMI do 2028 roku).

MARIUSZ JĘDRZEJEWSKI
innogy Polska IT Support

Czytaj dalej