MQTT и Sparkplug B: IoT протоколи за телеметрия и SCADA в енергетиката

Какво е MQTT

MQTT (Message Queuing Telemetry Transport) е лек publish-subscribe протокол, създаден от IBM през 1999 г. и стандартизиран като ISO/IEC 20922 (MQTT 3.1.1) и OASIS MQTT 5.0. Той е замислен за ненадеждни мрежи с ограничена честотна лента — точно условията, при които работят много енергийни обекти.

Publish-Subscribe модел

За разлика от Modbus и IEC 104 (client-server / master-slave), MQTT ползва publish-subscribe модел с три роли:

• Publisher — устройство, което публикува данни в определен topic (тема). Например RTU публикува измервания.
• Subscriber — приложение, което се абонира за topic и получава данните. Например SCADA сървър.
• Broker — централен сървър (Mosquitto, HiveMQ, EMQX), който приема публикациите и ги разпраща до всички абонати на съответния topic.

Publisher-ът и subscriber-ът не знаят един за друг — те комуникират само с broker-а. Това осигурява разхлабено свързване (loose coupling) и лесно мащабиране.

Topic структура

Topic-ите в MQTT са йерархични низове, разделени с наклонена черта:

• site/substation01/bay03/voltage
• solar/plant-varna/inverter-05/dc-power
• grid/feeder-12/recloser/status

Subscriber-ът може да ползва wildcards:

• + — един ниво: site/+/bay03/voltage (всички подстанции, bay 03).
• # — всички нива след позицията: solar/plant-varna/# (всичко от тази централа).

QoS нива

За телеметрия в енергетиката QoS 1 е най-честият избор — баланс между надеждност и скорост.

Retained Messages и Last Will

• Retained Message — broker-ът пази последната стойност на topic. Нов subscriber получава веднага последната стойност, без да чака следващата публикация.
• Last Will and Testament (LWT) — при свързване клиентът регистрира съобщение, което broker-ът ще публикува, ако връзката прекъсне неочаквано. Позволява на SCADA да открие, че устройството е офлайн.

MQTT 5.0 подобрения

• User Properties — метаданни в key-value формат към всяко съобщение.
• Shared Subscriptions — балансиране на натоварването между множество subscriber-и.
• Topic Alias — числов заместител на дълъг topic (намалява трафика).
• Message Expiry Interval — автоматично изтичане на стари съобщения.
• Reason Codes — подробни кодове за грешки и прекъсвания.

Sparkplug B — SCADA семантика върху MQTT

Чистият MQTT не дефинира какво съдържа payload-ът и как се именуват topic-ите. Sparkplug B (Eclipse Foundation, спецификация v3.0) добавя:

• Стандартизирана topic структура: spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
• Protobuf payload — компактен бинарен формат с метрики, типове данни, времеви печати и качествени флагове.
• Birth / Death certificates — при свързване edge node-ът публикува NBIRTH с пълен списък на своите метрики. При прекъсване broker-ът публикува NDEATH.
• State awareness — SCADA приложението (Primary Application) публикува STATE, за да покаже дали е онлайн.

Типове съобщения в Sparkplug B

Метрики

Всяка метрика съдържа:

• Name — име на точката (напр. „Voltage_L1").
• Alias — числов идентификатор (след BIRTH се ползва само alias за намаляване на трафика).
• Datatype — Int8, Int16, Int32, Int64, UInt8–UInt64, Float, Double, Boolean, String, DateTime.
• Value — текущата стойност.
• Timestamp — милисекунди (uint64).
• Quality — is_null, is_transient и др.

Архитектура в енергетиката

Типична реализация:

1. Полево ниво — RTU/PLC/gateway комуникира с електромери и инвертори по Modbus, IEC 101 или DNP3.
2. Edge Node — софтуер (Ignition Edge, HiveMQ Edge, Cirrus Link) превежда полевите протоколи в Sparkplug B и публикува в MQTT broker.
3. MQTT Broker — облачен или локален (HiveMQ, EMQX, Mosquitto). Приема данните и ги разпраща.
4. SCADA / Historian / Cloud — абонира се за метриките. Може да е Ignition, AWS IoT, Azure IoT Hub, или custom приложение.

Сигурност

• TLS 1.2/1.3 — криптиране на TCP връзката между клиент и broker.
• Автентикация — username/password, client certificate (mTLS), или OAuth 2.0 token.
• ACL (Access Control List) — broker-ът ограничава кой клиент до кои topic-и има достъп (publish/subscribe).
• MQTT 5.0 Enhanced Authentication — SASL-базирана автентикация.

MQTT/Sparkplug B спрямо IEC 104

Типични приложения

• Фотоволтаичен мониторинг — инвертори → Modbus → edge gateway → MQTT → облачна платформа.
• Виртуални електроцентрали (VPP) — агрегиране на разпръснати ресурси (батерии, генератори, EV зарядни) чрез MQTT.
• Предиктивна поддръжка — вибрации, температура, маслен анализ от трансформатори — поточно към ML платформа.
• Микромрежи — координация на DER (Distributed Energy Resources) чрез Sparkplug B.

Въвеждане в експлоатация

1. Избор и настройка на MQTT broker (Mosquitto за малки инсталации, HiveMQ/EMQX за enterprise).
2. Конфигуриране на TLS и ACL.
3. Настройка на edge gateway — Sparkplug B connector към полеви протоколи.
4. Дефиниране на topic namespace и метрики (Sparkplug group/node/device).
5. Тест с MQTT клиент (MQTT Explorer, mosquitto_sub/pub) — проверка на BIRTH съобщения.
6. Свързване на SCADA/Historian и проверка на DDATA потока.
7. Тест на DEATH сценарий — изключване на edge node, проверка на NDEATH.

Типични проблеми

• Broker претоварен при твърде чести публикации (sub-second) от много устройства — необходимо е клъстериране.
• Retained message с остаряла стойност — нов subscriber получава неактуална информация.
• Загуба на съобщения при QoS 0 и нестабилна мрежа.
• Topic namespace без конвенция — хаотична организация затруднява мащабирането.
• Sparkplug BIRTH не се изпраща след reconnect — SCADA не знае текущото състояние на метриките.

Кога се избира MQTT / Sparkplug B

При нови инсталации с облачна архитектура, разпръснати ресурси (DER, VPP, IoT сензори) и нужда от мащабируемост. MQTT допълва, а не замества IEC 104 — критичната телемеханика на подстанции остава на IEC 104/61850, а MQTT/Sparkplug B обслужва edge-to-cloud интеграцията и аналитичния слой.