Автоматика и диспетчеризация: какие сигналы согласовать
Диспетчерский экран не делает инженерные системы совместимыми. До закупки контроллеров нужно описать, какие события системы передают друг другу, кто принимает решение, что происходит при аварии или потере связи и как результат проверят на объекте.
Содержание статьи
Команда на вентилятор — ещё не подтверждённый пуск
Учебный непожарный сценарий: станок М-1 запрашивает местное удаление, контроллер отдаёт команду вытяжному вентилятору, а обратный сигнал должен подтвердить фактическую работу. В журнале оператора отдельно отображаются «команда отправлена» и «работа подтверждена». Зелёная кнопка или анимация вентилятора на экране без обратной связи не доказывают движения воздуха.
Для этого условного стенда технолог и проектировщик заранее согласовали правило: без подтверждения вытяжки станок М-1 не получает разрешения на пуск. Оператор видит «команда отправлена; работа не подтверждена», отмечает время и сообщает дежурному по инженерной системе и технологу. Он не включает станок принудительно через диспетчерский экран. Причину проверяют по питанию, состоянию вентилятора и обратному сигналу. Это правило учебного случая, не готовый алгоритм для любого производства; пожарные команды проектируют отдельно.
В учебном протоколе записаны версия алгоритма А-2, запрос М-1, отправленная команда, отсутствие подтверждения и запрет пуска. После исправления цепи обратной связи совместное испытание повторило весь путь: запрос → команда → подтверждённая работа → разрешение пуска. Оператор зафиксировал оба результата и только после закрытия замечания вернулся к штатному режиму. Диспетчеризация показывает и архивирует событие; её право управлять оборудованием определяется проектом и инструкцией.
Запрос, команда и обратная связь
Отображение команды и подтверждение фактической работы — разные состояния.
Разделите технологию, инженерные системы и пожарную защиту
Автоматизация станка или производственной линии управляет технологическим процессом. Инженерная автоматика ведёт вентиляцию, тепло, насосы и другие системы здания. Диспетчеризация собирает состояние и события, даёт оператору предусмотренные команды и хранит историю. Все эти контуры могут обмениваться данными, но один общий интерфейс не означает одну зону ответственности.
Пожарная сигнализация и автоматизация противопожарной защиты — отдельная нормативная функция со своими требованиями. Её нельзя проектировать как обычный сценарий системы управления зданием (BMS) и нельзя отдавать без проверки приоритетов произвольному контроллеру вентиляции. Для каждой связи пожарной и обычной автоматики укажите проектное основание, направление сигнала, безопасное состояние, подтверждение выполнения и процедуру испытания.
ГОСТ 21.408-2013 касается выполнения рабочей документации автоматизации технологических процессов, а СП 484.1311500.2020 — пожарной сигнализации и автоматизации противопожарной защиты. Ни один из них не является универсальной готовой схемой диспетчеризации любого цеха.
| Контур | Его задача | Что согласовать на границе |
|---|---|---|
| Технологическая автоматика | Режим и защита производственного оборудования. | Разрешения, блокировки, доступные сигналы и владелец алгоритма. |
| Инженерная автоматика | Управление системами здания. | Уставки, режимы, зависимость от технологии и электропитания. |
| Диспетчеризация | Наблюдение, журнал и разрешённые команды оператора. | Какие команды допустимы, как подтверждаются события. |
| Пожарная автоматика | Функции противопожарной защиты по профильному проекту. | Приоритеты, предусмотренные проектом сигналы и совместные испытания. |
Матрица взаимодействия: документ, которого часто не хватает
Для каждого события запишите источник, получателя, условие запуска, команду, ожидаемое подтверждение и поведение при отказе связи. Добавьте приоритет: местная ручная команда, технологическая блокировка, диспетчерская команда и сигнал пожарной защиты не должны спорить друг с другом в момент аварии. Конкретный порядок приоритетов задаёт применимый проект, а не название программного продукта.
В истории М-1 матрица разделяет запрос станка, команду контроллера и обратное подтверждение вентилятора. Отсутствие последнего сигнала не подменяют зелёной анимацией на экране. Для другой технологии правило запрета пуска может быть иным: его записывают до наладки, а не придумывают во время отказа.
Матрицу подписывают владельцы каждого раздела и обновляют вместе с программой, схемами и инструкцией оператору после изменения оборудования.
| Событие / сигнал | Источник → получатель | Подтверждение и отказ | Ответственный |
|---|---|---|---|
| Запрос рабочего режима | Технология → инженерная автоматика. | Статус принятия, заданное поведение при потере сигнала. | Технолог и разработчик инженерной автоматики. |
| Неисправность оборудования | Локальный контроллер → диспетчерская. | Понятный адрес, архив, порядок реакции оператора. | Поставщик оборудования и эксплуатация. |
| Пожарное событие | Профильная пожарная система → предусмотренные проектом исполнительные системы. | Подтверждение по проекту и отдельная совместная проверка. | Проектировщики пожарной и смежных систем. |
Что увидит оператор и что останется после смены
На экране нужны участок, система, агрегат, причина отклонения и действие по инструкции. Сигнал «авария» без адреса и времени не помогает дежурному. Уставка — заданное значение для управления, например температура; менять её может только разрешённая роль. Квитирование — отметка оператора «сигнал увидел», а не доказательство устранения причины. Эскалация — передача неустранённой тревоги назначенному специалисту по установленному времени и каналу. Архив сохраняет исходное событие, действия и восстановление связи.
Разделите право наблюдать, менять уставки, запускать оборудование и администрировать систему. Учётные записи, резервные копии конфигурации и журнал изменений согласуйте с эксплуатирующей службой. Если диспетчеризация собирает сведения о людях, отдельно определяют правовые основания и порядок обработки таких данных; обычная телеметрия оборудования не делает все данные персональными.
Проверьте время синхронизации журналов у разных систем. Без согласованных часов нельзя восстановить последовательность события: какая тревога была первой и какая команда последовала за ней.
Что согласовать до кабелей, шкафов и лицензий
Для каждого шкафа нужны место, питание, резерв при необходимости, теплоотвод, доступ и кабельные трассы. Для каждого протокола — совместимые версии, список точек, формат значений, скорость обновления и граница ответственности. Само слово «совместим с протоколом» не подтверждает обмен требуемыми командами и статусами.
Отдельно определите, кто предоставляет серверы, сеть, лицензии, инженерные учётные записи и доступ на время наладки; кто затем получает исходные проекты контроллеров и резервные копии. Если система закрыта без передачи конфигурации, заказчик окажется зависим от единственного подрядчика даже при исправном оборудовании.
| Смежник | Что даёт автоматике | Что получает обратно |
|---|---|---|
| Электроснабжение | Питание и подтверждённую схему резервирования. | Нагрузки шкафов и требования к переключению. |
| Вентиляция / тепло | Состав агрегатов, исполнительных механизмов и режимов. | Схемы управления, уставки, сигналы отказа. |
| Технология | Допуски процесса, блокировки и интерфейсы оборудования. | Алгоритмы согласованного запуска и остановки. |
| Эксплуатация / ИТ | Сеть, доступы, хранение и порядок обслуживания. | Архив, резервные копии, инструкции и учётные записи. |
Приёмка: проверить сценарий, а не только включение экрана
Программа проверки должна пройти нормальный режим, отказ датчика или связи, отключение питания, восстановление, запрет несанкционированной команды и пересечение сигналов двух систем. Испытание проводят на согласованном объектом безопасном режиме. Результат записывают по версии алгоритма и конфигурации, чтобы дефект можно было повторить и устранить.
Передача заказчику включает перечень точек, схемы, версии программ и настроек, права доступа, резервные копии, инструкции и обучение эксплуатационной смены. Открытый протокол испытания не закрывают фразой «исправлено»: нужен повторный результат. Отдельные профильные испытания пожарной защиты и пусконаладки оборудования выполняют по их применимым программам.
У каждой межсистемной команды есть владелец?
- Что проверить
- Подписанная матрица сигналов с источником, получателем и приоритетом.
- Следующий шаг
- Вернуть конфликт алгоритмов разработчикам разделов.
Известно безопасное состояние при отказе?
- Что проверить
- Алгоритм потери питания, датчика и связи для критичных режимов.
- Следующий шаг
- Не выпускать наладку на догадках монтажника.
Оператор сможет найти причину?
- Что проверить
- Экраны, адресные тревоги, архив времени, инструкция и права ролей.
- Следующий шаг
- Уточнить интерфейс до приёмки.
Переданы настройки для дальнейшей эксплуатации?
- Что проверить
- Экспорт проектов, лицензии, пароли по защищённой процедуре, резервные копии.
- Следующий шаг
- Зафиксировать состав передачи в договоре и акте.
Источники и проверка
Показать документы, на которые опирается статья
- ГОСТ 21.408-2013 — рабочая документация автоматизации технологических процессовОформление рабочих документов автоматизации технологического процесса.
- СП 484.1311500.2020 — пожарная сигнализация и автоматизация противопожарной защитыПрофильные требования к пожарной автоматике; не заменяются обычной диспетчеризацией.