Архитектура платформы

Уровни системы

Архитектура Стрикс соответствует модели Purdue (ISA-95) и включает четыре функциональных уровня.

L0 — Полевой уровень

Датчики и исполнительные механизмы, установленные непосредственно на оборудовании. Платформа поддерживает работу с датчиками серии Passer (Passer-В — вибрация, Passer-Т — ток и напряжение, MCSA), а также со сторонними устройствами по протоколам Modbus TCP, 4-20 мА (через модули ввода-вывода Larus) и BACnet/IP.

L1 — Edge-уровень

Edge-контроллеры Larus-10 и Larus-100 выполняют локальный сбор, предобработку и буферизацию данных. Контроллеры работают на базе стандарта IEC 61499 (распределённые функциональные блоки) и передают данные на платформенный уровень по MQTT. При потере связи с сервером данные буферизуются локально и досылаются после восстановления соединения.

L2 — Платформенный уровень

Ядро системы: BaSyx AAS Environment (модель данных), ClickHouse (история телеметрии), вычислительные сервисы (OEE, аварии, диагностика, APC), веб-интерфейс оператора. Все компоненты развёрнуты в Docker-контейнерах и взаимодействуют через REST API и MQTT.

L3 — Бизнес-уровень

Интеграция с системами управления техническим обслуживанием (ЛиманИСУ ТОРО), ERP, складским учётом. Данные из Стрикс доступны через REST API и могут использоваться для автоматического формирования заявок на ремонт, учёта наработки и планирования закупок запасных частей.

Модель данных AAS

В основе модели данных лежит стандарт IEC 63278 Asset Administration Shell (AAS) — цифровой паспорт оборудования, содержащий все сведения об активе: идентификацию, технические характеристики, телеметрию, историю обслуживания.

Иерархия оборудования

Стрикс использует четырёхуровневую иерархию:

Предприятие (facility)
  └── Участок (area)
        └── Группа оборудования (equipmentGroup)
              └── Единица оборудования (equipment)

Связи «родитель — потомок» задаются через атрибут parentId в specificAssetIds каждой оболочки. Уровень area является семантически гибким: на одном предприятии это может быть технологический участок (измельчение, флотация), на другом — подзавод или производственный корпус.

IRI-идентификация

Каждый объект в системе имеет глобально уникальный идентификатор в формате IRI:

Оболочка:  https://company.com/site/aas/equipment/pump-001
Субмодель:  https://company.com/site/sm/pump-001/operational-data
Актив:      https://company.com/site/asset/pump-001

Пространство имён (namespace) определяет принадлежность к проекту. Все представления во фронтенде фильтруются по активному namespace, что обеспечивает мультипроектность в рамках одного экземпляра BaSyx.

Субмодели

Каждая единица оборудования может содержать набор субмоделей, описывающих различные аспекты актива:

Субмодель	Стандарт	Назначение
Nameplate	IDTA 02006	Идентификация: серийный номер, производитель, год выпуска
TechnicalData	IDTA 02003	Технические характеристики: мощность, масса, габариты
OperationalData	—	Текущие значения телеметрии (температура, вибрация, ток)
TelemetryConfig	Liman	Конфигурация сбора: период, агрегация, фильтры, список параметров
OEE	ISO 22400-2	Рассчитанные показатели эффективности (доступность, производительность, качество)
AlarmHistory	—	Журнал аварийных событий с метками времени
TimeSeries	IDTA 02008	Ссылки на исторические данные (ClickHouse, S3 Parquet)
InterfaceMapping	IDTA 02027	Маппинг источников данных (MQTT topic, OPC UA nodeId)

Субмодели уровня проекта

На оболочке предприятия (facility) размещаются проектные субмодели: ProjectInfo (метаданные проекта, контакты, ссылки на внешние системы) и StoragePolicy (политика хранения телеметрии, квоты, переопределения по группам).

Каскад конфигурации

Параметры хранения и обработки телеметрии наследуются по иерархии с возможностью переопределения на каждом уровне:

StoragePolicy (предприятие) → значения по умолчанию для всего проекта
  └── Overrides[].MatchEquipmentType → переопределение для группы оборудования
        └── TelemetryConfig (единица) → переопределение для конкретного оборудования
              └── Parameters[].Period → переопределение для отдельного параметра

Топология деплоя

Все компоненты платформы развёрнуты в Docker-контейнерах на одном или нескольких серверах. Типовая схема деплоя:

Разделение инфраструктуры и сервисов

Инфраструктурные контейнеры (BaSyx, MongoDB, ClickHouse, Mosquitto) управляются отдельно от прикладных сервисов. Это позволяет обновлять вычислительные сервисы без остановки хранилища данных.

Поток данных

Описание потока

1. Сбор данных. Датчики Passer передают аналоговые сигналы на edge-контроллеры Larus. Контроллеры оцифровывают, фильтруют и публикуют данные в MQTT-брокер.

2. Запись в BaSyx. Сервис data-bridge подписывается на MQTT-топики и обновляет значения в субмодели OperationalData соответствующего оборудования. Маппинг «топик — свойство» задаётся через субмодель InterfaceMapping (IDTA 02027).

3. Запись в ClickHouse. Параллельно сервис telemetry-writer буферизует сообщения и записывает их в таблицу telemetry_raw. Материализованные представления автоматически агрегируют данные в telemetry_1min и telemetry_1hour.

4. Вычислительные сервисы. Каждый сервис (OEE, Alarms, Energy, Runtime, MTBF) периодически читает данные из BaSyx, выполняет расчёт и записывает результат обратно в BaSyx. Сервисы не имеют собственных баз данных — BaSyx является единственным источником истины.

5. Визуализация. Веб-интерфейс отображает текущие значения из BaSyx (через REST API) и исторические графики из ClickHouse (через HTTP-интерфейс).

6. Управление. Модуль APC читает текущее состояние процесса из BaSyx, рассчитывает оптимальные уставки и передаёт их на edge-контроллеры через MQTT.

Сервисная архитектура

Все вычислительные сервисы следуют единому архитектурному паттерну:

• Без собственной базы данных — BaSyx AAS является единственным хранилищем состояния
• Конфигурация в субмоделях — параметры расчёта хранятся в SMC (SubmodelElementCollection), а не в переменных окружения
• Одна оболочка = все субмодели — результат сервиса записывается в ту же оболочку, что и входные данные
• Идемпотентность — сервис можно перезапустить в любой момент без потери консистентности
• Upsert-паттерн — POST для создания, PUT при конфликте (409), PATCH не поддерживается

Сервис	Входная субмодель	Выходная субмодель	Период
oee	OperationalData + OperationalModes	OEE	60 с
energy	OperationalData	EnergyConsumption	60 с
alarms	OperationalData	AlarmHistory	30 с
runtime	OEE (CurrentMode)	Runtime	60 с
mtbf	Runtime + AlarmHistory	MTBF	300 с
monitor	все сервисы	SystemHealth	30 с
data-quality	OperationalData	DataQuality	60 с
telemetry-writer	TelemetryConfig + MQTT	ClickHouse	5 с (flush)
retention-cleanup	StoragePolicy	ClickHouse DELETE	3600 с
emulator	EmulationConfig	MQTT	1 с

Подробнее о каждом сервисе: Каталог сервисов

Безопасность

Аутентификация и авторизация

Платформа использует Keycloak в качестве провайдера идентификации (IdP) с протоколом OpenID Connect (OIDC).

Ролевая модель (realm roles):

Роль	Права
platform-admin	Полный доступ ко всем проектам и настройкам платформы
project-editor	Редактирование оборудования, субмоделей и конфигурации в рамках назначенных проектов
project-viewer	Просмотр данных мониторинга и отчётов без возможности изменения

Защита API

• Веб-интерфейс: OIDC-токены Keycloak, проверяемые на уровне API Gateway (FastAPI)
• Межсервисное взаимодействие: заголовок X-API-Key для аутентификации вычислительных сервисов при обращении к BaSyx REST API
• Внешний доступ: Authentik reverse proxy на входе, TLS-терминация, rate limiting

Соответствие 187-ФЗ

Архитектура предусматривает сегментацию сети между уровнями L0-L1 (полевая сеть) и L2-L3 (корпоративная сеть). Edge-контроллеры Larus работают в изолированном сегменте и инициируют исходящие соединения к MQTT-брокеру. Входящие соединения из корпоративной сети на полевой уровень запрещены.

Далее

• Стрикс.Монитор — модуль мониторинга и визуализации
• Стрикс.Диагност — модуль диагностики и предиктивного обслуживания
• Стрикс.APC — модуль усовершенствованного управления процессами
• Каталог сервисов — описание всех вычислительных сервисов