Cyfrowy bliźniak

Jednej, uzgodnionej definicji nie ma. NIST pisze o tym wprost w raporcie IR 8356 (luty 2025) i przytacza opis Digital Twin Consortium: wirtualna reprezentacja rzeczywistych obiektów i procesów, zsynchronizowana z określoną częstotliwością i wiernością. Własne, krótsze sformułowanie NIST brzmi: wirtualna (czyli cyfrowa) reprezentacja fizycznego albo postrzeganego obiektu, pojęcia lub idei ze świata rzeczywistego. Bliźniak może odwzorowywać pompę, całą instalację albo proces, np. harmonogram ładowania. Po stronie norm pojęcia i terminologię porządkuje ISO/IEC 30173:2023.

Bliźniak różni się od modelu symulacyjnego jednym: danymi na żywo. Model buduje się raz, na podstawie rysunków i fizyki. Bliźniak dostaje dane z czujników bez przerwy, zwykle przez przemysłowe IoT albo istniejący system SCADA, więc jego stan nadąża za prawdziwym urządzeniem. NIST opisuje "definicję cyfrowego bliźniaka" jako czytelny maszynowo opis typu obiektu, a każde prawdziwe urządzenie jako instancję utworzoną z tej definicji. W języku oprogramowania to schemat dla klasy urządzeń plus jeden żywy obiekt na każdą fizyczną jednostkę.

Kiedy bliźniak ma bieżący stan i historię, może wykonywać trzy rodzaje pracy. Pokazuje aktualny stan urządzenia w jednym miejscu, obok jego dokumentacji. Uruchamia scenariusze "co jeśli", np. inną strategię ładowania albo nowy układ instalacji, bez ryzyka dla sprzętu. W najbardziej zaawansowanych wdrożeniach wysyła też polecenia z powrotem do urządzenia. Wpis na blogu o rozwiązywaniu problemów z cyfrowym bliźniakiem (po angielsku) pokazuje, jak dwie pierwsze funkcje pomagają przy awariach i usuwaniu ich skutków.

"Cyfrowy bliźniak" w wymaganiach może oznaczać wszystko, od kokpitu po sterownik w pętli zamkniętej, więc trzeba ustalić, którą funkcję z tabeli się kupuje. Bliźniak do monitoringu to głównie inżynieria danych. Bliźniak symulacyjny potrzebuje jeszcze modelu i kogoś, kto go skalibruje. Bliźniak, który steruje, staje się częścią analizy bezpieczeństwa instalacji.

Najpierw zapytaj o ścieżkę danych. Umowa powinna wymieniać źródła (PLC, SCADA, liczniki, dane pogodowe i rynkowe), częstotliwość próbkowania, sposób obsługi luk i wartości odstających oraz właściciela szeregów czasowych. Jakość danych i nazewnictwo sygnałów ustal na starcie. Poprawianie ich, gdy kokpity i modele już istnieją, jest drogie.

Potem zdecyduj, gdzie bliźniak działa i jak jest zabezpieczony. NIST IR 8356 wymienia pięć cech, przez które bliźniaki są nowym problemem bezpieczeństwa: masowe opomiarowanie obiektów, centralizacja pomiarów, wizualizacja działania obiektu, zdalne sterowanie i wspólne standardy definicji bliźniaków. W praktyce najważniejsza jest centralizacja. NIST zauważa, że po przejęciu bliźniaka atakujący ma pełny dostęp do wszystkich danych o opomiarowanym obiekcie, a ktoś, kto kontroluje bliźniaka, może zmieniać to, co widzi operator, i jednocześnie wydawać polecenia. Rozdziel ścieżki odczytu i zapisu, wymagaj potwierdzenia operatora dla poleceń, które poruszają sprzętem, i loguj każdy zapis.

Kontrola dostępu wymaga więcej projektowania, niż zakładają kupujący. Operatorzy, inżynierowie, zarząd i partnerzy zewnętrzni widzą różne urządzenia i mają różne uprawnienia. Trzymaj tożsamość w jednym miejscu, np. logowanie jednokrotne na load balancerze, a definicje ról w konfiguracji, zamiast rozpraszać je po kokpitach.

Na koniec ustal, jak bliźniak będzie utrzymywany. Sprzęt się wymienia, firmware zmienia listy sygnałów, a modele się rozjeżdżają. Zaplanuj budżet na aktualizację i ponowną kalibrację modelu po uruchomieniu, a definicje urządzeń wersjonuj, żeby historia pozostała czytelna po zmianie.

Dla Kyoto Group przez trzy i pół roku budowaliśmy oprogramowanie przemysłowego IoT i cyfrowego bliźniaka dla magazynu ciepła na stopionej soli: od MVP UX/UI do opartego na SCADA systemu, który w czasie rzeczywistym monitoruje i steruje przepływem energii.

Warstwa bliźniaka łączyła dane z instalacji z danymi pogodowymi i analizą cen energii i miała interfejs do symulacji wydajności instalacji. W 2024 r. zespół pracował też nad platformą webową do planowania lokalizacji przyszłych elektrowni słonecznych oraz symulowania ich wydajności i kosztów na podstawie danych, np. nasłonecznienia i ukształtowania terenu. Dane z instalacji przechodziły przez przemysłową platformę danych, której funkcje wystarczały do testów i prototypów, ale przy długotrwałym używaniu sprawiały problemy, więc następnym razem do logiki produkcyjnej wybralibyśmy dojrzalsze środowisko. Streamlit dobrze sprawdził się przy prototypach (PoC). Logowanie OIDC do Azure Entra ID przeniesione na load balancer AWS zdjęło uwierzytelnianie z aplikacji. Dostęp oparty na rolach w kokpitach był trudny w konfiguracji i nie sprawdził się na dłuższą metę, więc role warto zaplanować wcześnie.