Pull to refresh

SCADA: в поисках идеала

Reading time 6 min
Views 73K
image По моим наблюдениям, большинство толковых специалистов АСУ, работающих со SCADA, проходят несколько стадий «эмоционального роста»: освоение какой-либо SCADA, поиск чего-то лучшего, идеи и попытки написания своего варианта, выработка философского отношения к проблеме и использование одного из существующих продуктов.

Да, бывают исключения. Например, встречаются сильно увлеченные и упорные энтузиасты, которые создают что-то работающее, но картины они не меняют совершенно.

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

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

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

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

  1. Как только возникает необходимость в создании большого проекта с большим числом элементов на мнемосхемах или потребность в сколько-нибудь заметных объемах вычислений, сразу бросается в глаза очень низкая скорость работы. Особенно комично выглядит ситуация, когда приходится перекладывать расчеты на ПЛК, хотя его быстродействие несопоставимо ниже современных ПК. Чаще всего и об организации выполнения нескольких потоков также можно забыть.

  2. Попытка сделать что-нибудь, не предусмотренное разработчиками SCADA, легко выливается в очень нетривиальные решения с огромными трудозатратами.

  3. Закрытость внутренних механизмов и неполная документация. Например, попробуйте найти для коммерческих SCADA полноценное описание форматов хранения данных и структуры БД.

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

  5. Высокая стоимость — при создании большого промышленного объекта стоимостью в несколько миллионов выделить 5-10 тыс. евро проблема не большая, но если речь ведется об относительно недорогом оборудовании, выпускаемом большим тиражом, затраты даже в 200 евро на один экземпляр могут оказаться непозволительной роскошью.

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

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

  1. Необходима высокая скорость работы. Это означает, что не должно быть никаких интерпретаторов, на выходе надо получить исполняемый машинный код.

  2. Возможность легко и без существенных рисков изменять поведение существующих компонентов или добавлять свои.

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

  4. Простота и скорость разработки. Необходимо свести к минимуму написание кода и по максимуму использовать визуальное программирование. Если для работы над проектом по автоматизации будет необходимо затрачивать заметно большие усилия по сравнению с коммерческими SCADA, то кому это все будет надо?

  5. Удобная и современная среда разработки (IDE). Необходимы привычные инструменты любого программиста: автодополнение кода, контроль версий и т.п.

  6. Низкая стоимость стороннего ПО, а в идеале бесплатность и открытость исходного кода.

  7. Все эти требования необходимо реализовать при минимально возможных затратах усилий нескольких разработчиков.

Отсюда напрашивается решение — надо взять существующую хорошую среду для визуального программирования и создать к ней библиотеку компонентов, заточенных под специфические задачи SCADA-систем. Рассуждая подобным образом я остановил свой выбор на Qt. Тут и масса готовых компонентов, и отличная IDE, и огромное сообщество разработчиков.

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

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

режим разработки мнемосхемы

Созданный набор можно условно поделить на несколько групп.

  1. Компоненты, предназначенные для обеспечения обмена данными с ПЛК

    • Система тегов. Фактически, некоторый буфер между драйверами и другими частями библиотеки, обеспечивающий доступ к данным из различных компонентов программы.
    • Драйвер-клиент для OPC DA2. По моему мнению, на данный момент это самый популярный способ обмена данными с ПЛК и довольно сложно найти хоть сколько-нибудь распространенное устройство без OPC-сервера.

  2. Обеспечение записи и доступа к архивной информации

    • Система аварийных сообщений.
    • Журналы технологических параметров.

  3. Набор графических компонентов (widgets).

    • Построение графиков и трендов из журналов технологических параметров. Тут все классически — выбор и настройка отображения накопленных данных.
    • Работа с аварийными сообщениями — вывод активных сообщений, подтверждение оператором (квитирование), доступ к архивной информации.
    • Отображение различных элементов мнемосхем. Как показали опросы, в большинстве компаний используют собственные иконки для показа состояний технологического оборудования. По этой причине был создан компонент, позволяющий выводить графические изображения (в том числе и с эффектом мигания) в зависимости от значений тегов.
    • Построение больших анимированных схем трубопроводов. Готовых аналогов мне не доводилось встречать ни в одной SCADA, а ведь потребность очевидна — попробуйте проложить маршрут в разветвленной системе с двумя — тремя сотнями задвижек.
    • Набор компонентов для облегчения создания пользовательских элементов.

image

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

  • Создание утилит для решения побочных задач в уже существующих системах. Так например, мне довелось написать аналог Matrikon OPC Data Manager с более богатым функционалом, потратив на это всего около четырех часов и сэкономив довольно значительные средства.
  • Разработка приложений для работы с научными приборами.
  • Системы «умный дом».

image

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

Чуть больше информации можно найти на странице в Facebook.

Также буду очень благодарен за конструктивную критику и новые идеи.

И в заключение, небольшое видео FAQ:

Tags:
Hubs:
+20
Comments 65
Comments Comments 65

Articles