Termin „digital twin” bywa używany do opisania wszystkiego – od modelu 3D w CAD do pulpitu z wykresami. Z inżynierskiego punktu widzenia bliźniak cyfrowy to model obiektu połączony dwukierunkowo z jego fizycznym odpowiednikiem, aktualizowany danymi z produkcji i zdolny do odpowiadania na pytania „co się stanie, jeżeli”. Bez tego sprzężenia mamy wizualizację, nie bliźniaka. Poniżej opisujemy architekturę danych takiego wdrożenia i wymagania, które trzeba spełnić po stronie sterowania.
Poziomy dojrzałości – od modelu do bliźniaka
| Poziom | Nazwa | Sprzężenie z obiektem | Typowe zastosowanie |
|---|---|---|---|
| 1 | Model cyfrowy | brak – dane wprowadzane ręcznie | Dokumentacja, oferta, koncepcja |
| 2 | Cień cyfrowy (digital shadow) | jednokierunkowe: obiekt → model | Monitoring, raportowanie OEE |
| 3 | Bliźniak cyfrowy | dwukierunkowe, z aktualizacją stanu | Optymalizacja nastaw, testy zmian |
| 4 | Bliźniak predykcyjny | dwukierunkowe + modele prognostyczne | Utrzymanie predykcyjne, symulacja scenariuszy |
Większość wdrożeń przemysłowych zatrzymuje się na poziomie 2 i to często wystarcza – daje rzetelny obraz strat i dostępności. Przejście na poziom 3 ma sens, gdy istnieje realna potrzeba testowania zmian (nowy wariant produktu, inna kolejność operacji) bez zatrzymywania produkcji. Zakres takich wdrożeń opisujemy w usłudze wdrożeń na produkcji typu Digital Twin.
Architektura warstwowa i przepływ danych
Wdrożenie porządkujemy w cztery warstwy o rozdzielonych odpowiedzialnościach. Kluczowa zasada: warstwa sterowania nigdy nie zależy od dostępności warstw wyższych – awaria serwera danych nie może zatrzymać maszyny.
| Warstwa | Elementy | Protokół / format | Czas odpowiedzi |
|---|---|---|---|
| Sterowanie (OT) | PLC, serwonapędy, roboty, czujniki | PROFINET, EtherCAT, EtherNet/IP | 1–10 ms |
| Akwizycja | serwer OPC UA, brama edge | OPC UA (PubSub / Client-Server), MQTT | 50–500 ms |
| Przetwarzanie | baza czasu szeregowego, reguły agregacji | InfluxDB, TimescaleDB, Parquet | sekundy |
| Model i analityka | model symulacyjny, warstwa raportowa | REST/gRPC, API symulatora | sekundy – minuty |
Dobór sygnałów – mniej, ale właściwych
Typowy błąd to próba archiwizacji wszystkiego. Przy 2000 sygnałach próbkowanych co 100 ms generujemy około 1,7 mld rekordów na dobę, z czego przydatny jest ułamek. Zamiast tego dobieramy sygnały na podstawie pytań, na które model ma odpowiadać, i dopasowujemy częstotliwość do dynamiki zjawiska.
| Kategoria danych | Przykład | Częstotliwość | Retencja |
|---|---|---|---|
| Zdarzenia stanu | start/stop cyklu, zmiana trybu | zdarzeniowo | 2–5 lat |
| Liczniki produkcji | sztuki dobre, braki, przezbrojenia | na cykl | 5 lat |
| Alarmy i przestoje | kod, czas, stanowisko, przyczyna | zdarzeniowo | 5 lat |
| Parametry procesowe | siła docisku, temperatura, ciśnienie | 200 ms – 1 s | 3–12 miesięcy |
| Przebiegi dynamiczne (trace) | prąd silnika, błąd nadążania | 1–10 ms | bufor kołowy 1–7 dni |
| Dane metrologiczne | wyniki pomiarów z kontroli | na detal | wg wymagań klienta |
Wymagania po stronie sterownika
To, czy bliźniak cyfrowy jest wykonalny, w 80 % rozstrzyga się w programie PLC. Jeżeli sterownik nie odróżnia przyczyn przestoju, nie liczy cykli i nie znakuje detali identyfikatorem, żadne narzędzie analityczne nie odtworzy tych informacji z zewnątrz.
- Identyfikacja detalu – unikalny identyfikator (DMC, RFID, licznik) towarzyszący detalowi przez całą linię; bez niego nie da się powiązać parametrów procesu z wynikiem kontroli.
- Znacznik czasu w sterowniku – zdarzenia znakowane w PLC, nie w warstwie akwizycji; synchronizacja czasu przez NTP/PTP, inaczej korelacja zdarzeń między stanowiskami jest niewiarygodna.
- Model stanu maszyny – jednoznaczne stany (praca, przestój planowany, awaria, brak materiału, przezbrojenie) sumujące się do 100 % czasu, bez luk.
- Struktura danych a nie pojedyncze tagi – dane eksponowane jako obiekty (np. Station.Status, Station.Counters) ułatwiają skalowanie i utrzymanie mapowania.
- Wersjonowanie programu – numer wersji dostępny jako sygnał; zmiana kodu bez zapisu wersji unieważnia analizy historyczne.
Te elementy projektujemy jako część specyfikacji oprogramowania, równolegle z logiką maszyny – szczegóły w opisie usługi programowania sterowników PLC oraz automatyki i uruchomień.
OPC UA jako warstwa integracyjna
OPC UA jest dzisiaj standardem sprzęgającym warstwę OT z IT, przede wszystkim dzięki modelowi informacyjnemu: dane mają typ, jednostkę i strukturę, a nie tylko adres. W praktyce stosujemy dwa tryby: Client-Server dla odczytu strukturalnego i konfiguracji oraz PubSub (lub MQTT z modelem OPC UA) dla strumieni telemetrii o wielu odbiorcach.
| Aspekt | Client-Server | PubSub / MQTT |
|---|---|---|
| Model komunikacji | zapytanie – odpowiedź, subskrypcje | publikacja do brokera / multicast |
| Skalowanie odbiorców | ograniczone liczbą sesji | bardzo dobre |
| Opóźnienie typowe | 50–500 ms | 10–100 ms |
| Praca przez sieci rozległe | wymaga tunelowania | naturalne (MQTT przez TLS) |
| Zastosowanie | konfiguracja, odczyt na żądanie | telemetria, dashboardy, wiele systemów |
Niezależnie od wariantu obowiązuje zasada jednokierunkowego przepływu danych do warstw wyższych. Zapis do sterownika z systemu nadrzędnego (np. zmiana receptury) realizujemy wyłącznie przez zdefiniowany, walidowany interfejs z potwierdzeniem – nigdy przez bezpośredni zapis do zmiennych wykorzystywanych w logice bezpieczeństwa lub sekwencji.
Etapy wdrożenia i typowy harmonogram
| Etap | Zakres | Czas orientacyjny |
|---|---|---|
| Analiza pytań i wskaźników | ustalenie, na co model ma odpowiadać | 1–2 tygodnie |
| Specyfikacja sygnałów i modelu danych | lista tagów, struktury, retencja | 2–3 tygodnie |
| Rozszerzenie programu PLC | stany, liczniki, klasyfikacja przestojów | 2–4 tygodnie |
| Warstwa akwizycji i baza | OPC UA, brama edge, baza czasowa | 2–3 tygodnie |
| Model symulacyjny i kalibracja | dopasowanie do danych rzeczywistych | 3–6 tygodni |
| Walidacja i szkolenie | porównanie prognoz z produkcją | 2 tygodnie |
Kalibracja modelu na danych rzeczywistych jest etapem, który najczęściej jest pomijany, a decyduje o zaufaniu do wyników. Model uznajemy za wiarygodny, gdy prognozowana przepustowość mieści się w granicach ±3–5 % wartości zmierzonej w porównywalnych warunkach. Punktem wyjścia bywa model zbudowany na potrzeby wirtualnego uruchomienia linii – jego ponowne wykorzystanie radykalnie skraca ten etap. Więcej o całościowym podejściu do wdrożeń: wdrażanie systemów produkcyjnych.
Powiązane artykuły z Poradnika Technicznego
- Wirtualne uruchomienie linii (virtual commissioning) – MiL, SiL, HiL w praktyce
- Stanowiska kontrolno-pomiarowe i systemy wizyjne – dobór komponentów i walidacja Gage R&R
- Czas taktu i OEE – jak obliczyć przepustowość linii produkcyjnej
Pełna lista opracowań: Poradnik Techniczny MDP Engineering. Masz pytanie dotyczące własnego projektu? Skontaktuj się z nami.
