Подключение объекта к централизованной системе мониторинга банка - что требует ЦСМ и почему локальная SCADA обычно не проходит

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

Такую задачу закрывает отдельный шлюз между существующей АСУ и централизованной системой мониторинга (далее ЦСМ), а вовсе не переделка самой АСУ. Ниже - почему локальная SCADA почти никогда не подключается напрямую, из чего состоит шлюз, что означает требование выделенного APN и справочника зон, и что нужно зафиксировать в техническом задании, чтобы объект приняли с первого раза. Фактура опирается на проект подключения административного здания крупного российского банка - четыре этажа, три серверные, отдельный контейнер ДГУ, действующая диспетчеризация на SCADA TRACE MODE.

Почему объект вообще нужно заводить в ЦСМ

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

Разница между «на объекте есть диспетчеризация» и «объект под наблюдением» лежит в организации работы, а не в технике:

• Событие видно только на месте. Локальный АРМ показывает аварию тому, кто в этот момент смотрит на экран в здании. Ночью и в выходные это никто.
• Нет единого регламента реагирования. У каждого объекта своя процедура, потому что нет общей точки, где инциденты сравниваются между собой и приоритизируются.
• Нет сопоставимой отчётности. Данные с разных зданий собраны в разных структурах, свести их в один отчёт по сети невозможно без ручной работы.
• Не работает превентивная аналитика. Тренды по расходу, наработке оборудования и частоте отказов имеют смысл на массиве объектов, а не на одном.

Отсюда и жёсткость требований ЦСМ: система принимает данные только в том виде, в котором их можно сравнивать между объектами. Это ключ ко всему остальному - большинство «странных» пунктов ТЗ объясняются именно требованием сопоставимости.

Почему локальную SCADA не подключают к ЦСМ напрямую

Коротко: между локальной АСУ и ЦСМ почти всегда расходятся три вещи - протокол, структура имён и требования к сети. Каждое расхождение по отдельности решаемо, вместе они дают отдельный узел - шлюз.

Разберём по порядку, потому что заказчик обычно ждёт, что «просто настроим передачу»:

• Протокол. ЦСМ принимает данные по MQTT. Локальная SCADA чаще собрана вокруг Modbus и OPC, а поддержка MQTT появляется только в свежих версиях или не появляется вовсе. В проекте по административному зданию банка это решилось обновлением программной среды TRACE MODE до седьмой версии с поддержкой MQTT, Modbus TCP и OPC - с конвертацией проекта и отладкой в новой инструментальной версии, но без перерисовки мнемосхем.
• Именование. Устройства на объекте называются исторически: ЩБП-1.1-ППК, ПР-К 2.10, ПВ-7. Эти имена понятны эксплуатации здания и бессмысленны для системы, которая собирает сотни объектов. ЦСМ требует, чтобы каждое устройство было привязано к коду зоны и типу из единого справочника - без этого данные просто не принимаются.
• Сеть. Требование обычно формулируется как «шлюз в изолированном сегменте, единственный маршрут - к ЦСМ». Локальный SCADA-сервер этому требованию не удовлетворяет по определению: он живёт в сети объекта и имеет связь с полевым уровнем.
• Ответственность за изменения. Даже если технически всё сошлось, привязка передачи данных прямо к SCADA означает, что каждое изменение в ЦСМ придётся отражать в проекте АСУ - то есть трогать работающую систему. Шлюз выносит эту зону в отдельный узел, где изменения безопасны.

Отсюда практический вывод: подключение к ЦСМ - это отдельный объект автоматизации со своим шкафом, своим питанием и своей документацией.

Из чего состоит шлюз

Коротко: свободно программируемый контроллер с локальным MQTT-брокером, маршрутизатор сотовой связи, резервное питание и отдельный шкаф. Архитектура получается трёхуровневой, где шлюз - верхний уровень, а существующая АСУ остаётся нетронутой.

Как это выглядит на практике:

Уровень	Что входит	Кто им владеет
Полевой	Датчики, счётчики качества электроэнергии, контроллеры вентиляции, плата управления ДГУ, SNMP-агенты ИБП, преобразователи интерфейсов	Объект, не меняется
Автоматизации	Контроллеры, щиты автоматизации, локальный SCADA-сервер	Объект, дорабатывается минимально
Управления	Контроллер-шлюз с MQTT-брокером, маршрутизатор LTE, резервное питание	Новый узел проекта

В проекте по зданию банка шлюз собран на свободно программируемом контроллере на ARM под Linux с маршрутизатором LTE, резервным питанием и монтажом в отдельном шкафу на DIN-рейку. Полевой уровень при этом остался как есть - контроллеры качества электроэнергии, контроллеры вентиляции, плата управления ДГУ, SNMP-агенты ИБП и преобразователи интерфейсов не менялись вообще. Все изменения пришлись на уровень SCADA и шлюза.

Этот принцип стоит закладывать в ТЗ прямым текстом: подключение к ЦСМ не должно затрагивать полевой уровень. Как только в объём попадает замена датчиков, проект превращается из интеграционного в реконструкцию со всеми вытекающими сроками.

Справочник зон и структура топиков - почему это половина работы

Коротко: каждый передаваемый параметр становится отдельным топиком MQTT, имя которого собирается по формуле из справочника заказчика. Сопоставление сотен исторических имён с этим справочником - самая трудоёмкая и самая недооценённая часть проекта.

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

Что это значит на практике для инженера, который делает проект:

• Каждое устройство нужно классифицировать. Не «щит ЩБП-1.1-ППК», а «щит бесперебойного питания, зона такая-то, номер такой-то». Классификация делается вручную, по факту обхода объекта, и требует сверки с эксплуатацией.
• Ошибка в коде зоны не видна на объекте. Локально всё работает, данные уходят, а в ЦСМ параметр приземляется не туда или отбрасывается. Отладка идёт через службу поддержки ЦСМ, а не своими силами.
• Объём растёт быстрее, чем кажется. В проекте по зданию банка под наблюдение попали более двадцати пяти точек учёта электроэнергии - на главном щите и щитах гарантированного, бесперебойного и специального питания. К ним добавились шесть источников бесперебойного питания с телеметрией по SNMP, контроллер дизель-генераторной установки и девять приточно-вытяжных установок. Отдельно - несколько десятков распределительных щитов с контролем положения автоматических выключателей. По каждому устройству - свой набор параметров.
• Справочник живёт своей жизнью. Он принадлежит заказчику и обновляется без вашего участия. Поэтому в проекте имеет смысл держать соответствие «локальное имя - код ЦСМ» отдельной таблицей, а не зашивать в конфигурацию.

Именно на этом этапе проекты по подключению к ЦСМ обычно и растягиваются. Монтаж шкафа - две смены, сопоставление номенклатуры - недели.

Что именно передаётся: состав телеметрии

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

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

Тип параметра	Пример	Как используется в ЦСМ
Состояние «работает / не работает»	Режим ИБП, факт запуска ДГУ, положение автоматических выключателей в щитах	Мгновенная реакция дежурной службы
Измерение с уставкой	Напряжение и ток по фазам, температуры воздуха в контурах вентиляции, давление масла ДГУ	Срабатывание порогов и формирование тревог
Накопительный счётчик	Энергия по точкам учёта, наработка оборудования, расход топлива	Отчётность и планирование обслуживания
Диагностика узла	Коды неисправностей, загрязнённость фильтров, эффективность рекуператора	Переход к обслуживанию по состоянию

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

Требования по сети и питанию

Коротко: шлюз работает через выделенный APN сотового оператора в изолированном сегменте без маршрутов куда-либо кроме ЦСМ, и обеспечен резервным питанием - потому что от него ожидают непрерывной работы.

Три требования, которые заказчик обычно формулирует жёстко и не обсуждает:

• Выделенный APN. Корпоративная SIM-карта заказчика, маршрутизатор LTE, изолированный сетевой сегмент, исключающий соединение с любыми сторонними системами кроме целевой ЦСМ. Это закрытый канал, а не «интернет для шлюза» - и он же означает, что удалённая отладка возможна только по согласованной схеме доступа.
• Запрет на размещение в корпоративных сегментах. Шлюз нельзя воткнуть в существующую сеть здания, даже если она принадлежит тому же заказчику. Архитектура подключения проверяется на соответствие утверждённому архитектурному решению - и это отдельная процедура согласования, которую надо заложить в график.
• Резервирование питания. Шлюз и маршрутизатор питаются через собственный источник бесперебойного питания с ёмкостью АКБ, рассчитанной на поддержку работы при пропадании основного питания. Логика простая: пропадание питания на объекте - это ровно тот момент, когда ЦСМ должна получить событие, а не потерять связь.

Отдельно стоит заранее обсудить доступ службы поддержки ЦСМ к шлюзу - в проекте по зданию банка для этого настраивался SSH-доступ. Кто, как и по какому регламенту заходит на устройство после сдачи, лучше зафиксировать в ТЗ, а не выяснять на приёмке.

Что заложить в ТЗ на подключение к ЦСМ

Коротко: границу периметра, состав телеметрии по подсистемам, требования к сети и питанию шлюза, порядок сверки со справочником заказчика и состав сдаваемой документации.

Минимальный состав требований:

• Явное указание, что существующая локальная АСУ сохраняется: логика, мнемосхемы и полевой уровень в объём переделки не входят.
• Перечень подсистем и состав параметров по каждой - согласованный с принимающей стороной до начала проектирования, а не после.
• Требование к обследованию как к отдельному этапу с результатом в виде сверки фактического оборудования с документацией объекта. На зданиях с историей исполнительная документация расходится с фактом почти всегда.
• Порядок получения и версия справочника зон и кодов, а также процедура согласования сопоставления локальных имён с этим справочником.
• Требования к каналу: выделенный APN, кто предоставляет SIM-карту, кто согласует архитектуру подключения и в какой срок.
• Резервирование питания шлюза с указанием расчётного времени автономной работы.
• Порядок доступа службы поддержки заказчика к шлюзу после сдачи.
• Состав пусконаладки: сквозная проверка передачи каждого параметра от полевого уровня до ЦСМ, а не только до локального брокера.
• Комплект документации: структурная схема автоматизации, схема внешних подключений, планы прокладки кабельных трасс по этажам, кабельный журнал, спецификация оборудования.

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

Частые вопросы

Можно ли обойтись без шлюза, если SCADA на объекте современная и умеет MQTT? Технически иногда можно, но остаётся требование по сегментации сети: SCADA-сервер связан с полевым уровнем и в изолированный контур с единственным маршрутом к ЦСМ не выносится. Плюс любая правка требований принимающей стороны будет означать вмешательство в работающую АСУ. Отдельный узел дешевле в сопровождении, даже когда он избыточен по протоколу.

Придётся ли переучивать операторскую смену объекта? Нет, если проект сделан правильно. Смысл архитектуры со шлюзом в том, что локальная АСУ продолжает работать в прежнем виде: те же мнемосхемы, тот же регламент. ЦСМ - это дополнительный потребитель данных, а не замена диспетчерской объекта.

Что делать, если часть нужных параметров на объекте вообще не собирается? Это выясняется на обследовании и попадает в проект отдельной строкой: добавление модулей контроля состояния, подключение по SNMP к тем ИБП, что раньше не мониторились, съём данных с приборов учёта, которые стояли автономно. Важно поймать этот объём до подписания, потому что он относится к полевому уровню и меняет и сроки, и стоимость.

Насколько достоверны данные со старых узлов учёта? Ровно настолько, насколько достоверен измерительный тракт. На объектах, где узлы учёта стоят давно, перед запуском мониторинга имеет смысл проверить тракты и согласовать результат с метрологической службой заказчика - иначе в ЦСМ поедут цифры, которым никто не поверит, и первый же спорный отчёт вернётся к вам.

Чем подключение к ЦСМ отличается от внедрения диспетчеризации в сети объектов? Направлением задачи. Подключение к ЦСМ - интеграционная работа на одном сложном здании, где верхний уровень уже существует и принадлежит заказчику. Диспетчеризация сети - тиражирование однотипного решения на десятки и сотни объектов, где верхний уровень создаётся вместе с ними. Разбор второй задачи - в статье «Диспетчеризация филиальной сети».

Источники

• Подключение мониторинга инженерных систем к ЦСМ крупного российского банка - кейс: административное здание, модернизация SCADA до версии с поддержкой MQTT, шлюз на ARM/Linux, выделенный APN, нумерация топиков по справочнику зон банка, состав переданной телеметрии.
• Мониторинг энергоресурсов на 21 объекте госзаказчика - смежная задача централизованного сбора данных с защищёнными требованиями к пограничному устройству и проверкой достоверности измерительных трактов.
• Диспетчеризация и СТДУ - страница услуги: чем различаются СТДУ, САДИС и АСДИМ, состав работ и эксплуатационное сопровождение.

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