[Из песочницы] SCADA: в поисках идеала
По моим наблюдениям, большинство толковых специалистов АСУ, работающих со SCADA, проходят несколько стадий «эмоционального роста»: освоение какой-либо SCADA, поиск чего-то лучшего, идеи и попытки написания своего варианта, выработка философского отношения к проблеме и использование одного из существующих продуктов.Да, бывают исключения. Например, встречаются сильно увлеченные и упорные энтузиасты, которые создают что-то работающее, но картины они не меняют совершенно.
Попробуем разобраться, почему так происходит и может ли быть выход из этого порочного круга.
Примечание: дальнейшие рассуждения будут касаться преимущественно коммерческих продуктов, но во многом справедливы и для проектов с открытым кодом, о которых будет сказано отдельно.
В первом приближении процесс работы со SCADA-системой сводится к нескольким действиям: выбор параметров обмена данными с ПЛК, разработка мнемосхем в специальном редакторе, настройка логирования событий и состояний параметров. Для обеспечения сложного поведения графических элементов мнемосхем и несложных математических расчетов используется написание скриптов или вообще предполагается, что достаточно средств простейшей анимации, настраиваемой в редакторе.
Такой подход во многом себя оправдывает — легко обучиться, можно быстро реализовать несложные проекты. По большому счету, можно даже не иметь минимальных знаний о программировании для начала работы.
Сегодня существует довольно большое количество SCADA-систем, различающихся по своим возможностям, стоимости, удобству разработки и т.д. Казалось бы, выбирай подходящий вариант и начинай творить доброе, светлое, вечное… Но тут-то и выясняется, что все не так просто.
- Как только возникает необходимость в создании большого проекта с большим числом элементов на мнемосхемах или потребность в сколько-нибудь заметных объемах вычислений, сразу бросается в глаза очень низкая скорость работы. Особенно комично выглядит ситуация, когда приходится перекладывать расчеты на ПЛК, хотя его быстродействие несопоставимо ниже современных ПК. Чаще всего и об организации выполнения нескольких потоков также можно забыть.
- Попытка сделать что-нибудь, не предусмотренное разработчиками SCADA, легко выливается в очень нетривиальные решения с огромными трудозатратами.
- Закрытость внутренних механизмов и неполная документация. Например, попробуйте найти для коммерческих SCADA полноценное описание форматов хранения данных и структуры БД.
- Многие авторы статей о современных стратегиях разработки ПО негативно отзываются о распространенном подходе, когда созданию нового функционала уделяется несравнимо большее внимание, чем оптимизации и тестированию кода. К сожалению, это часто наблюдается и в мире SCADA. Порой в процессе разработки приходится больше времени потратить на обхождение недокументированного поведения системы, чем собственно на разработку. А ведь это промышленные системы с повышенными требованиями к надежности.
- Высокая стоимость — при создании большого промышленного объекта стоимостью в несколько миллионов выделить 5–10 тыс. евро проблема не большая, но если речь ведется об относительно недорогом оборудовании, выпускаемом большим тиражом, затраты даже в 200 евро на один экземпляр могут оказаться непозволительной роскошью.
Пару слов о системах с открытым кодом. При искреннем уважении к разработчикам мне кажется, что идея, несмотря на всю привлекательность, практически не реализуема. Причина — огромные трудозатраты при отсутствии заметного сообщества. Слишком мало людей, заинтересованных в подобном продукте и при этом способных писать качественный код на объектно-ориентированном языке, готовых тратить свое свободное время на такой проект. Собственно, осознание объемов работы для создания чего-то, способного конкурировать с существующими коммерческими продуктами, и заставляет опускать руки.
Теперь, получив представление о трудностях, попробуем сформулировать требования к идеальной SCADA и посмотрим, можно ли решить проблему, если слегка выйти за рамки традиционной парадигмы.
- Необходима высокая скорость работы. Это означает, что не должно быть никаких интерпретаторов, на выходе надо получить исполняемый машинный код.
- Возможность легко и без существенных рисков изменять поведение существующих компонентов или добавлять свои.
- Прозрачность форматов хранения настроек и исторических данных. К примеру, необходимость сделать специфическую выборку из архивов для построения отчетов не должна выливаться в длительный реверсинжиниринг инструментов, входящих в состав SCADA.
- Простота и скорость разработки. Необходимо свести к минимуму написание кода и по максимуму использовать визуальное программирование. Если для работы над проектом по автоматизации будет необходимо затрачивать заметно большие усилия по сравнению с коммерческими SCADA, то кому это все будет надо?
- Удобная и современная среда разработки (IDE). Необходимы привычные инструменты любого программиста: автодополнение кода, контроль версий и т.п.
- Низкая стоимость стороннего ПО, а в идеале бесплатность и открытость исходного кода.
- Все эти требования необходимо реализовать при минимально возможных затратах усилий нескольких разработчиков.
Отсюда напрашивается решение — надо взять существующую хорошую среду для визуального программирования и создать к ней библиотеку компонентов, заточенных под специфические задачи SCADA-систем. Рассуждая подобным образом я остановил свой выбор на Qt. Тут и масса готовых компонентов, и отличная IDE, и огромное сообщество разработчиков.
Когда я впервые познакомился с Qt, то был просто поражен внутренней логичностью и богатством этой библиотеки. Как только возникает задача сделать что-нибудь, очень часто выясняется, что это уже практически реализовано в Qt и надо просто адаптировать под свои нужды.
Когда задача правильно сформулирована, остается ее просто реализовать, что я и начал делать некоторое время назад. К текущему моменту удалось реализовать минимальный джентльменский набор компонентов.
Созданный набор можно условно поделить на несколько групп.
- Компоненты, предназначенные для обеспечения обмена данными с ПЛК
- Система тегов. Фактически, некоторый буфер между драйверами и другими частями библиотеки, обеспечивающий доступ к данным из различных компонентов программы.
- Драйвер-клиент для OPC DA2. По моему мнению, на данный момент это самый популярный способ обмена данными с ПЛК и довольно сложно найти хоть сколько-нибудь распространенное устройство без OPC-сервера.
- Обеспечение записи и доступа к архивной информации
- Система аварийных сообщений.
- Журналы технологических параметров.
- Набор графических компонентов (widgets).
- Построение графиков и трендов из журналов технологических параметров. Тут все классически — выбор и настройка отображения накопленных данных.
- Работа с аварийными сообщениями — вывод активных сообщений, подтверждение оператором (квитирование), доступ к архивной информации.
- Отображение различных элементов мнемосхем. Как показали опросы, в большинстве компаний используют собственные иконки для показа состояний технологического оборудования. По этой причине был создан компонент, позволяющий выводить графические изображения (в том числе и с эффектом мигания) в зависимости от значений тегов.
- Построение больших анимированных схем трубопроводов. Готовых аналогов мне не доводилось встречать ни в одной SCADA, а ведь потребность очевидна — попробуйте проложить маршрут в разветвленной системе с двумя — тремя сотнями задвижек.
- Набор компонентов для облегчения создания пользовательских элементов.
Конечно, предстоит пройти еще немалый путь, но уже сейчас просматривается несколько возможных направлений для применения, помимо собственно всех видов классических задач промышленной автоматизации:
- Создание утилит для решения побочных задач в уже существующих системах. Так например, мне довелось написать аналог Matrikon OPC Data Manager с более богатым функционалом, потратив на это всего около четырех часов и сэкономив довольно значительные средства.
- Разработка приложений для работы с научными приборами.
- Системы «умный дом».
Как-то незаметно для меня, мое хобби превратилось во что-то большее, вызывающее интерес у других людей. Появилась мысль превратить это творчество в стартап, но пока все упирается в недостаток людей, готовых разделить со мной эту работу. Если у Вас есть желание принять участие в развитии стартапа, встать у истоков новой компании или попробовать себя в роли сооснователя, напишите мне в личку.
Чуть больше информации можно найти на странице в Facebook.
Также буду очень благодарен за конструктивную критику и новые идеи.
И в заключение, небольшое видео FAQ:
Комментарии (3)
11 января 2017 в 17:20
0↑
↓
Я так понимаю, что если оно пишется на Qt, то требования к cpu/ram будут весьма приличные?11 января 2017 в 19:45
0↑
↓
А почему не решились присоединить свои усилия к open scada? Вроде тоже QT там основной движок…11 января 2017 в 20:09
0↑
↓
Я бы добавил ещё один пункт.Возможность повторного использования компонентов. Вот у тебя есть одинаковых установки, которые стоят рядом друг с другом. Тебе хочется абстрагировать их в единый компонент, и с точки зрения управляющей логики, и с точки зрения взаимодействия с пользователем, а потом использовать трижды.
А на практике часто приходится использовать копипасту для размножения.
