Диспетчеризация на ПЛК с MasterSCADA и IEK IIoT: архитектуры, внедрение и риски – часть 2

Процесс внедрения системы по стандарту ГОСТ 34

Внедрение системы диспетчеризации – это серьёзный инженерный проект, который необходимо выполнить по определённой методологии. В России традиционно ориентиром служит стандарт ГОСТ 34 (комплекс стандартов на автоматизированные системы), регламентирующий стадии создания АСУ. Соблюдение ГОСТ 34 обеспечивает системный подход: начиная от обследования объекта и заканчивая сдачей системы в эксплуатацию с необходимой документацией. Ниже кратко рассмотрены основные этапы внедрения SCADA-системы в соответствии с ГОСТ 34:

1. Обследование и техническое задание. На первом этапе проводится обследование объекта автоматизации: собираются исходные данные о технологическом процессе, существующих контроллерах, датчиках, требованиях к диспетчеризации. Выявляются проблемы и задачи, которые должна решить система (например, отсутствие централизованного контроля, частые аварии незамеченными остаются и т.п.). Результатом этой фазы становится техническое задание (ТЗ) – официальный документ, где фиксируются цели проекта, перечень контролируемых параметров, требуемый функционал (см. предыдущий раздел), показатели надежности, состав оборудования и ПО, стандарты и регламенты, которые надо учесть. ТЗ согласуется заказчиком и служит отправной точкой для проектирования.
2. Проектирование системы. Этап проектирования часто разбивается на стадии эскизного проекта и технического проекта (так рекомендует ГОСТ 34, хотя в современных реалиях их могут объединять). Инженеры-разработчики на этом шаге разрабатывают архитектуру системы: выбирают вариант (локально, гибридно или облачно), разрабатывают структурные схемы системы диспетчеризации, сети связи, размещение серверов и рабочих станций, указывают модели ПЛК и другого оборудования. Параллельно создаётся проектная документация – например, схемы подключений (какие сигналы с датчиков к каким входам ПЛК идут), планы размещения шкафов автоматики, спецификации компонентов. Если используется MasterSCADA, проектирование включает продумывание структуры проекта SCADA: какие узлы ввода-вывода понадобятся, сколько тегов (переменных) будет, как организовать базы данных архивов, безопасность и права пользователей. На этом же этапе часто создаётся макет или концепт будущих экранов (мнемосхем), чтобы заказчик представлял, как будет выглядеть интерфейс. Проектирование по ГОСТ предполагает выпуск комплекта документов: технический проект содержит пояснительную записку, чертежи, спецификации оборудования и кабелей, описания алгоритмов работы системы. Этот комплект также подлежит согласованию и экспертизе.
3. Разработка и конфигурирование ПО. После утверждения проекта наступает практическая реализация: программисты создают прикладное ПО для ПЛК (логика управления) и разрабатывают саму SCADA-проект в среде MasterSCADA. Контроллеры ONI могут программироваться, например, с помощью MasterPLC (IEC 61131-3) или другого среды; на этом шаге реализуются все технологические алгоритмы, заложенные в ТЗ. Параллельно конфигурируется SCADA: настраиваются драйверы связи с ПЛК по нужным протоколам (Modbus, MQTT и т.д.), создаются мнемосхемы, вводятся теги, настраиваются архивы, задаются уставки аварий, пишутся скрипты, если требуются нестандартные расчёты. Фактически, происходит разработка приложения диспетчеризации. Этот этап можно вести частично на испытательном стенде – т.е. в офисе интегратора, моделируя работу контроллеров, чтобы заранее протестировать логику. Также подготавливаются сопроводительные документы: инструкции оператора, описания программ.
4. Монтаж и интеграция оборудования. Параллельно с софтверной разработкой (а часто и раньше) идёт монтажный этап: установка и подключение контроллеров ONI и прочего полевого оборудования (датчиков, приводов) на объекте, прокладка кабельных линий, монтаж щитов автоматики, серверного шкафа и рабочих мест. Если архитектура предусматривает локальные серверы – в диспетчерской размещают сервер MasterSCADA, настраивают сетевое оборудование (коммутаторы, маршрутизаторы, модемы). Если используется облако – настраивают шлюзы связи (например, промышленный роутер для MQTT-подключения контроллеров к интернету). По завершении физического монтажа система готова к пуско-наладке.
5. Пусконаладочные работы (ПНР). ПНР – один из ключевых этапов, где разработанная система проверяется и настраивается в реальных условиях. Инженеры вместе с технологическим персоналом проводят прогон всех сигналов: проверяют, правильно ли SCADA считывает показания каждого датчика, соответствуют ли отображаемые на экранах значения реальности. Проводится настройка контроллеров: калибровка датчиков, регулировка контуров управления, оптимизация параметров ПИД-регуляторов (если есть). Ключевой задачей является тестирование аварийной сигнализации и блокировок: имитируются аварийные ситуации (например, превышение давления) и проверяется, сработали ли алармы в MasterSCADA, отключилось ли оборудование при критическом отклонении, поступили ли уведомления. Также тестируется сценарий взаимодействия оператора – например, запуск агрегатов из системы диспетчеризации, переключение режимов. На этапе ПНР часто выявляются несоответствия или недоработки, их тут же исправляют: корректируют программу ПЛК, дорабатывают мнемосхемы, изменяют пороги срабатывания сигнализаций. Если система гибридная или облачная, дополнительно проверяют связь с облаком: все ли данные доходят, нет ли потерь при передаче, правильно ли обновляются панели мониторинга IIoT-платформы. ПНР завершается тогда, когда система начинает устойчиво и правильно функционировать в соответствии с ТЗ на реальном процессе.
6. Опытная эксплуатация и приёмка. После пусконаладки обычно следует период опытной (пробной) эксплуатации – несколько недель или месяцев, когда система работает под наблюдением, а заказчик оценивает её эффективность. В этом периоде возможно внесение небольших изменений или настройка дополнительной аналитики, если выявятся новые потребности. Затем проводится приёмочно-сдаточное испытание: комиссия проверяет соответствие работы системы требованиям ТЗ, сравнивает достигнутые показатели с плановыми, оценивает качество документации. По результатам оформляется акт приёмки – система диспетчерского управления считается введённой в действие. Персонал заказчика получает все необходимые инструкции, проходит обучение работе с новым программным обеспечением (если не прошёл ранее). С этого момента проект внедрения завершается, начинается штатная эксплуатация системы.
7. Сопровождение и развитие. ГОСТ 34 предусматривает и стадию сопровождения – это эксплуатация, техническая поддержка системы, а также ее возможное дальнейшее развитие (модернизации, расширение функционала). Интегратор или служба АСУТП предприятия ведут обслуживание серверов, обновления MasterSCADA, резервное копирование архивов. Если подключаются новые технологические узлы, система масштабируется (о принципах масштабирования – ниже). Важно заложить в договоре на внедрение условия гарантийной поддержки на первоначальный период, а далее – регламент технического обслуживания, чтобы система оставалась работоспособной и актуальной.

Следование этой поэтапной процедуре по ГОСТ 34 позволяет минимизировать риски: проект проходит несколько точек контроля качества (экспертиза ТЗ, проверка проекта, тестирование на ПНР), благодаря чему снижается вероятность, что какие-то аспекты останутся неучтенными. Конечно, реальный процесс внедрения может адаптироваться под конкретный проект (например, укрупнение стадий, использование методологий Agile для ПО), но общая логика – от требований к результату через стадии проектирования и отладки – сохраняется. Для инженера, ведущего проект диспетчеризации, ГОСТовский подход обеспечивает дисциплину разработки и прозрачность для всех участников.

Преимущества подхода IEK IIoT: MQTT, контроллеры ONI и безсерверная архитектура

Решения от IEK GROUP (платформа MasterSCADA 4D, облачная IEK IIoT Platform и линейка оборудования ONI) представляют собой современную экосистему для диспетчеризации, основанную на принципах промышленного Интернета вещей. Рассмотрим технические преимущества этого подхода, которые отличают его от классических SCADA-реализаций:

- Использование протокола MQTT и других IIoT-технологий. В традиционных SCADA-системах опрос контроллеров часто ведётся по опросным протоколам (Modbus, OPC DA) в режиме запрос-ответ, что порождает значительную нагрузку при масштабировании. В платформе IEK IIoT сделан упор на MQTT (Message Queuing Telemetry Transport) – лёгкий протокол обмена сообщениями по модели publish/subscribe. Контроллеры ONI могут выступать в роли MQTT-клиентов, самостоятельно отправляя данные на брокера при изменении значений. Это снижает трафик и обеспечивает почти в реальном времени доставку данных, особенно важную для распределённых систем с сотовой связью. MQTT встроен в архитектуру IEK IIoT Platform, что упрощает интеграцию устройств: подключив контроллер к интернету и настроив публикацию топиков, мы сразу видим его данные в облачной диспетчерской панели. Кроме того, IEK IIoT Platform – микросервисная, то есть каждая функция (хранение данных, обработка, визуализация) реализована отдельным сервисом. Это повышает надёжность (отказ одного компонента не «роняет» всю систему) и упрощает обновление/масштабирование инфраструктуры.

- Промышленные контроллеры ONI с открытой архитектурой. Линейка ПЛК ONI (разработки, интегрированные в IEK) спроектирована с учетом требований современного IIoT. Эти контроллеры имеют компактные размеры, достаточную производительность (существуют модели с частотой CPU, большим объёмом RAM/ROM), широкий набор интерфейсов (Ethernet, RS-485, USB, опции GSM/3G модемов для связи). ONI поддерживают стандартные языки программирования (МЭК 61131-3) через среду MasterPLC – то есть инженерам легко создавать логику, не привязываясь к проприетарным языкам. Главное – глубокая интеграция с платформой диспетчеризации: ПЛК ONI «из коробки» дружат с MasterSCADA, а также имеют поддержку протоколов, требуемых для IEK IIoT Platform (упомянутый MQTT, а также Modbus TCP/RTU для локальных подключений). Так, связка «MasterSCADA + ONI» не требует дополнительных шлюзов или OPC-серверов – данные идут напрямую. Контроллеры ONI разработаны в России, что важно в условиях импортозамещения и независимости от зарубежных поставщиков. Инженер, использующий единый стек IEK, получает уверенность в совместимости компонентов и локальную техническую поддержку от производителя при внедрении.

- Отказ от громоздких серверов – serverless-подход. Традиционно при слове «SCADA» мы представляем помещение с рядами серверов, стойками бесперебойников и сложной ИТ-инфраструктурой. IEK IIoT предлагает во многом безсерверное решение: функции сервера берёт на себя облако, а на объекте зачастую достаточно интеллектуальных контроллеров и небольшого коммуникационного устройства. Это кардинально упрощает инфраструктуру: не нужно покупать и обслуживать дорогостоящий серверный hardware, заботиться о лицензиях на серверные ОС и СУБД – достаточно подписки на облачный сервис. Для ряда средних и малых систем (например, автоматизация инженерных систем здания, локальная котельная, насосная станция) подобный подход снижает порог входа в диспетчеризацию. Компания может стартовать с небольшого пилотного проекта в облаке (тем более что IEK IIoT Platform заявлена как no-code и доступна для бесплатного пробного использования) и при успешных результатах масштабировать решение. Масштабируемость по требованию – ещё одно преимущество: облачная платформа гибко наращивает ресурсы хранения данных и обработки под увеличивающийся парк устройств, без необходимости замены всего ПО. Также снижаются требования к локальному IT-персоналу: основные задачи (резервирование данных, обновления безопасности, поддержание работы сервиса 24/7) берет на себя провайдер. Это не означает полное отсутствие контроля – через веб-консоль можно управлять своими объектами, создавать новые узлы, следить за состоянием подключений. Итогом безсерверной архитектуры становится сокращение совокупных затрат на жизненный цикл системы и ускорение внедрения новых функций (обновление ПО на стороне сервиса автоматически доступно всем пользователям).

Важно подчеркнуть, что перечисленные преимущества проявляются при грамотном использовании. Например, MQTT эффективен, но требует настройки QOS и ретрансляции сообщений для надёжности; облако освобождает от серверов, но ответственность за данные (резервное копирование, информационная безопасность настроек) всё равно лежит и на клиенте. В целом же платформа IEK IIoT с MasterSCADA и ONI демонстрирует тренд на конвергенцию SCADA и IoT: классические функции диспетчеризации дополняются возможностями больших данных и облачных технологий. Инженерно это выражается в более гибких интеграционных возможностях, повышении масштабируемости и потенциале для внедрения алгоритмов машинного обучения, предиктивной диагностики прямо поверх собираемых данных.