Сервисы платформы

Платформа Стрикс построена на микросервисной архитектуре. Каждый сервис решает одну задачу: расчёт OEE, мониторинг алармов, учёт энергопотребления и т.д. Все сервисы работают по единому паттерну и взаимодействуют исключительно через REST API Eclipse BaSyx.

Архитектурные принципы

Stateless-процессы

Каждый сервис — это stateless Python-процесс, который читает и пишет данные только через BaSyx REST API. Сервис не хранит состояние между перезапусками: вся информация находится в субмоделях AAS.

Единый источник правды

BaSyx AAS Environment — единственная база данных для всех сервисов. Ни один сервис не использует собственное хранилище. Исключение — Telemetry Writer и Retention Cleanup, работающие с ClickHouse для хранения временных рядов.

Конфигурация в субмоделях

Параметры работы сервисов хранятся в субмоделях BaSyx, а не в переменных окружения. Переменные окружения содержат только адрес BaSyx и интервал опроса. Бизнес-конфигурация (пороги алармов, формулы расчёта, правила режимов) — всегда в субмоделях.

Мультиязычность

Все свойства субмоделей содержат displayName с переводами на русский и английский:

{
  "idShort": "CurrentPower",
  "displayName": [
    {"language": "ru", "text": "Текущая мощность"},
    {"language": "en", "text": "Current Power"}
  ]
}

Upsert-паттерн

BaSyx не поддерживает PATCH. Все сервисы используют паттерн POST → 409 (Conflict) → PUT:

1. Попытка создать субмодель через POST /submodels
2. Если получен код 409 — субмодель уже существует, обновляем через PUT /submodels/{id}
3. После создания субмодели обязательно вызвать POST /shells/{shellId}/submodel-refs для привязки

Жизненный цикл сервиса

Каждый сервис следует единому циклу работы:

Этап	Описание
discover	Поиск shell'ов с нужными субмоделями (например, OperationalData для OEE)
tick	Один цикл обработки — вызывает process_device для каждого найденного устройства
process_device	Чтение входных данных → вычисление → запись результата в выходную субмодель
sleep	Ожидание до следующего цикла (интервал задаётся в переменной окружения)

Кэширование конфигурации

Конфигурационные субмодели (OperationalModes, AlarmConfig) кэшируются на 5 минут. Это снижает нагрузку на BaSyx при частых циклах опроса.

Структура файлов сервиса

Каждый сервис расположен в services/{name}/ и содержит стандартный набор файлов:

services/oee/
├── main.py              # Точка входа: подключение, запуск цикла
├── oee_service.py       # Бизнес-логика: _tick(), _discover(), _process_device()
├── oee_builder.py       # Построение JSON субмодели
├── basyx_client.py      # REST-клиент BaSyx (общий для всех сервисов)
├── config.py            # pydantic-settings (BASYX_URL, интервал)
├── requirements.txt     # Зависимости Python
├── Dockerfile           # python:3.12-slim → pip install → python main.py
├── README.md            # Техническая документация
└── VERSION              # Версия сервиса (semver)

Деплой

Все сервисы запускаются через Docker Compose на продуктовом сервере. Каждый контейнер зависит от aas-environment:

my-service:
  build: ./services/my-service
  depends_on: [aas-environment]
  environment:
    - BASYX_URL=http://aas-environment:8081
    - MY_INTERVAL_SEC=60
  restart: unless-stopped

Деплой сервисов выполняется вручную через кнопку deploy-services в CI/CD пайплайне GitLab. Инфраструктурные контейнеры (MongoDB, Mosquitto, ClickHouse, BaSyx AAS Environment) работают автономно и не управляются через Compose.

Каталог сервисов

Сервис	Вход	Выход	Интервал	Статус
OEE	OperationalData + OperationalModes	OEE	60 с	production
Alarms	OperationalData	AlarmHistory + AlarmConfig	30 с	production
Energy	OperationalData	EnergyConsumption	60 с	production
Runtime	OEE (CurrentMode)	Runtime	60 с	production
MTBF	Runtime events	MTBF	60 с	production
Data Quality	OperationalData	DataQuality	60 с	production
Monitor	все сервисы	SystemHealth	30 с	production
Emulator	EmulationConfig	MQTT messages	1 с	production
Data Bridge	InterfaceMapping + MQTT	OperationalData	5 с	production
Telemetry Writer	TelemetryConfig + MQTT	ClickHouse	5 с flush	production
Retention Cleanup	StoragePolicy	ClickHouse DELETE	1 ч	production
APC Controller	OperationalData	APC setpoints	60 с	beta
APC Simulator	Process model	Simulated data	1 с	beta
API Gateway	JWT tokens	Proxied requests	--	production
Doc Parser	PDF/DOCX	Extracted data	on demand	beta
Diagnost	Raw signals	Spectra, defects	on demand	production
RAG Index	AAS data	ChromaDB vectors	on demand	beta

Добавление нового сервиса

Используйте шаблон services/_templates/SERVICE_README.md и файл projects/STRIX_PRODUCTS/services.json для регистрации нового сервиса в каталоге платформы. После регистрации запустите python aas_loader/add_service_links.py для создания ServiceComponent shell в BaSyx.

Трёхуровневая модель данных

Сервисы работают с данными на трёх уровнях:

Уровень	Хранилище	Частота	Ретенция
Живые значения	BaSyx OperationalData	~1 Гц	последнее значение
История	ClickHouse (raw / 1min / 1hour)	5 с flush	7 дн / 90 дн / 2 года
Сырой сигнал	S3 Parquet (IDTA 02008)	25+ кГц	по StoragePolicy

Политика хранения настраивается через субмодель StoragePolicy на уровне facility shell. Возможны переопределения по типу оборудования и отдельным параметрам.

Схема взаимодействия

Все вычислительные сервисы читают данные из BaSyx и записывают результаты обратно в BaSyx. Ни один сервис не общается с другим напрямую — только через субмодели AAS.