16,0
рейтинг
11 января в 17:12

Разработка → SCADA: в поисках идеала из песочницы

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:

Алексей Волков @SimarglSCADA
карма
6,0
рейтинг 16,0
Инженер АСУ

Самое читаемое Разработка

Комментарии (26)

  • 0
    Я так понимаю, что если оно пишется на Qt, то требования к cpu/ram будут весьма приличные?
    • +2
      Сам по себе QT много не требует. Даже на компьютере 10 летней давности запуск простых Qt приложений проблем не вызывают, не говоря уже про современные машины.

      Основное потребление cpu/ram зависит именно от самой задачи, которую решает приложение.
    • 0
      Действительно, требования конечного приложения оказываются довольно скромными. Проект на около 1000 тегов, со всеми потрохами потребовал примерно 100 MB RAM и успешно работает на простом планшете (IRBIS tw39) и стареньком нетбуке (MSI MS-N011).
  • +1
    А почему не решились присоединить свои усилия к open scada? Вроде тоже QT там основной движок…
    • 0
      OpenSCADA классный проект, но я пытаюсь использовать принципиально другую идеологию.
  • 0
    Я бы добавил ещё один пункт.

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

    А на практике часто приходится использовать копипасту для размножения.
    • 0
      Да, Вы правы. Это очень здорово, когда можно написать один виджет и использовать многократно из проекта в проект. А особенно приятно, когда эта возможность является гармоничной частью языка программирования, а не искусственным костылем.
      • 0
        Особенно, если ты из проекта в проект используешь одну и ту же железку: контроллер, датчи, реле — все одинаковые.
  • +3
    О как! :) Запасаюсь попкорном и занимаю первый зрительский ряд. Еще одна самописная скада!

    На самом деле, судя по текущему состоянию Вашей разработки, Вы еще в самом начале пути в состоянии уровня прототипов, поверьте мне, как человеку прошедшему уже многие эти этапы, и до сих пор идущего через многие новые. Но, желаю Вам удачи и главное — сохранить этот запал энтузиазма, аналогичный в свое время дал мне сил довести до коммерческого вида свое решение и продолжать его развитие и внедрение до сих пор. Готовьтесь, теперь у Вас появится оооочень много критиков. :)
    Ну, и если что — пишите, чем смогу подскажу, у меня граблей собрано было уже много по этой теме…
    • 0
      Спасибо! Надеюсь, что мне удастся повторить Ваш успех. А критики… это прекрасно, т.к. дают много идей для улучшения продукта. :)
  • 0
    Дело хорошее, однако название далеко от техники (тыц)

    Romer -а слушайте, он знает что говорит. )
    • 0
      Зато образ красивый – крылатый пес оберегающий посевы. :)
  • 0
    DeltaV — SCADA? ))) Вы делаете мне больно.
    • 0
      Признаю, с DeltaV погорячился. На практике видел только мельком и как-то не правильно воспринял. Спасибо за замечание.
  • 0
    Посмотрел на первый рисунок и сразу возник вопрос. Почему DeltaV отнесли к SCADA? DeltaV это распределенная система управления, но может я что-то не знаю? Можно купить у Emerson DeltaV в виде SCADA, отдельно?
  • 0
    мне приходилось писать свои скады — в основном, на c++builder (универсальное решение для армов на пк и для панелей визуализации) и даже на vb (только для панелей на базе win ce). плк тоже были под стать — micropc типа octagon и fastwel. да, программы для плк — тоже на c/c++ )
    потом много чего сделал на step7 + wincc 6/7. последние годы работаю с wonderware system platform.
    и мысли вот такие:
    — сименс после c++builder, после кода на c/c++ для плк показался просто раем. не фонтан, есть выбешивающие косяки, но терпимо и достаточно красиво всё можно делать;
    — ww sp — ужас и это нельзя применять в реальной, серьёзной автоматике. только диспетчеризация и прочие системы, допускающие кратковременные остановы/перезагрузки; что угодно может зависнуть без видимых указний на ошибки: всё коннектед, всё гуд, но не работает и на запросы не отвечает. самое печальное, что для лечения некоторых зависов нужен только редеплой, который только человеком и только вручную. как это продают?
    вот после ww возникает стойкое желание писать всё на самостоятельно.
    на qt можно, но лучше сразу иметь в виду трансляции экранов в веб.
    писать сразу для веба надо.
    проблемы в контексте таких велосипедов, собственно, две:
    — кто это будет поддерживать на условном заводе после внедрения и вашего отъезда;
    — реализация обмена данными.
    вопрос 1. согласился бы я принять систему для асу, созданную «на коленке» (не сименс, не аб, не вв, даже не овен и не кодесис), будучи рядовым руководителем службы асутп предприятия? в адеквате — нет. да, всегда есть нюансы, всегда есть лихие асушники, но это не мэйнстрим. это основная трудность.
    вопрос 2. на начальном этапе вы ограничены в выборе лишь пирогом в виде «ваша скада -> opc локальный -> что-то типа кепвэйр с кучей модулей». можете смело считать, что opc в чистом виде между скадой и другим пк на реальном предприятии работать не будет. и на реальном производстве есть и s7, и модбасы в самых разных реализациях, и opc, и всякие сущности, типа fs gateway.
    и на начальном этапе не нужно сразу проектировать именно ide, именно редактор скады. создайте сначала просто визуальные компоненты для того же дизайнера qt. (но всё таки напомню: забудьте всё, и пишите сразу для веб. инфа 100%)
    • 0

      Вы очень верно ухватили суть основных задач.


      Трансляция в веб нужна, но пока у меня не в приоритете.


      Ваш вопрос 1: да это серьезная задача вывести продукт на консервативный рынок автоматизации и сделать его мэйнстримом, но это верно для любого продукта. Будем работать :)


      Ваш вопрос 2: написание драйверов одна из приоритетных задач. В ближайшее время буду делать для siemens.


      По-поводу ide – наверно я плохо донес свою основную идею. Я вообще не буду делать свою ide. Моя главная задача: сделать так, чтобы разработка велась в Qt Creator и при этом была проще, чем в других SCADA.


      • 0
        я и правда серьёзно думал об этом — о замене на что-то своё (причём очень желательно — open source).
        тоже пару лет назад смотрел на qt именно в этом плане.
        но потом пришлось повозиться с d3js, с svg, с вебом… и qt как-то поблёк. веб, js, svg — это такая простая штука, такая универсальная! хочешь — отображай в любом браузере на десктопе. хочешь — верстай контейнеры в адаптивном стиле для всех этих смартов и чего угодно! хочешь производительность, риалтаймовость? приручи какой-нибудь веб-сервер, реализуй обмен визуалистики с бэкэндом чере те же веб-сокеты. красота!
        .я не веб-макакер — я как раз наоборот, от asm, от железа, от си, от stl/ld/etc, но я оценил ближайшее будущее именно так — это веб. и если вы один (вас мало), если вы не монстр типа сименса или шнайдера, то не стоит распыляться, я думаю. работать сразу универсальным образом.
        но может вы как-то иначе собираетесь прикручивать веб и мобильность.
      • 0
        Про web — правда. Надо с самого начала думать, как передать все в web. Потом «прикрутить» будет очень сложно.

        Сравнивать Qt и другие SCADA неправильно. Со SCADA-системами работают разные люди, порой они и понятия не имеют о программировании, а в Qt вынь да положь знание C++. SCADA, в общем-то, и нужна для того, чтобы уйти от программирования в сторону мышки. Технология производства выходит на первый план, думать о тонкостях C++ некогда, сдавать надо. А если еще и заказов много, то нанимать программистов под C++ будет очень дорого.
        • 0
          слишком категорично про неправомерность сравнения скад и qt.
          как правило, про ненужность программистов с «нашей самой лучшей скадой», про отказ вообще от тэгов и прочий шрот — это поле менеджеров, продаванов этих скад. этот шрот они грузят в уши менеджеров и покупашек от заказчика.
          допускаю, что можно рисовать очень простые проекты без программизма, но сам с этим не сталкивался. всегда есть код, и код порой очень и очень сложный. плюс вообще сложные техрешения. такова реальность. но — да, есть сименс и ко, есть языки мэк, среди которых есть и языки релейной логики в плк, и даже есть фбд в некоторых скадах (может кто напомнит, кстати: была или есть такая скада, вроде из австралии; забыл название). но кажущаяся простота выразительных средств языка никак не связана с необходимостью думать и придумывать.
          думать и придумывать, как малыми средствами, из небольших деталек, построить красивое здание решения — разве это не суть программирования?
          чем отличается тот же quick script от wonderware от си, от шарпа? только тем, что на нём гораздо сложнее сделать что-либо толковое. (си + vb в wincc — уже гораздо лучше!). поэтому для сложных алгоритмов мы берём ms vs и создаём библиотеку для archestra. потому что встроенные средства ww не убоги, но часто недостаточны и просто сложны в применении, если нужно сделать как раз что-то небанальное.
          а для qt есть привязки, так что c++ знать не обязательно. можно и на пистоне писать.
          • 0
            Вы все правильно говорите, совсем без программирования нельзя, ведь технологию нужно обсчитывать.

            Но, насколько я понял авторское высказывание о том, что среда (в его понимании IDE) не в приоритете (читай — не особо нужна), ситуация другая. В SCADA-системе уже есть инфраструктура, все уже между собой увязано, осталось только потоки данных раскидать и обсчитать (знаю, что выглядят мои слова слишком уж оптимистично). А тут получается, что дали мне Qt и сиди сам собирай всю скаду от начала и до конца. Думаю, это совсем другой уровень сложности.
            • 0
              Вы меня все-таки поняли не верно. Я не утверждал, что IDE не в приоритете. Я говорил, что в Qt уже есть отличная IDE и моя задача адаптировать Qt Creator под нужды автоматизации и завязать в единую инфраструктуру. В идеале, вы и не заметите особой разницы в процессе разработки по сравнению с классическими решениями (кроме гораздо более широких возможностей :)). 8 случаях из 10 Вам и не придется писать код вообще либо можно обойтись 2-3 строками.
  • 0
    По приведенному описанию сложно понять, насколько удобный и функциональный продукт. Думаю, вам никто в комментариях ничего ценного по этому поводу не напишет.

    Чтобы получить действительно качественный feedback нужно дать возможность попробовать поработать с продуктом сторонним пользователям. Опыт создателя программы не может быть до конца объективным в силу разных причин.

    Есть у вас возможность дать продукт на тестирование неподготовленным пользователям? Мне, например, было бы интересно посмотреть. Я сам много лет писал SCADA-систему, не в одиночку, конечно.
  • 0
    В будущем я обязательно дам возможность тестировать продукт всем желающим, но это требует плотной работы над документацией, процессом инсталляции и решения еще множества задач. Как только буду готов – отпишусь на хабре, вот только будет это еще не очень скоро.
  • 0
    В плане идеи использовать готовую IDE есть похожий проект Advanced HMI.
    Только там Visual Studio.

    У вас наверно будет преимущество кроссплатформенности?
    • 0
      Да. А еще стоимость — Qt можно использовать бесплатно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.