Действительно я против построение SCADA так как их строят сейчас. Я против того функционала, который им пытаются приписать и что на них пытаются реализовать.
В этой статье я представлю свое видение современных систем, поговорим об отдельных узлах в системе, посмотрим что можно упростить, что улучшить, что оставить неизменно. Узнаем где можно и нужно использовать Apache Kafka.
А теперь самое главное. Это мой взгляд на то как можно организовать системы диспетчеризации и управления на современных производствах, которые, возможно, готовы к таким экспериментам.
Основная цель данной статьи вызвать диалог. Я с вами делюсь своим взглядом на вещи, вы можете выразить свое мнение относительно моего взгляда. В чем вы согласны, в чем не согласны, какие моменты вам не понятны и стоит рассказать подробнее или указать мне на ошибки, которые я смогу исправить, переосмыслив свое представление.
Такой диалог приведет к формализации проблем, которые есть в каких-то секторах АСУТП, что позволит их проработать.
Что такое SCADA?
Википедия 1:
SCADA (аббр. от англ. Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных) — программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. SCADA может являться частью АСУ ТП, АСКУЭ, системы экологического мониторинга, научного эксперимента, автоматизации здания и т. д. SCADA-системы используются во всех отраслях хозяйства, где требуется обеспечивать операторский контроль за технологическими процессами в реальном времени. Данное программное обеспечение устанавливается на компьютеры и, для связи с объектом, использует драйверы ввода-вывода или OPC/DDE серверы. Программный код может быть как написан на одном из языков программирования, так и сгенерирован в среде проектирования.
Wikipedia
Википедия 2:
Диспетчерское управление и сбор данных ( SCADA ) представляет собой архитектуру системы управления, включающую компьютеры , сетевую передачу данных и графические пользовательские интерфейсы для высокоуровневого наблюдения за машинами и процессами. Он также охватывает датчики и другие устройства, такие как программируемые логические контроллеры , которые взаимодействуют с технологическими установками или механизмами.
Wikipedia
В целом SCADA счистема представляет из себя архитектру системы управления, которая должна обладать определенным функционалом и под такие задачи пишутся специальные программные пакеты.
Давайте же взглянем на основные задачи, которые решает скада.
Если у вам есть что добавить в список основных задач, то прошу. Если кто-то в список основных задач для скада добавить создание p2p соединения с проходным режимом работы, то должен буду вас огорчить, что этот функционал добавили лишь для того чтоб было хоть какое-то УКП и для маркетинга.
Рассмотрим стандартную схематику архитектуры SCADA системы.
Центральным узлом является «скада сервер», который устанавливает связь между собой и станциями оператора, шлюзами с различными протоколами, возможно напрямую подсоединяется к ПЛК или удаленному терминалу, у него есть связь с БД. Плюс он хранит текущую визуализацию, с возможностью запуска скриптов визуализации плюс возможностью трансляции данных на уровень выше.
Стандартный монолит, который обладает как я рядом своих преимуществ, так и рядом недостатков. Таких как сложность горизонтального масштабирования или смены различных сред исполнения.
Далее мы рассмотрим крупные функциональные узлы SCADA системы.
Обмен данными с ПЛК и управление процессом.
Комплексный вопрос, которые мне сложно представить отдельно друг от друга. Тут есть несколько моментом, которые стоит обсудить:
- Обмен данными между ПЛК и скада
- Обмен данными между ПЛК и ПЛК
- Операторское управление технологическим процессом.
Обмен данными между ПЛК и SCADA
Наверное, одна из основных задач любой системы — наладить процесс обмена между ПЛК и верхним уровнем для предоставления необходимой информации с поля и для поля.
По факту мы имеем два больших пула данных на прием и отправку.
Принимаем:
- Показания датчиков
- Состояние оборудования
- Состояние ПЛК и модулей
- Информацию о технологическом процессе
- Аварии, предупреждении, блокировки
Передаем:
- Команды оперативного вмешательства
- Новые уставки для технологических процессов
- Штатные запуски/остановы технологических процессов
В итоге мы получаем, что каждый пункт, кроме оперативного вмешательства оператора не сильно критичны ко времени.
Основной проблемой является передача данных между уровнями системы, так как он организован в зависимости от желаний производителя как железа, так и программного продукта.
Крупные производители железа любят строить свою «экосистему», завязывая все на свой протокол общения, который редко. но бывает открытым. К тому же в так называемую «экосистему» очень сложно полноценно поставить стороннего производителя без различных прослоек или сложных преобразований данных на стороне ПЛК.
Если мы рассматриваем обычного производителя SCADA системы, то в его арсенале есть набор шлюзов для общения с нижними уровнями, которые обычно все приводят к стандартному OPC UA. И если с открытыми протоколами все понятно, то для использование проприетарных протоколов используются сторонние библиотеки.
Обмен данными между ПЛК и ПЛК
Обмен данными между ПЛК существует для передачи различной информации от одной технологической цепочки к другой. Мы можем передавать различные аварийные сообщения, сигналы блокировок, информацию о ходе технологического процесса. Спорным моментом является передача каких-либо сигналов, которые должны принимать участи в оперативном автоматическом регулировании процесса. Например показатели уровнемера, которые забираются одним ПЛК, а потом передаются в другой, который использует данные показатели у себя. При такой ситуации я бы рекомендовал либо физически сдублировать сигнал во второй ПЛК, либо пересмотреть алгоритм работы и зоны ответственности.
Однако при решении вопросов автоматизации приходится организовывать общение ПЛК. Существует несколько способов М2М.
Начнем с простых способов
На схемах выше можно заметить максимально типичные схемы обмена данными между ПЛК, которые при использовании ряда специальных протоколов позволяют нам организовать действительно Realtime обмен данными между ними.
Это либо общение завязанное напрямую между двумя ПЛК, и если вы выбираете ПЛК от одного производителя, то у вас существует множество способов обмена информацией, зачастую предопределенные производителем железа. И вам уже не надо строить какие-то сложные схемы или поднимать отдельную инфраструктуру для этого, но вы привязываете себя к одному производителю.
Но на ряду с традиционными решениями есть и несколько интересных.
В первом случае — это обмен через шину данных. Вот сюда у нас подходят все брокеры хоть RabbitMQ, хоть Kafka, хоть Reddis c его pub/sub(присмотритесь для тестов).
Шина способна принимать и отправлять большие объемы данных, можно спокойно заменить ПЛК, ввести новые ПЛК, легко организовать связь с серверами для граничных вычислений и облаками. Никакого Realtime, в случае с MQTT при гарантированной доставке сообщения могут дублироваться, изначальная высокая сложность настройки шины. Но мы получаем удобную систему с большим потенциалом для масштабирования и отказоустойчивости.
А вот вариант обмена какими-то данными между ПЛК через скада сервер — боль, страх и ужас. Существуют решения, при которых через скаду передают какие-то данные, которые плк использует при автоматическом управлении технологическим процессом. Отдельная моя боль — управление технологическим процессом на скаде, когда есть скрипт, который берет значения датчиков, обрабатывает их и выдает ПЛК нужные значения.
Никогда не передавайте через SCADA систему данные между ПЛК, которые должны использоваться для оперативного управления.
Операторское управление технологическим процессом
Последний момент в этой части — операторское управление. Оператор — это сотрудник, который следит за работоспособность всей технологической цепочки и в случае необходимости корректировки технологического процесса. В случае если у нас оператор отвечает за одну конкретную установку, то он также запускает необходимые технологические процессы.
Оператор должен иметь возможность экстренного исправления технологического процесса, или остановки технологического процесса.
Но это просто дополнительные необходимые меры для безопасности, но никак не приглашение к действию. Любой алгоритмический сбой в технологическом процессе должен как-то фиксироваться и после такой фиксации должна быть итерация доработки системы и тестирования доработанного.
Система должна быть максимально автоматической с минимальным влиянием человеческого фактора.
У оператора не должно быть таких ситуаций, при которых для положительного результата его вмешательства должна быть реализована система реального времени на операторской стороне скада системы
А к чему была эта часть?
Если вам кажется, что это была банальщина и так всем все понятно, то хорошо, мы еще раз повторили какие-то общие моменты, возможно у кого-то появились какие-то мысли. Но весь этот разгон про операторов обмен со скадой, обмен между плк был для того, чтобы рассказать о базовых вещах так как мне надо и сделать вывод, который будет удобен мне. А вот и вывод
Построение систем реального времени для обмена данными между ПЛК и SCADA является избыточным, чего нельзя сказать про обмен между ПЛК и ПЛК, где построение такой системы иногда необходимо. А использование скады как трансфера или заглушки является следствием ошибки в построении архитектуры.
Визуализация или HMI
Визуализация отвечает за визуальное представление технологического процесса, отображение состояния конечных устройств, возможность логического управления и настройки оборудования.
Если мне не изменяет память, то выглядит схема примерно так. На сервере хранится проект, который просто копируется на АРМ, где и запускается в рантайме этой скада системы.
И вот тут момент, который я бы очень сильно хотел поменять. Дать возможность создания визуализации, которая не была бы привязана к какой-то среде выполнения. Есть web и браузеры. Что еще надо для хорошей визуализации?
Да наша архитектура сети станет чуточку больше.
Условно скада сервер как таковой теперь просто занимается предоставление необходимых данных для фронта. Скада сервер мы можем пинговать через REST API или благодаря http2, возможно просто обращаться к БД или просто к кэшу нашей системы.
И да, это действительно js. И он прям максимально подходит для подобных задач.
Логирование, архивирование и аварийная сигнализация.
Запись в базу при совершении действия, запись в базу и сравнение с выводом сообщения, которое запишется в базу. Вес эти три функции просто работа с данными. Обычно все это происходит где-то через наш центральный скада сервер, который держит связь с SQL DB.
И тут я опять со своей шиной данных.
Теперь мы точно знаем, что на каждое событие от ПЛК или на каждые данные от него их получат те сервисы, которым они потребуются. Также в случае действий оператора мы сможем легко отправить все данные в нужные места для хранения, анализа, а также выдать управляющее воздействие.
Аварийные сообщения
Аварийные сообщение — это информация о том, что уже случилось. Не бывает аварийных сообщений до аварии и аварийные сообщения не должны формироваться на стороне оператора. В большинстве случаев это обычная функция скада системы, когда она при изменени статуса определенного тега просто показывает сообщение на визуализации.
Так что подобную надстройку сделать очень легко. Но я бы никогда не писал аварийные сообщения вместе со всеми. Они требуют отдельное место для хранения и отдельного канала для своей передачи.
Новый подход
Так как в настоящее время идет тенденция слияния OT и IT, то почему бы нам просто не взять готовые решения и подходы и просто не перенести из в сферу промышленной автоматизации, подстраивая их под определенные требования.
Общение между частями системы происходит через шину
Всем роутингом теперь занимается отдельная часть системы. У нас есть брокер. Он нам и помощет.
Идеальное место для реализации шины при помощи MQTT брокеров или Apache Kafka, за которую многие спрашивают. Можете сами придумать как будет реализована шина.
Real-time оставляем там, где он нужен
Мы четко умеем разграничивать данные внутри систем. Те которые требуются для производственного процесса в данный момент времени и те данные, которые могут для нас прийти с небольшой задержкой. Если у нас остается потребность в обмене данными между ПЛК, то мы оставляет как физические среды передачи данных между ними, так и пользуемся необходимыми протоколами.
Отправка данных в шину от ПЛК происходит напрямую или через шлюз.
Многие ПЛК уже умеют в какие-то протоколы, связанные с IoT или с web. Так что вполне можно организовать быстрый обмен данными на открытых протоколах не обращая внимания на конечного производителя оборудования.
Быстрое масштабирование системы
Любые серверные мощности можно нарастить или сократить, в зависимости от требований. Плюс появляется возможность интеграции нового функционала. Это могут быть какие-то серверы граничного вычисления или шлюзы на верхние уровни, возможно какая-то система ручных замеров на месте. Даже можно датчики беспроводные завести прям в шину.
Информационная безопасность
При хорошей настройки системы и при использовании необходимого инструментария, но такую информационную безопасность реализовать чуть проще. Чем на системах, которые являются суровым монолитом и требует ожидания патча с заплаткой.
А минусы?
Они огромные.
Это долгий поэтапный процесс перехода на такую системы в современных реалиях. Он возможен либо в качестве эксперимента на готовых предприятиях при интеграции новых элементов производственных линий, либо при модернизации старых. В любом случае это будет какой-то пилотный проект для расчета экономической выгоды.
Такую систему удобнее вводить при строительстве новых предприятий. Где нет еще жесткой системы и можно рискнуть. Такие риски оправданы на небольших предприятиях, где возможна цифровизация производства и ее введение даст сразу результат.
Следующая проблема — кадры. Придется повышать квалификацию существующих, либо нанимать новый персонал, либо субподряд под конкретные задачи. Это приводит к росту постоянных издержек, так что ФОТ будет раздуваться слегка или не очень. при таких условиях экономика должна сходиться из-за уменьшения себестоимости товара, благодаря повышению беспрерывной работы производства, улучшения режимов работы, которые бы влияли на уменьшение отходов и на увеличение количества продукции при том же качестве.
Итог
Так кому же это стоит вводить? Для начала как всегда малым предприятиям с гибкими процессами с малым временем итерации производства. Если система будет вести расход материала при производстве. прогнозировать его нехватку и еще подсчитывать сроки поставки, то вполне можно организовать прогнозируемую закупку, которую можно воткнуть в фин модель и быть более уверенным, что какого-то расходника не окажется. Плюс хотя бы минимальная система оповещения о необходимости обслуживания оборудования продлит его жизнь.
Каким-то производствам, которые хотели бы быть немного технологичными и подружить цеха и АБК. И если это крупные предприятия с гос. поддержкой или участие государства, то это максимально сложно и можно на них ставить крест до лучших времен, то вот средние предприятия без участия государства могут обратить внимание на подобные схемы и технологии и применять их пилотно и точечно.
Где бы я не стал рассматривать подобные технологии… В каких-то устоявшихся производствах, где экономика уже подсчитана и надо чтоб все просто работало. Вот в такие системы я бы не лез.
Это все что я хотел поведать в обзорном посте. Жду ваших замечаний, предложений и комментариев.
Можно писать мне на почту: info@engcore.ru
Также можно подписаться на ТГ канал с новостями