Řízení technologií v energetice

Kdy potřebujete řízení technologií, ne jen monitoring

Většina zakázek na monitoring energetiky začíná stejně: „chceme vidět, co se na lokalitě děje“. Během prvních týdnů provozu se ale téměř vždy objeví druhá otázka: „a můžeme z toho dashboardu i něco změnit?“ V ten moment přestává jít o vizualizaci a začíná řízení technologií.

Konkrétní scénáře, kdy je dálkové řízení nezbytné:

• Nastavení setpointu činného výkonu PCS — provozovatel BESS reaguje na signál agregátora nebo na cenu silové elektřiny a musí okamžitě změnit režim úložiště (nabíjení / vybíjení / držení).
• Dispečerské blokace — distributor nebo interní dispečink požaduje omezení výkonu FVE. Manuální zásah na lokalitě není akceptovatelný časem odezvy ani auditovatelně.
• Reset po poruše — po vyřešení příčiny alarmu operátor potřebuje vzdáleně kvitovat chybu a znovu spustit technologii, aniž by musel na místo.
• Změna režimu ochran — sezónní přenastavení proudových nebo napěťových prahů REF615, s plnou dohledatelností kdo, kdy a proč.

Architektura řízení přes cloud

Řízení technologií z cloudové platformy vypadá jinak než čtení telemetrie. Zápis na Modbus register mění fyzický stav zařízení, a to nese jiné požadavky na bezpečnost, latenci a auditovatelnost. ECC platforma řeší řízení touto cestou:

1. Operátor odešle příkaz z webové aplikace. Aplikace ověří jeho oprávnění (RBAC: role operator nebo admin) a zvaliduje příkaz proti register mapě zařízení (že jde o zapisovatelný register, že hodnota je v povoleném rozsahu).
2. Zvalidovaný příkaz je odeslán jako direct method přes Azure IoT Hub na edge modul. Direct method má timeout — pokud edge nezareaguje do 30 sekund, příkaz je zamítnut a operátor to okamžitě vidí.
3. Edge modul provede zápis přes Modbus (funkční kódy FC6 / FC16) a vrátí skutečnou odpověď zařízení. Nic není „fire-and-forget“ — každý příkaz má potvrzený nebo zamítnutý výsledek.
4. Kompletní řetězec — kdo, kdy, jakou hodnotu, jaké zařízení, jaký výsledek — je zapsán do audit log tabulky s hash řetězcem. Auditor si kdykoli může řetězec ověřit kryptograficky.

Bezpečnost dálkových zásahů

Dálkové řízení energetické technologie je z pohledu NIS2 a ISA/IEC 62443 jedna z nejcitlivějších funkcí platformy. Konkrétní ochranná opatření, která máme zabudovaná:

• Rate limiting per uživatel a per zařízení — token bucket brání „ukliknutí“ i cíleným pokusům o zaplavení zařízení příkazy.
• Explicit write allowlist v register mapě — jen registery označené jako writable: true lze měnit. Ochranné funkce a konfigurace zůstávají typicky read-only.
• Two-person integrity pro kritické změny (roadmap) — nastavení prahů ochran vyžaduje potvrzení druhého operátora s rolí admin.
• Audit chain s hash návazností — každý záznam v audit_log obsahuje SHA-256 hash předchozího záznamu. Zpětná úprava logu se pozná okamžitě, hodinová kontrolní úloha ověřuje řetězec automaticky.
• Session invalidace přes lastLogout — odvolání přístupu je okamžité, ne až po vypršení JWT.

Kdy řízení přes cloud nemá smysl

Poctivě: ne všechno řízení patří do cloudu. Ochranné funkce (rychlé vypínání, distanční ochrany, blokáda podpětí) vždy zůstávají v lokální ochraně nebo PLC s reakční dobou v milisekundách. Cloud slouží pro dispečerskou vrstvu — pomalejší rozhodování, které lze udělat v řádu sekund a je potřeba mít z jednoho místa napříč lokalitami. Rozhraní mezi lokální ochrannou logikou a cloudovou dispečerskou vrstvou je typický scope integračního projektu, který stavíme.

Vazba na integrátorské služby

Řízení technologií není samostatný produkt — je to výstup dobře odvedené integrace. Pokud řešíte konkrétní projekt, kde potřebujete zkombinovat vizualizaci, dispečink a bezpečné dálkové zásahy, začněte na stránce integrace energetických systémů. Tam popisujeme rozsah služeb a technologické stacky, se kterými dělíme.