UMEC Space Wiki | Автоматизация

Главная модель

Каждый сценарий состоит из условий и действий. Условие отвечает на вопрос "когда сработать", действие - "что сделать". Важная особенность текущего интерфейса: источник всегда должен быть привязан к конкретной линии, чтобы RTU 1, RTU 2 и TCP не смешивались.

flowchart LR
    A[Канал устройства] --> B[Условие]
    B --> C{Результат}
    C -->|нет| D[Ждать следующей проверки]
    C -->|да| E[Действие]
    C -->|unknown| H[Сохранить последнее достоверное состояние]
    H --> D
    E --> F[Команда устройству]
    F --> G[Запись в Журнал автоматизации]

Поля сценария

Поле	Назначение	Практический совет
Name	Понятное имя правила.	Используйте имя по действию: "CO2 high - ventilation boost".
Logic	AND требует выполнения всех условий, OR - хотя бы одного.	Для аварий часто подходит OR, для точной комбинации - AND.
Режим	Определяет повторяемость: persistent, one-shot или multiple.	Для постоянного поддержания состояния используйте persistent, для одиночного события - one-shot.
Negate	Инвертирует результат условия.	Используйте осторожно: инверсия усложняет чтение правила при обслуживании.
Enabled	Разрешает или запрещает выполнение правила.	Отключайте правило перед изменением критичных действий.

Отсутствующее, устаревшее, offline или ошибочно прочитанное условие делает всю оценку unknown для AND, OR и Negate. В этом состоянии действия подавляются, а флаги prev_state и executed не меняются. Паузы scanner/service/BLE действуют так же. После восстановления правило сравнивается с последним достоверным состоянием, поэтому не возникает ложного фронта или повторного one-shot.

Как создать рабочее правило

Опишите цель простыми словами Например: "Если CO2 выше 1200 ppm, включить усиленную вентиляцию на устройстве VF51".

Выберите источник условия Укажите линию, устройство и канал. Проверьте, что канал уже стабильно обновляется в ModBus.

Задайте порог Используйте инженерные единицы, которые видит оператор, а не внутреннее представление регистра.

Выберите действие Укажите линию, устройство и команду. Для TCP-канала убедитесь, что маршрут разрешается однозначно.

Сохраните и включите После сохранения проверьте Enabled и дождитесь записи в Журнал автоматизации при тестовом срабатывании.

Журнал автоматизации

Журнал автоматизации - главный источник доказательств по автоматизации. Если оператор говорит "правило не сработало", сначала смотрите не JSON и не код, а журнал: было ли условие истинным, пыталось ли устройство выполнить команду, был ли отказ маршрута или недоступность линии. Поля evaluation_state и состояния отдельных условий различают обычный false и безопасный unknown; повторяющийся unknown не создаёт запись на каждом цикле.

Обзор журнала

Журнал автоматизации обзор на русском языке.

Журнал показывает историю выполнения и помогает отделить ошибку условия от ошибки действия.

Подробная запись

Журнал автоматизации execution entry на русском языке.

Подробности записи нужны для поддержки: источник, результат, действие и причина отказа.

Типовые ошибки

Симптом	Вероятная причина	Что проверить
Сценарий не срабатывает.	Условие не становится истинным или правило отключено.	Enabled, Logic, порог, свежесть канала в ModBus.
Условие сработало, но команда не выполнена.	Устройство недоступно, команда неверна или маршрут TCP неоднозначен.	Журнал автоматизации, ModBus command, настройки TCP tunnel/NAT.
Правило срабатывает слишком часто.	Порог близок к шумящему значению или выбран неподходящий mode.	Тренд канала, hysteresis в логике объекта, mode сценария.
После изменения устройства сценарий стал вести себя иначе.	Канал или команда были переименованы/удалены.	Конфигурация, Template Formats, Журнал автоматизации после первого запуска.

Локальные сценарии без участия облака