ТЗ на диспетчеризацию здания (SCADA): состав и пример

Начните с задач эксплуатации

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

Например: увидеть, какая установка остановилась; отличить аварию оборудования от потери связи; проверить изменение температуры за смену; изменить разрешённую уставку; выяснить, кто и когда переключил режим. Эти задачи определяют состав сигналов, экранов и архивов.

Если задача сформулирована только как «красивые мнемосхемы», важные функции легко останутся за пределами предложения. Удобство интерфейса нужно проверять на действиях диспетчера.

Разделите SCADA, контроллеры и комплектную автоматику

Программируемый логический контроллер — ПЛК — выполняет назначенные ему алгоритмы рядом с оборудованием. Местная панель позволяет наблюдать и управлять на объекте. SCADA объединяет информацию и разрешённое управление на верхнем уровне. В конкретной системе функции могут распределяться по-разному; это распределение и нужно записать.

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

Контуры регулирования и необходимые защиты оборудования проектируют с учётом требуемой автономности. Их нельзя молча переносить на обычное рабочее место оператора или считать обеспеченными только потому, что на экране есть кнопка. Отдельные специализированные системы, включая противопожарные, сохраняют собственные требования и границы управления; их отображение в SCADA не заменяет предусмотренную автоматику.

В задании также разделяют исполнителей. Кто разрабатывает или меняет программу ПЛК? Кто предоставляет таблицу обмена комплектного агрегата? Кто проектирует и поставляет шлюз, прокладывает сеть, настраивает сервер и проверяет оборудование? Фраза «подключить по протоколу» не отвечает на эти вопросы.

Если местной панели достаточно для задачи, верхний уровень не нужно добавлять формально. Отличия и варианты размещения разобраны в статье о панели оператора Weintek.

Новое и действующее здание: с чего начать ТЗ на SCADA

Состав требований к экранам, командам, тревогам и архивам нужен в обоих случаях. Различаются исходные данные и путь к работающей системе. В новом здании оборудование ещё предстоит выбрать и установить. В действующем часть оборудования уже работает, но её возможности и документация требуют проверки. Наличие SCADA на существующем объекте не предполагается: это может быть и первое объединение отдельных щитов в диспетчеризацию.

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

Новое здание: предусмотреть диспетчеризацию в проекте

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

Например, требование видеть температуру означает, что нужно определить место измерения, датчик, способ подключения и передачу значения. Требование видеть положение клапана — согласовать соответствующую обратную связь. Надпись «насос работает» требует выбранного подтверждающего признака. Одной переменной в программе SCADA для этого недостаточно.

Сначала заказчик и проектировщики определяют, какие системы объединяются, какие параметры нужны персоналу и какие команды допускаются. Затем проект автоматики распределяет функции между датчиками, исполнительными устройствами, ПЛК, комплектными агрегатами и верхним уровнем. Из этого появляются требования к оборудованию, сети, электропитанию и размещению.

На этом этапе можно оценить число систем и рабочих мест, состав функций и предварительный объём сигналов. Адреса регистров и точную комплектацию интерфейса уточняют после выбора оборудования. При этом нужные данные и команды следует включить в требования к закупке заранее: иначе поставщик может предложить исправный агрегат, который не предоставляет нужную функцию диспетчеру.

Действующее здание: проверить автоматику и определить доработки

При создании или модернизации диспетчеризации в существующем здании сначала проверяют актуальность исходной документации: она может описывать проектное решение, которое отличается от фактически установленной и работающей системы. Техническое задание должно опираться на проверенное состояние объекта. В одном из полученных ТЗ указано, что проекты контроллеров отсутствуют, рабочая документация частично расходится с объектом, а несколько установок нужно вернуть в работу. В таком случае стоимость «подключения к SCADA» невозможно определить по одному перечню оборудования.

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

Полезный первый результат обследования — ведомость расхождений: что написано в документации, что найдено в щите, что проверено в работе и какое решение требуется. По ней заказчик видит, где нужна только настройка SCADA, а где необходимы ремонт, замена полевого оборудования или доработка автоматики. Эти работы можно оценивать отдельно, не пряча их под словом «интеграция».

После обследования обновляют перечень систем и точек. Статус «обнаружено в старом архиве» не равен статусу «доступно с действующего контроллера». Это особенно важно при расширении системы, которая много лет изменялась без полного обновления проекта.

Для работающего объекта в ТЗ также фиксируют ограничения на остановки: какие системы должны продолжать работу, когда допустимо переключение, кто согласует отключения и как сохраняются необходимые функции на время изменений. Если заменяют прежнюю SCADA, отдельно определяют перенос настроек и нужной истории, а также действия при неудачном переключении.

На одном объекте могут сочетаться оба сценария: например, существующая насосная и новая вентиляционная установка. Для новых узлов требования задают проектом, для действующих — подтверждают обследованием. Их объединяют общими обозначениями, таблицей сигналов и согласованными правилами управления.

Как связать вентиляцию, автоматику, электроснабжение и SCADA

Диспетчеризация собирает информацию из разных систем, поэтому её функции согласуют со смежными разделами. При новом строительстве это делают в процессе проектирования. На действующем объекте проверяют существующие связи, восстанавливают недостающие сведения и оформляют изменения затронутых систем.

Для обоих случаев полезна общая таблица: какой раздел задаёт функцию, где возникает сигнал, кто обеспечивает подключение и в каком документе это отражено. Обозначения комплектов и распределение работ принимают по конкретному проекту; автоматика отопления и вентиляции (АОВ) и другие разделы ниже служат привычными примерами.

Один агрегат должен сохранять одинаковое обозначение на схеме ОВ, в проекте автоматики, спецификации, таблице сигналов и на мнемосхеме. Если П1 переименовали, перенесли или заменили, изменение проверяют во всех затронутых документах. Иначе программист, монтажник и заказчик могут работать с разными версиями одной системы.

Почему «комплектная автоматика» не закрывает кабели и подключение

Запись «установка с комплектной автоматикой» нужно раскрыть по составу. Поставщик может включить контроллер и внутреннюю проводку агрегата, а наружные датчики, кабели к внешним приводам, связь со SCADA и питающую линию оставить за пределами поставки. Это проверяют по предложению и документации выбранного оборудования.

Для установленного агрегата сверяют ту же границу по фактическому подключению: что уже выполнено, что можно использовать дальше и какие линии или модули потребуется добавить. Наличие контроллера в щите само по себе не подтверждает готовность подключения к SCADA.

Для каждого внешнего подключения нужны начало и конец линии, назначение, ответственная сторона и место в документации. Кабели от приборов и приводов до щита, питание, сеть от щита до шлюза или коммутатора, подключение удалённой панели — разные позиции. Их марки, сечения, исполнение и количество определяют по условиям проекта и трассам. Если отдельного комплекта АОВ нет, эти работы всё равно должны попасть в назначенный раздел, спецификацию и объём монтажа.

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

Как уточнять таблицу сигналов до разработки и приёмки

Таблица сигналов проходит путь от требуемых функций к подтверждённым данным и испытаниям. Для нового и действующего объекта удобно выделить четыре контрольных момента:

1. Когда определяют функции: записать требуемые измерения, состояния, команды, единицы и назначение каждого сигнала. Для нового оборудования указать, какой раздел предусматривает его источник. Для действующего — что уже подтверждено обследованием и что нужно добавить или проверить.
2. Когда подтверждают техническое решение: для закупаемого агрегата согласовать данные, команды, интерфейс и дополнительные модули до заказа. Для установленного — проверить возможности его фактической модели, версии программы и подключения; определить состав доработки. Для BACnet можно запросить PICS — описание реализованных возможностей протокола; отдельно нужен перечень точек самого агрегата.
3. При согласовании рабочей документации: сопоставить таблицу с выбранной автоматикой и описанием обмена, схемами подключений, сетью, питанием и спецификациями. Окончательные адреса и настройки закрепить по документации выбранной версии оборудования и согласованной конфигурации.
4. На приёмке после подключения: проверить значения и команды на фактическом оборудовании, отметить результат испытаний и передать окончательную таблицу вместе с исполнительными материалами. Это относится и к новой поставке, и к подключённым существующим установкам.

Если нужный параметр или команда не поддерживаются, для нового оборудования решение принимают до заказа, для действующего — включают согласованную доработку в объём работ. Это может быть дополнительный датчик, интерфейсный модуль, изменение автоматики или другой способ реализации функции. Замена модели оборудования требует повторной проверки её влияния на смежные разделы и разработку SCADA.

Перечень оборудования и таблица сигналов

Сначала составляют перечень систем: обозначение, местоположение, назначение, выбранный или требуемый тип контроллера и комплектной автоматики, интерфейс и ответственная сторона. Для нового здания этот перечень увязывают с проектом, для модернизации — с результатами обследования. Затем составляют таблицу сигналов. Тегом в SCADA обычно называют переменную, связанную с измерением, состоянием, командой или вычисляемым значением.

У каждого сигнала должны быть понятны источник, смысл, тип данных, единицы измерения, диапазон и направление обмена. Для чтения задают нужную актуальность; для записи — допустимые значения и условия. Отдельно отмечают архивирование, тревоги и отображение.

Команда «Пуск» и сигнал «Работает» — разные данные. Запись команды не доказывает, что двигатель запустился. А состояние, вычисленное из команды в программе, нельзя подписывать как физическое подтверждение, если такого подтверждения нет.

Ниже — учебный фрагмент для условной приточной установки П1. Обозначения придуманы для объяснения; это не готовая карта регистров или проект конкретного щита.

В окончательной таблице помимо видимой подписи нужны технический идентификатор и адрес. Для одной платформы это будет адрес регистра, для другой — идентификатор узла или объекта. До выбора оборудования можно зафиксировать требуемую функцию без выдуманного адреса; перед настройкой обмена таблица должна позволять связать экран с конкретным источником без догадок программиста.

Показательный пример из заказного ТЗ: состояния пускателей некоторых насосов сведены попарно на один вход. Диспетчер видит работу пары, но не может установить, какой насос включён. Если в новом ТЗ написать «показать каждый насос отдельно», две иконки на экране проблему не решат. Нужны два различимых источника данных и проверка подключения; а сигнал пускателя следует назвать именно состоянием пускателя, если фактический расход или работу насоса он не подтверждает.

Проверяемая формулировка для подобной задачи: «Отображать состояние пускателя каждого насоса по отдельному сигналу. При отключении одного насоса состояние второго остаётся самостоятельным и достоверным; изменение обоих состояний фиксируется в журнале». Если отдельных сигналов в щите ещё нет, их получение и подключение указывают как часть работ до настройки экрана.

Так же проверяют требование показать «аварию завесы» или другого комплектного агрегата. Сначала выясняют, предоставляет ли он отдельный контакт либо доступное сообщение по интерфейсу. Если нет, отдельно согласуют возможный косвенный контроль, например температуры или питания. Его нельзя подписать на экране как внутреннюю неисправность агрегата, которую источник не сообщает.

Как посчитать объём сигналов

Дальше перечень сопоставляют с правилами выбранной платформы. Количество строк таблицы, физических входов ПЛК, внешних точек SCADA, архивируемых переменных и объектов на экране может различаться. Поэтому фраза «лицензия на 300 сигналов» без определения того, что считается сигналом, недостаточна.

Что согласовать по протоколам и щитам автоматики

Наличие Ethernet-разъёма не подтверждает возможность нужного обмена. Даже одинаковое название протокола у двух устройств не означает, что доступны все необходимые данные и команды.

Для подключения запрашивают описание интерфейса, таблицу данных, версии оборудования и программ, ограничения на чтение и запись. Для Modbus, например, проверяют адресацию, типы данных, масштабирование и порядок слов в многорегистровых значениях. Для OPC UA — доступные узлы, типы, качество и временные метки. Для BACnet — необходимые объекты и доступные операции, включая правила записи там, где они применяются.

Если поставщик передаёт температуру числом 235 с масштабом 0,1, на экране должно появиться 23,5 °C. Без согласованного масштаба связь может технически работать, а данные — выглядеть правдоподобно и оставаться неверными.

Для существующего щита отдельно проверяют право и техническую возможность изменения программы, доступность проекта, свободные интерфейсы и ресурсы контроллера. Иногда достаточно настроить обмен. В другом случае нужны шлюз, изменения программы или дополнительные физические сигналы. Это разные объёмы работ.

Для нового щита требования к обмену входят в задание на его проектирование и изготовление. В состав поставки включают необходимые интерфейсные модули и документацию; разработчик программы ПЛК и разработчик SCADA согласуют данные, команды и поведение при нарушении связи. Нужный протокол проверяют в выбранной комплектации, а не только по названию серии контроллера.

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

Опишите результат отдельно для каждой инженерной системы

Заказчики нередко перечисляют вентиляцию, тепловые завесы, насосы, ИТП и холодоснабжение в одном задании. Общая фраза «вывести все системы» не показывает, где достаточно наблюдения, где требуется команда и есть ли для неё сигнал и исполнительный механизм.

Для каждого требования удобно ставить один из статусов: входит в согласованный объём, зависит от проектного решения, обследования или данных поставщика, требует отдельного решения. Рядом указывают, кто предоставляет доступ или исходные данные и когда принимается решение. Так условная возможность не превращается незаметно в обещание подрядчика.

Особенно важно отделить контроль параметра от управления процессом. Если заказчик просит передать на экран температуру трубопровода, наличие датчика ещё не означает право SCADA управлять насосом или клапаном. Такие функции добавляют только с описанием алгоритма и границ ответственности действующей автоматики.

Пример фрагмента ТЗ на диспетчеризацию вентиляции

Фраза «сделать диспетчеризацию вентиляции» не позволяет оценить работу и принять её результат. Ниже — учебный фрагмент ТЗ для условной приточной установки П1. Он подходит для нового и действующего здания: сначала фиксируют исходное состояние и путь подключения, затем — общие требования к работе системы.

По такой записи можно определить объём проектирования или доработки, распределить поставку, монтаж и настройку SCADA, а затем проверить работу П1. Аналогичный фрагмент составляют для каждой различающейся системы; одинаковые установки можно объединить типовым решением с перечнем отличий.

Как должна работать команда с экрана

Для команды описывают цепочку: оператор запросил действие → система проверила полномочия и условия → запрос принят контроллером → получено подтверждение результата либо понятная причина отказа.

На примере пуска установки нужно определить:

1. Разрешён ли дистанционный режим и кто имеет право запуска.
2. Какие блокировки проверяет автоматика и что видит оператор при запрете.
3. Как контроллер подтверждает получение запроса.
4. По какому отдельному сигналу определяется фактическая работа.
5. За какое согласованное время должен появиться результат и что происходит при его отсутствии.

Кнопка не должна окрашивать оборудование в состояние «работает» только потому, что по ней нажали. Оператору полезно различать запрос, ожидание подтверждения, фактическое состояние и отказ.

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

Для групповой команды, например остановки нескольких приточных и вытяжных установок одним действием, нужна отдельная строка ТЗ: точный состав группы, полномочия оператора, приоритет местного управления, взаимодействие с существующими защитами, подтверждение остановки по каждой установке и порядок обратного запуска. Одна большая кнопка на мнемосхеме не определяет поведение оборудования. Если установки должны останавливаться совместно при неисправности одной из них, перечисляют группы и конкретные условия такой связи.

Тревоги, события и квитирование

Тревога сообщает о состоянии, требующем реакции. Событие фиксирует произошедшее: смену режима, вход пользователя, изменение уставки или восстановление связи. Не каждое событие нужно сопровождать звуком, иначе важные сообщения потеряются среди обычных действий.

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

Квитирование означает, что оператор подтвердил получение тревоги. Оно само по себе не устраняет неисправность и не должно подменять сброс защиты. Состояния «причина ещё действует», «причина устранена» и «оператор подтвердил» нужно различать.

Пример понятной записи: «П1. Нет подтверждения работы вентилятора после команды пуска». Она сообщает объект и наблюдаемое несоответствие. Надпись «Авария 17» полезна только вместе с доступной расшифровкой и привязкой к месту.

В ТЗ определяют, какие тревоги требуют звука, какие передаются выбранным получателям и что происходит при недоступности канала уведомлений. Отправка сообщения и подтверждённое ознакомление человека — разные результаты. Состав внешних уведомлений согласуют отдельно от отображения на автоматизированном рабочем месте (АРМ).

Фраза «сообщить аварии на телефон» требует уточнений: какая именно авария, кому она передаётся по сменам, кто ведёт список получателей, как увидеть результат доставки и что делать, если основной получатель недоступен. Проверяют и обратную сторону: устранение причины на оборудовании должно отразиться в журнале независимо от того, прочитал ли человек сообщение.

Какие экраны действительно нужны оператору

Вместо неопределённого количества мнемосхем составляют перечень экранов с назначением каждого.

• Обзор объекта: какие системы работают, где есть действующие тревоги и где потеряна связь.
• Экран установки: фактические состояния, параметры, режим, разрешённые команды и причины блокировок.
• Тревоги: активные сообщения, подтверждение, фильтры по зоне и переход к оборудованию.
• Тренды: выбранные параметры на общей шкале времени с понятными единицами.
• Журнал действий: кто менял режимы и уставки, что было задано и чем закончился запрос.

На мнемосхеме важны различия между остановкой, отсутствием питания, местным управлением и потерей данных. Цвет дополняют текстом или понятным символом. Старая зелёная индикация при потерянной связи не должна выглядеть как достоверное текущее состояние.

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

Архивы: что сохранять и с какой подробностью

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

Период опроса устройства, обновление экрана и запись в архив — три разные настройки. Быстрое обновление цифры на экране не доказывает, что с такой же подробностью сохраняется история.

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

На графиках важно отличать измерение от интерполяции и отсутствие данных от нуля. Если счётчик временно недоступен, нулевое потребление не следует автоматически из отсутствия связи.

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

В одном из заданий на доработку диспетчеризации заказчик отдельно просил исправить ситуацию, когда установки переходили между летним и зимним режимами в разное время. Поэтому для расписаний и сезонных режимов в ТЗ указывают, где хранится расписание, какой источник времени используют контроллеры и сервер, кто меняет календарь и как проверяется переключение на всех затронутых установках. Поправить время только на рабочем компьютере может быть недостаточно.

Что произойдёт при потере связи или остановке сервера

Этот раздел полезно прорабатывать до выбора резервирования. Нужно определить, какие функции требуются при каждом отказе и сколько времени допустимо оставаться без них.

Буфер перед записью в базу помогает при недоступности самой базы. Но он не восстановит значения, которые SCADA вообще не получила из-за разрыва связи с контроллером. Для этого накопление должно происходить у доступного источника, а протокол и программа — поддерживать последующую передачу.

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

Резервный сервер также не закрывает автоматически отказ единственного коммутатора, источника питания или общей базы. В задании называют конкретный отказ, допустимый перерыв и допустимую потерю данных. Проверяют именно это сочетание.

Права пользователей и доступ к системе

Полномочия удобнее задавать по действиям. Наблюдателю доступен просмотр; диспетчеру — согласованные команды и квитирование; инженеру — разрешённые настройки; администратору — управление системой. Это пример разделения, который уточняют под службу эксплуатации.

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

Архитектуру сети, разделение доступа, обновления и резервное копирование увязывают с требованиями владельца объекта. Обновление должно иметь понятный порядок проверки и возврата. Конкретная схема зависит от платформы и инфраструктуры, но оставить этот объём неопределённым в ТЗ означает перенести решение на момент эксплуатации.

Серверы, лицензии и смежные работы

В состав поставки могут входить серверы, операторские места, сетевое оборудование, шлюзы, ИБП, программные лицензии и средства резервного копирования. Для каждой позиции указывают, поставляется она подрядчиком или предоставляется заказчиком.

В программной части проверяют архитектуру исполнения, число клиентов, драйверы, внешние точки, архивирование, отчёты и резервирование. Ограничения драйвера могут отличаться от ограничений самой SCADA. Отдельно уточняют среду разработки, условия переноса и восстановления лицензий, обновления и расширение системы. Актуальную комплектацию подтверждают для выбранного продукта.

Не стоит ограничивать предложение строкой «SCADA — 1 комплект». Полезнее видеть, что включено: исходные данные и обследование при необходимости, проектирование и согласование смежных разделов, экраны, разработка или изменение ПЛК, интеграция, испытания, документация и обучение. Кабельная сеть, серверная инфраструктура и внешние интерфейсы должны иметь своего исполнителя, даже если часть работ лежит за рамками договора разработчика.

В одном заказном ТЗ кабель от контроллера до рабочего места прокладывает сам заказчик. Это вполне рабочая граница, если её указать вместе с точками подключения, сроком готовности и проверкой линии. Иначе разработчик ожидает готовый канал, заказчик — смонтированную систему, а связь между ними отсутствует. Тем же способом распределяют питание и ИБП, доступ в действующую сеть, получение программы ПЛК, ремонт щита и связь с комплектными установками.

Как прописать приёмку: проверять действия и отказы

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

Для нового здания проверку начинают ещё с проекта: у каждой функции должны быть источник, алгоритм, интерфейс и предусмотренное подключение, а в спецификациях и объёмах работ — её оборудование и линии. До закупки проверяют подтверждение поставщика. После монтажа проверяют реализацию этой цепочки на объекте. Принятие проектных решений и приёмка работающей системы — разные результаты, оба полезно закрепить в ТЗ.

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

Стендовые испытания до выезда часто называют FAT, проверку на объекте — SAT. На стенде можно проверить интерфейс, права и многие сценарии. Физические сигналы, реальную сеть, работу оборудования и границы смежных систем проверяют на объекте. Имитацию обозначают в протоколе; она не становится свидетельством фактического срабатывания оборудования.

Что передают после разработки

Для эксплуатации и дальнейшего развития нужны не только ярлык программы и пароль оператора. Состав передачи закрепляют в ТЗ:

• редактируемый проект SCADA и относящиеся к работе проекты ПЛК, если их разработка или изменение входят в объём;
• согласованную проектную документацию в пределах работ, окончательные таблицы сигналов, интерфейсов, экранов и тревог;
• относящиеся к работам исполнительные схемы подключений и сети, спецификации и кабельные журналы с фактическими изменениями;
• описание алгоритмов, прав, архивирования и поведения при отказах;
• состав оборудования, программ и лицензий с версиями и условиями восстановления;
• резервные копии и проверенная инструкция восстановления;
• инструкции для диспетчера и обслуживающего инженера, результаты испытаний и обучение;
• перечень остающихся замечаний, согласованные условия поддержки и порядок изменений.

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

От чего зависят стоимость и срок разработки SCADA

Количество экранов и сигналов влияет на трудоёмкость, но не объясняет её полностью. Подключить десять одинаковых контроллеров с проверенной таблицей обмена и десять разных старых устройств без исходных проектов — разные задачи.

На объём также влияют команды и блокировки, детализация тревог, отчёты, миграция истории, резервирование, требования к доступу, число площадок, готовность смежных разделов и доступность оборудования для испытаний. Повторно используемый типовой экран сокращает часть работы, но не отменяет проверку адресации и функций каждой установки.

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

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

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

Нужно ли оформлять ТЗ на SCADA по ГОСТ 34.602-2020

ГОСТ 34.602-2020 действует в России и устанавливает требования к составу, содержанию и оформлению технического задания на создание, развитие или модернизацию автоматизированной системы. Если для проекта требуется ТЗ на АС по этому стандарту, инженерные требования к SCADA включают в оформленный документ вместе с остальными разделами. Приведённый выше фрагмент показывает, что проверить на установке и как принять функцию, но не заменяет полный документ для конкретного объекта.

Требование «по ГОСТ» само по себе не определяет, откуда взять сигнал работы насоса, кто проектирует или меняет ПЛК и какой отказ испытывать на объекте. Эти решения всё равно нужно согласовать по проектируемой или действующей системе и закрепить в ТЗ и приложениях к нему.

Короткая структура задания для своего объекта

Рабочее ТЗ можно собрать в следующем порядке:

1. Объект, пользователи и задачи эксплуатации.
2. Перечень систем и исходные данные: схемы нового здания либо состояние действующего оборудования и результат обследования.
3. Связи со смежными разделами, границы проектирования, поставки и монтажа, исходные данные от каждого исполнителя.
4. Архитектура: ПЛК, панели, SCADA, сеть и внешние системы.
5. Таблица сигналов, команд и описания интерфейсов со статусом: проектное требование, подтверждение поставщика, проверка на оборудовании.
6. Режимы управления, приоритеты и сценарии одиночных и групповых команд.
7. Тревоги, события, уведомления и действия персонала.
8. Экраны и операции, которые оператор выполняет на каждом.
9. Архивы, тренды, отчёты, расписания и работа со временем.
10. Права, удалённый доступ, отказные режимы и восстановление.
11. Оборудование, внешние подключения и кабели, лицензии, этапы проверки проекта и системы, комплект передачи.

У каждой существенной строки должны быть ответственный за исходные данные и способ проверки результата. Если параметр пока неизвестен, его оставляют открытым вопросом с понятным способом определения, а не заполняют произвольной цифрой.

В работе по диспетчеризации инженерных систем AERO такое задание связывает оборудование, разработку и эксплуатацию. Оно помогает оценить объём до начала программирования и затем принять именно те функции, ради которых создавалась система.

Пришлите задание на проектирование или материалы действующего объекта и задачи диспетчера — обсудим состав ТЗ, связи со смежными системами и границы разработки для вашего объекта.