Что передать инженеру до разработки PLC/SCADA

Цель и границы системы

Сначала описываются as-is и требуемое to-be: какие установки, шкафы, механизмы и интерфейсы входят в проект. Отдельно фиксируются функции PLC, HMI/SCADA, локальных устройств и внешних систем, а также намеренные исключения.

Минимальный артефакт — одностраничная схема границ и перечень «в объёме / вне объёма». Он защищает обе стороны от незаметного расширения задачи.

• роль оператора, технолога, наладчика и администратора;
• допустимые остановы и время восстановления;
• ответственные за технологические решения;
• площадки и работы, требующие отдельной договорённости.

Технологические документы и редакции

Нужны актуальные PFD/P&ID или функциональные схемы, перечень оборудования, Instrument Index, I/O List, электрические схемы, паспорта приборов и приводов, cause-and-effect и описание существующей системы.

Для каждого файла фиксируются номер, редакция, дата, статус и владелец. Файл без источника нельзя автоматически считать утверждённым требованием.

Режимы, состояния и последовательности

Фраза «насос работает автоматически» недостаточна. Нужны режимы Off/Manual/Auto/Maintenance, условия пуска и останова, безопасное начальное состояние, допустимые переходы, отмена операции и поведение после пропадания питания или восстановления связи.

Для сложных функций применяются state diagram, sequence table или control narrative. Permissive, interlock и trip описываются раздельно.

• что запрещает старт;
• что останавливает уже работающий объект;
• что фиксируется до reset;
• что может восстановиться автоматически;
• какие override допустимы и кем.

Сигналы и качество данных

Для тега задаются обозначение, владелец, тип, диапазон, единица, масштабирование, фильтрация, normal/fail state, диагностика и потребители. Для сетевых данных добавляются timeout, stale, timestamp и реакция на Bad/Uncertain.

Уставки, deadband и задержки имеют технологический источник и ответственного. Тогда одно и то же значение одинаково понимают PLC, HMI, архив и тест.

SCADA, сеть и внешние интерфейсы

Требования к SCADA описывают задачи пользователя: обзор, команды, права, faceplate, alarm/event, trends, reports, audit и quality. Для каждого интерфейса фиксируются протокол, роли client/server, адреса, read/write-права, период, timeout, reconnect и версия контракта.

Фразы «передать в MES» или «подключить по OPC» не задают проверяемого результата.

• состав и направление данных;
• единицы и кодировки;
• heartbeat и контроль устаревания;
• NTP/PTP, timezone и timestamps;
• сертификаты и порядок сопровождения.

Состав передачи и приёмка

До старта согласуются нативные проекты, внешние SCL/XML/CSV, I/O mapping, версии, архитектура, backup оборудования и сети, FAT/SAT, известные ограничения и change log.

Критерий приёмки должен быть наблюдаемым: не «удобный экран», а, например, «оператор определяет причину запрета пуска без watch table».

Реестр неопределённостей: TBD, допущения и противоречия

Не все пробелы в исходных данных одинаковы. TBD означает, что решение ещё не принято; допущение — временную рабочую гипотезу; противоречие — конфликт между двумя источниками; RFI — формализованный вопрос владельцу данных. Если свести их к обычным комментариям, временная догадка может незаметно стать постоянной частью алгоритма.

В рабочем реестре для каждого пункта полезно указывать ID, затронутую функцию, источник вопроса, возможное влияние, владельца решения, срок и временный вариант. При выпуске очередной baseline открытые пункты пересматриваются: закрытое решение должно попасть не только в протокол, но и в связанную документацию, код и тесты.

• TBD — решение отсутствует, назначены владелец и срок;
• ASSUMPTION — гипотеза явно помечена и требует подтверждения;
• CONFLICT — перечислены противоречащие редакции или источники;
• RFI — вопрос сформулирован так, чтобы ответ можно было превратить в проверяемое требование.

Карточка механизма вместо набора разрозненных тегов

Для насоса, клапана, привода или нагревателя удобно собрать одну функциональную карточку. В ней связываются назначение механизма, команды, обратные связи, режимы, стартовые разрешения, работающие блокировки, защитные реакции, диагностика, времена ожидания, действия после отказа и элементы HMI. Такая карточка становится общей точкой проверки для технолога, электрика, разработчика PLC и автора SCADA.

Например, наличие команд Start и Stop ещё ничего не говорит о готовности агрегата. Нужны источник режима Local/Remote, подтверждение работы, состояние силовой части, допустимость повторного пуска, реакция на отсутствие обратной связи и поведение после восстановления питания. Конкретные реакции и выдержки берутся из утверждённого алгоритма, анализа риска и документации изготовителя.

• сигнал или команда → физический источник → владелец данных;
• нормальное состояние → состояние при обрыве или потере связи;
• режим применимости → задержка → условие фиксации и сброса;
• отображение в HMI → запись в журнал → приёмочный тест.

Матрица ответственности за исходные решения

Разработчик может обнаружить противоречие и предложить технический вариант, но это не делает его владельцем технологической уставки или допустимого состояния процесса. Для спорных данных полезна компактная матрица: кто предоставляет значение, кто подтверждает технологический смысл, кто реализует, кто проверяет и кто принимает результат.

Предложение подрядчика отмечается как proposed, пока уполномоченная сторона не зафиксирует решение. Это особенно важно для alarm priority, уставок, задержек, permissive, interlock, trip, прав пользователей и write-доступа к внешней системе. История решения сохраняется вместе с редакцией документа, а не только в переписке.

• владелец процесса подтверждает требуемое поведение;
• владелец оборудования подтверждает ограничения изготовителя;
• разработчик подтверждает реализуемость и влияние на архитектуру;
• приёмочная сторона утверждает способ проверки результата.

Вертикальный срез до массовой разработки

До тиражирования типового блока на десятки механизмов полезно пройти один представительный объект по всей цепочке: исходный сигнал, quality, PLC-логика, команда, диагностика, HMI, alarm/event, архив и FAT-сценарий. Такой вертикальный срез рано выявляет несовместимые обозначения, неясную семантику режима, отсутствующие статусы и расхождения между PLC и SCADA.

Результатом может быть согласованная карточка механизма, прототип faceplate, пример alarm message, набор тегов и несколько тестов. Это ещё не подтверждает готовность всей установки, но создаёт проверенный образец для дальнейшей разработки и позволяет оценить реальную стоимость изменения требований.

• штатная команда проходит от HMI до подтверждённого результата;
• запрет команды показывает оператору конкретную причину;
• потеря качества не маскируется под нормальное значение;
• событие и тренд можно связать с одним временем и тегом;
• тест ссылается на конкретную редакцию исходного требования.