Open Source Process Control!!!

     Оле, оле-оле-оле!!!     
     Итак — свершилось!! Так сказать — наконец-то!! Триумф воли и системы, крупной организации и разделения труда — короче исключение, которое подтверждает правило!         
     Начну издалека — в области АСУТП в области же металлургии, тяжелого машиностроения и иже с ними, а так же близких отраслей, доминирование проприоритарных решений, на базе ли Linux или же Windows, преобладали абсолютно и преобладают до сих пор, и что ещё более чем вероятно — будут преобладать.    
     Редкие  и неоднозначные попытки сделать Open Source систему АСУТП для этих отраслей накладывались на следующие ограничения:

  1. Трудоемкость реализации проекта из-за необходимости поддержки определенного количества протоколов, а так же сопутствующего, для их реализации, аппаратного обеспечения;
  2. Реализация необходимого уровня быстродействия системы (в области автоматического управления по заданному алгоритму и т.д.);
  3. Реализация сносной, как минимум мало-уступающей, самым дешевым средствам визуализации уровень графических представлений для операторов тех.процессов;
  4. Реализация и ведение архивов тревог, сообщений, трендов и вывод их для операторов в произвольной форме, с обязательной привязкой к значению сохраняемой величины;
  5. Реализация архитектуры клиент-сервер;
  6. Разграничение доступа;
  7. Возможность связи со сторонними системами по унифицированным (де-факто — принятыми в отрасли) протоколам. В нашем случае — это OPC (вот здесь находится независимый сайт нацеленный на разработчиков OPC-серверов и OPC-клиентов). А это соответственно ссылки на двух самых известных производителей OPC-серверов — Matrikon и KEPWare.
  8. Ряд других.

     Не менее важен был такой стандартный и традиционно ругаемый компонент как служба поддержки и документация. То в каком виде это было представлено у разработчиков Open Source — для АСУТП не подходило никоим образом. В этом была своя специфика, которая разработчиками не учитывалась.    
     К тому же, из-за вышеупомянутой трудоемкости и предъявляемой SCADA системам требованиями — разработка затягивалась, версии долго не обновлялись, количество ошибок и падений систем было слишком много, а пути их решения — далеко не всегда однозначны. Учитывая то, что эксплуатировать SCADA системы будет заводской персонал, в душе не знающий, в массе своей, как и куда приладить очередной конфиг.файл из под  Linux, а любой простой будет записан на счет того, кто внедрит такую "устойчивую" систему — желающих было не много, в общем-то мало их было. Но они были.    
     В конечном итоге, именно один из таких "внедренцев" и объявился со своим продуктом.    
     Сразу же надо оговориться, что внедренец это SSAB — шведский производитель листового проката и металло-проката. К этому надо добавить, что в целях экономии, 20-ть лет назад было решено использовать в виде SCADA систему — систему на базе Linux. Разработки и доработки шли и удут уже 20-ть лет, а сама система, как в откомпилированном виде, так и в виде уже готовых пакетов выложена и готова к применению.
     Сайт системы ProView.     
     Собственно, если бы эта система не соответствовала бы, в большей части, тем чем обладают проприоритарные SCADA пакеты — речь бы о ней и не шла.
     Но ведь нет же!
     В системе реализована концепция PC-based Automation. Это вещь достаточно известная и достаточно долго применяющаяся. К слову о птичках на данный момент есть две ярко выраженные тенденции в АСУТП и их применении — использование PAC (Programmable Automation Computer) и PLC (Programmable Logic Controller). Кординальные отличия, если грубо, заключаются в том, что первые строятся на базе обычных микропроцессоров, вторые — специальные устройства. Первые под управлением тех или же иных версий Win и Lin ОС, вторые — свои собственные системы реального времени на базе как того же WxWorks, либо же, скажем QNX.
     Использование системы ProView ближе скорее к первой группе. Используется ПК, естественно в промышленном исполнении, желательно, безусловно, забить его памятью и не скупиться на процессоре.
     Система может и используется одновременно как и SoftPLC, так и как HMI система.
     Как HMI система, ProView обладает следующими функциями:

  • Разграничение прав доступа;
  • Архивирование и аварийные тревоги и сообщения;
  • Создание мнемосхем с использованием развитых функций отображений и большой палитры всевозможных анимационных компонентов (де-факто — это давно уже стало стандартом);
  • Возможность использование внешних компонентов системы Linux (поскольку система Open Source, да к тому же ещё и отлаженная — тут вы ограничены своей фантазией и возможностями);
  • Безлимитная БД тэгов;
  • Возможность дополнения системы своими собственными компонентами, а так же возможность, опять же — дело тут в вас и больше ни в ком — написать свой собственный протокол сбора данных и монтировать его в систему;
  • Возможность работы по OPC-протоколу (в качестве OPC-сервера, но так же и клиента — на момент написания поста, автор это не опробовал!).

     Как SoftPLC система, ProView обладает следующими функциями:

  • Программирование на языках симейства IEC 61131-3;
  • Программирование на языках высокого уровня;
  • Шаговая автоматика;
  • Использование протоколов PROFIBUS, MODBUS RTU/ASCII/TCP для сбора данных с устройств ввода/вывода;
  • Широкая поддержка периферийных устройств про-ва ф.Siemens, вплоть до того, чтобы напрямую к ним обращаться, минуя использование gsd-файлов.

   Безусловно есть и документация на английском и форум работающий, и какая-никакая, но реклама — более 450-ти внедрений на 2-х металлургических заводах (один в Швеции, другой в США — правда надо сказать, что первый — это завод разработчиков системы).
    Однако, как и у любой системы — есть недостатки:

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

    Однако, за исключением первого, которое надо всегда держать при себе, это всё отступает на второй план, когда мы обращаемся к тем выгодам, которые система, потенциально сулит. Тем более, что основным плюсом выступает именно её Open Source реализация, что позволяет серьёзно сэкономить на АСУТП (собственно так где её можно использовать без помех, так это в диспетчерских системах — водоснабжение, насосные, теплоснабжение, управление горелками, теплообменниками, системы сбора и управления релейных шкафов стендов испытания, общепромышленные механизмы и прочее — там где не нужны сверх-скорости и сверх-точность, а это собственно — уже не мало! Кроме всего прочего — несмотря на все отличия от построения проприоритарных SCADA систем, сам принцип проектирования сохранен, так же как и представление элементов).
    В общем — шведам остается пожелать только успешного плавания и непотопляемости!!!
    ПыСы — небольшое дополнение к вышеизложенному — обнаружен был демо-проект!!! Так что всё ещё более сказочно!! :)

Об авторе Kaliban