Модуль p.9 · Урок 5
Урок 5: IIoT open-source стек — ThingsBoard + EMQX + OPC UA + TimescaleDB + Grafana
Содержание
- Чему вы научитесь
- Базовая референс-архитектура
- Первое важное исправление research-пака: open62541 — это MPL, а не LGPL
- Второе важное исправление: EMQX уже не Apache-2.0 Community в актуальной ветке
- Третье исправление: Grafana и TimescaleDB надо называть честно
- Как выглядит рабочая схема на заводе
- Вариант А: ThingsBoard как платформа
- Вариант Б: минималистичный стек без платформы
- Где нужен Node-RED
- MVP за неделю: что реально собрать
- Где этот стек ломается
- 1. OPC UA security не настроена
- 2. Tag explosion
- 3. Стек собирают без лицензионной карты
- А что со SCADA open-source
Чему вы научитесь
- Собирать IIoT-стек без проприетарных западных платформ: от PLC до дашборда
- Выбирать open-source OPC UA, MQTT, time-series и dashboard-компоненты с учётом реальных лицензий, а не старых презентаций
- Понимать, когда ThingsBoard нужен как платформа, а когда достаточно связки
OPC UA → MQTT → DB → Grafana - Не попадать в ловушки по лицензиям: EMQX, Grafana, mixed-license у TimescaleDB и фактическая лицензия open62541
- Делать MVP за неделю без архитектурного самообмана
В промышленном IIoT open-source стек хорош тем, что он может жить полностью on-prem и не требует закрытого SaaS. Но это не означает, что все компоненты одинаково «свободные». На 20 апреля 2026 года у части популярных проектов лицензии уже успели поменяться. Поэтому правильный вопрос звучит так: не «какой стек моднее», а «какой стек можно законно эксплуатировать в моём контуре».
Базовая референс-архитектура
| Слой | Инструмент | URL | Лицензия | Зрелость AIStudy | Комментарий |
|---|---|---|---|---|---|
| OPC UA C SDK | open62541 | github.com/open62541/open62541 | MPL-2.0 + CC0 parts | production | Важное исправление: это не LGPL, а MPL |
| OPC UA Java | Eclipse Milo | github.com/eclipse-milo/milo | EPL-2.0 | stable | Хорошо для Java-стека |
| OPC UA Python | asyncua / opcua-asyncio | github.com/FreeOpcUa/opcua-asyncio | LGPL-family, точную редакцию лучше проверить | stable | Удобный экспорт из PLC в data pipeline |
| MQTT broker | EMQX | github.com/emqx/emqx | BSL 1.1 c v5.9+ | production | Технически силён, но уже не Apache-2.0 |
| MQTT broker | Mosquitto | mosquitto.org | EPL / EDL | production | Самый спокойный licensing-profile |
| IIoT platform | ThingsBoard CE | github.com/thingsboard/thingsboard | Apache-2.0 | production | Device management, rules, dashboards |
| Edge wiring | Node-RED | github.com/node-red/node-red | Apache-2.0 | production | Быстрый low-code клей |
| Edge platform | EdgeX Foundry | edgexfoundry.org | Apache-2.0 | stable | Сильнее, когда устройств и протоколов много |
| Time-series in Postgres | TimescaleDB | github.com/timescale/timescaledb | mixed / Apache-2.0 + дополнительные условия | production | Очень удобен, но license terms надо проверять |
| Time-series | InfluxDB | github.com/influxdata/influxdb | mixed ecosystem | production | Быстрый ingest, но licensing надо смотреть по версии |
| Event streaming | Apache Kafka | github.com/apache/kafka | Apache-2.0 | production | Нужен не всегда, но полезен для scale |
| Dashboarding | Grafana | github.com/grafana/grafana | AGPL-3.0 | production | Для внутреннего использования нормален, для OEM/перепродажи осторожно |
Первое важное исправление research-пака: open62541 — это MPL, а не LGPL
Официальный репозиторий open62541 прямо пишет: библиотека лицензирована под Mozilla Public License v2.0, а отдельные части — под CC0; это позволяет встраивать её в проприетарный софт, не распространяя copyleft на весь ваш продукт, если не модифицировать саму библиотеку (open62541/open62541).
Это важное отличие. Для промышленного интегратора MPL обычно проще объяснить, чем LGPL, потому что область открытия кода уже и привязана к самим файлам библиотеки.
Второе важное исправление: EMQX уже не Apache-2.0 Community в актуальной ветке
Research-пак держит старую картину: EMQX Community Edition = Apache-2.0. Актуальная официальная страница репозитория пишет другое: начиная с v5.9.0 EMQX перевёл все функции в единое издание под Business Source License 1.1, а для кластера из более чем одного узла теперь нужен license file (emqx/emqx).
Это не означает, что EMQX надо вычеркнуть. Это означает, что для лицензионно-чувствительного проекта у вас теперь два сценария.
- либо вы осознанно берёте EMQX как технически сильный broker и отдельно проверяете BSL-условия;
- либо для максимально спокойного OSS-контура берёте Mosquitto и не спорите с юристами.
Третье исправление: Grafana и TimescaleDB надо называть честно
Официальный репозиторий Grafana говорит прямо: OSS-ветка распространяется под AGPL-3.0, с отдельными Apache-исключениями, описанными в LICENSING.md (grafana/grafana). Для внутреннего корпоративного использования это чаще всего приемлемо. Для перепродажи, white-label и OEM-решений — уже нетривиальная тема.
С TimescaleDB ситуация мягче, но тоже не «чистый Apache» в старом смысле. В официальном репозитории одновременно видны Apache-2.0 и дополнительная лицензия, а значит terms надо проверять по тем функциям и пакетам, которые вы реально используете (timescale/timescaledb).
Практический вывод: для внутреннего завода стек TimescaleDB + Grafana по-прежнему очень хорош. Но если вы строите продукт для внешней поставки, licensing review обязателен.
Как выглядит рабочая схема на заводе
flowchart LR
A[PLC / контроллеры / OPC UA server] --> B[asyncua / open62541 client]
B --> C[MQTT broker]
C --> D[Node-RED rules]
D --> E[TimescaleDB]
D --> F[ThingsBoard CE]
E --> G[Grafana]
F --> GЗдесь есть два возможных центра тяжести.
Вариант А: ThingsBoard как платформа
Если вам нужны device registry, rule engine, alarms, dashboards, multi-tenant UI и готовый IIoT-слой, ThingsBoard CE — очень сильная база. Официальный репозиторий под Apache-2.0, есть gateway, device management и поддержка стандартных протоколов (thingsboard/thingsboard).
Вариант Б: минималистичный стек без платформы
Если у вас одна площадка, несложная логика и сильная команда ИТ/OT, иногда достаточно цепочки OPC UA client → MQTT → Node-RED → TimescaleDB → Grafana. Это дешевле и проще по TCO, но требует дисциплины в поддержке.
Где нужен Node-RED
Node-RED многие недооценивают, потому что воспринимают как «игрушку для low-code». Это ошибка. На заводе он часто полезен ровно там, где нужен прозрачный glue layer между промышленным протоколом, брокером, простой логикой и интеграцией с внешними системами. Официальный проект живой, под Apache-2.0, с долгой историей production-использования (node-red/node-red).
Node-RED уместен, если нужно:
- быстро собрать маршрут данных без тяжёлого кода;
- сделать простые правила и трансформации;
- быстро показать MVP цеху и ИТ.
Node-RED плох, если вы пытаетесь превратить его в полноценную data platform. Тогда лучше заранее идти в Kafka/streaming и платформенную архитектуру.
MVP за неделю: что реально собрать
Подключитесь к PLC через OPC UA. На Python-пути чаще всего быстрее всего стартовать через
opcua-asyncio/asyncua, на C — через open62541.Стабилизируйте теги. Имена, units, sampling interval, quality flags. Без этого дальше будет красивый хаос.
Проложите данные в MQTT. Если licensing важнее всего — смотрите сначала Mosquitto. Если нужна функциональность и вы готовы к review лицензии — EMQX.
Добавьте простую rule-логику. Node-RED достаточно, чтобы перевести теги в события, алерты и нормализованные сообщения.
Сложите time-series в TimescaleDB. Это самый удобный первый путь, если у вас уже есть PostgreSQL-компетенция.
Поднимите Grafana или ThingsBoard. Grafana — для аналитического дашборда, ThingsBoard — если нужен ещё и device/rule слой.
Где этот стек ломается
1. OPC UA security не настроена
Самая частая техническая ошибка — команды проверяют только чтение тегов и забывают про сертификаты, политики безопасности и аутентификацию. Потом в production внезапно выясняется, что «быстрый пилот» жил без нормальной security-конфигурации. Для КИИ и чувствительных контуров это неприемлемо — см. урок p.3/02.
2. Tag explosion
Если брать все теги PLC подряд, вы получите не IIoT-систему, а свалку сигналов. Нужна модель данных: что хранить постоянно, что агрегировать, что считать событием, а что оставлять в SCADA/historian.
3. Стек собирают без лицензионной карты
Это особенно опасно в open-source IIoT. EMQX, Grafana, TimescaleDB, SCADA-пакеты — у всех свои нюансы. Технически всё может взлететь, а юридически проект потом придётся пересобирать.
А что со SCADA open-source
Если вам нужен не только data-pipeline, но и полноценный open-source SCADA-контур, в research-паке есть два практических имени:
- Scada-LTS — LGPL/GPL-подобный контур, Java, web-based;
- Rapid SCADA — модульный вариант на .NET, в research-паке указан как Apache-подобный путь, но конкретные условия лучше сверять по текущему релизу — нужна проверка.
Для большинства AI-проектов я бы не начинал со «своей open-source SCADA». Чаще выгоднее интегрироваться в существующую SCADA/MES и строить отдельный data/AI-слой рядом.