Комплекс программного обеспечения «МикСИС». Уникальная архитектура для систем с высокой устойчивостью и быстродействием

Компания «УМИКОН» – разработчик одноименного программно-технического комплекса ПТК УМИКОН, единственного отечественного универсального ПТК, который включает в себя и полнофункциональный комплекс программного обеспечения верхнего уровня, и полномасштабный комплекс технических средств. Но если с техническими средствами ПТК УМИКОН мы уже знакомили нашего читателя, то о ПО верхнего уровня разговор пойдет впервые. Чем же он выделяется на фоне других решений? Сегодня большинство разработчиков ПО, в том числе крупных и известных, являются сторонниками клиент-серверной архитектуры. Компания «УМИКОН» демонстрирует совершенно другой подход. Ее комплекс программного обеспечения (КПО) «МикСИС» – это уникальная разработка, позволяющая строить системы любой степени сложности без использования клиент-серверной архитектуры. Какие это дает преимущества? И какими характеристиками отличается такая система? Об этом мы беседуем с генеральным директором ООО «УМИКОН» Владиславом Лебедевым.

В. О. Лебедев, к. т. н., генеральный директор ООО «УМИКОН»

ИСУП: Владислав Олегович! Расскажите, пожалуйста, о назначении комплекса программного обеспечения (КПО) «МикСИС».

В. О. Лебедев: Комплекс предназначен для решения всего круга задач, которые связаны с автоматизированными системами управления – прежде всего управления технологическими процессами, но и АСУП1 то­же. Кроме то­го, он предназначен для настройки и конфигурирования (программирования) оборудования и ПО автоматизированных систем: от модулей контроллеров до АРМ в локальном и сетевом режимах.

ИСУП: Это, как я понимаю, что-то типа SCADA-системы? Или намного шире?

В. О. Лебедев: Намного ши­ре. SCADA – лишь одна из небольших функций, которая подразумевает поддержку интерфейса оператора в рамках АСУ ТП, архивирование данных и предоставление архивов, генерацию отчетов. Все это есть, но это только часть. Также производятся расчеты, в том числе в реальном времени, выработка управляющих воздействий в автоматическом режиме – не только в автоматизированном. Выполняются настройки, конфигурирование контроллеров и модулей ввода/вывода. Обеспечена возможность программирования и конфигурирования автоматизированных рабочих мест оператора – АРМ (как собственного, так и других – удаленно по се­ти), расчетных узлов (можно сказать, серверов, хо­тя у нас серверов как таковых нет – всё это узлы).

Я бы выделил несколько отличий нашего программного комплекса. Во-первых, все узлы в се­ти являются системами реального времени. Да­же автоматизированное рабочее место представляет собой контроллер с поддержкой реального времени и надстройкой для отображения и конфигурирования. Это позволяет иметь единые средства программирования для всех уровней системы: от модулей ввода/вывода до АРМ и расчетных узлов уровня предприятия. Они у нас целиком графические (то есть программирование сводится к конфигурированию), полностью ограждающие разработчика от синтаксических ошибок, позволяющие редактировать программу непосредственно во время ее работы, немедленно наблюдая результат редакции, а также однозначно выкачивать из контроллера работающую там программу, например, для ее дальнейшего редактирования и обратной загрузки. Насколько нам известно, ни одной из этих возможностей не обладают никакие иные системы и средства программирования, поэтому мы защитили свой приоритет патентом РФ на изобретение № 2668738 от 15.11.2017 «Способ и система для визуального создания программ для вычислительных устройств».

Вторым важным отличием является уникальная система сетевого обеспечения. Наш приоритет здесь закреплен патентом РФ на изобретение № 2707675 от 17.06.2019 «Способ организации хранения данных на узлах сети с передачей данных между узлами се­ти с предсказуемой загрузкой узлов се­ти для систем реального времени». В частности, работа в локальной се­ти ти­па Ethernet осуществляется по такому алгоритму, при котором передачей данных полностью управляет передающий – источник данных, а не приемник. Это дает возможность использовать в том числе и широковещательные пакеты. В се­ти может быть неограниченное количество узлов, притом что ее загрузка остается, в общем-то, низкой. Сотни, тысячи узлов, десятки тысяч, если на­до! Ничего похожего у других разработчиков ПО нет.

Важно подчеркнуть, что мы не применяем дисциплину «клиент – сервер» ни в каких функциях реального времени на АРМах, контроллерах, вычислительных узлах (серверах) – нигде. Она возможна только в режиме настройки и конфигурирования.

ИСУП: А что это глобально дает?

В. О. Лебедев: Это дает устойчивость системы. Алгоритмы такие, что DDoS-атака невозможна, поскольку узел работает в рамках собственной конфигурации. Ни на какие запросы он не отвечает, их просто бесполезно посылать. Но, конечно, DDoS-атака – это крайний случай. Главное, что передачей данных управляет источник, обеспечивая абсолютную устойчивость системы во время работы. В клиент-серверной архитектуре источник (сервер) зависит от запросов клиентов. Соответственно, чем их больше, тем больше он нагружен. Начиная с определенного момента, основные его ресурсы тратятся на ответы клиентам, а не на собственную работу – это особенность любой клиент-серверной архитектуры. У нас такое в принципе невозможно, поэтому система изначально устойчива.

Клиент-серверная архитектура неустойчива, работает она вероятностно – до тех пор, по­ка систему не перегрузили. На­ше твердое убеждение состоит в том, что в АСУ ТП клиент-серверную архитектуру применять не просто неэффективно, а опасно.

ИСУП: Поддерживается ли подключение оборудования других производителей? Как быть с драйверами?

В. О. Лебедев: Подключение стороннего оборудования поддерживается. Во-первых, мы поддерживаем Modbus TCP/UDP. Кроме то­го, поддерживаем OPC, хо­тя и стараемся не использовать по вышеизложенной причине. OPC – это клиент-серверная архитектура, таящая в се­бе опасность развала системы в самый важный момент, когда происходит максимум изменений и событий. Именно в этот момент клиент-серверная архитектура и развалится. Но для связи с чужими устройствами она у нас есть.

Еще некоторые протоколы поддерживаются, в частности, электротехнический протокол МЭК 60870-5-101/104, промышленные протоколы ADAM ACSII и т. д. Но основной – Modbus, который используется для связи с продуктами других производителей. Для внутренней связи у нас свой сетевой обмен.

ИСУП: Какую структуру имеет КПО «МикСИС»?

В. О. Лебедев: КПО «МикСИС» охватывает очень много различных компонентов. Но если говорить о структуре АРМ или контроллера верхнего уровня, то ту­да обязательно входит ядро реального времени для Windows или Linux: соответственно MWBridge или MLB. Среди других компонентов – средства обновления программного обеспечения и конфигурирования, для АРМ – система отображения (рис. 1). Есть программы уровня MES: средства расчета технико-экономических показателей, планирования производственных задач, система генерации отчетов, средства программирования как АРМ, так и контроллеров. Ну и другие компоненты, которые просто долго перечислять.

Рис. 1. Пример мнемосхемы (увеличить изображение)

ИСУП: Комплекс программного обеспечения «МикСИС» – мультиплатформенное решение. Используете только Linux или Windows?

В. О. Лебедев: Система в принципе мультиплатформенная. Для верхнего уровня есть исполнение под Li­nux и исполнение под Windows – разные программы. Кроме то­го, для контроллеров нижнего уровня предназначена собственная операционная система реального времени. Это не Windows и не Li­nux, а полностью на­ша разработка.

ИСУП: Расскажите о ней хо­тя бы в двух словах.

В. О. Лебедев: Она обладает минимальными функциями, то есть обеспечивает функционирование модуля ввода/вывода или контроллера (в зависимости от количества входов/выходов или имеющихся интерфейсов). Поддерживает жесткое реальное время с тактом 1 мс. Обеспечивает отсутствие программных прерываний и отсутствие очередей в системе. Конечно, мы не можем избежать аппаратных прерываний, но, по крайней ме­ре, нет программных прерываний. Система имеет строгую однозадачную внутреннюю структуру и строго детерминированное исполнение всего процесса, что обеспечивает ее устойчивость и производительность. Поддерживаются интерфейсы RS-485 (протокол Mod­bus RTU и другие), Ethernet (Mod­bus UDP) и наш сетевой протокол.

ИСУП: Предусмотрена ли в вашей системе поддержка веб-интерфейса?

В. О. Лебедев: Веб-интерфейс у нас имеется уже более 15 лет. Однако, поскольку это принципиально «клиент – сервер», мы реализовали такую поддержку в качестве периферийной опции, которая может использоваться, но по вышеуказанным причинам мы этого не рекомендуем при построении АСУ ТП.

ИСУП: Но это удобно.

В. О. Лебедев: Это удобно для разработчиков, им проще сделать систему отображения, потому что ее собирают из готовых «кубиков». Но все недостатки, о которых я говорил, здесь встают в полный рост. Завалить такую систему очень легко. Ну и производительность, конечно, на том же оборудовании будет примерно в сто раз ни­же, лишних деталей в ней очень много. Я знаю, что АСУ ТП на клиент-серверной архитектуре сейчас многие делают, потому что это проще и дешевле для разработчика – не для пользователя. Но функциональность у такой системы меньше и производительность гораздо ниже.

ИСУП: Возможно ли локальное использование одного или нескольких компонентов для решения отдельных частных задач?

В. О. Лебедев: Да, возможно. Но и система в целом может быть как локальной, так и распределенной. Сперва она компактная, локальная, потом расширяется. Можно, начав с одного модуля ввода/вывода и небольшой информационной системы выстроить сеть из сотен компьютеров и тысяч модулей с задачами автоматического управления и прогностического анализа.

ИСУП: А лицензирование и стоимость лицензий как-то зависят от количества точек автоматизации?

В. О. Лебедев: Скорее зависят от размера и сложности системы в целом. Количество точек у нас никогда не ограничивалось, а такие факторы, как количество АРМ или сложность функций системы, влияют на стоимость лицензии.

ИСУП: Можно ли создать на ба­зе вашего решения малые системы автоматизации, например, автоматизировать пе­чи сушки или построить еще какие-то локальные системы? Я имею в ви­ду с точки зрения финансов.

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

К тому же можно использовать отдельные компоненты комплекса, например графический редактор. У нас встроенный графический редактор, который обладает уникальным свойством: он совмещенный – и растровый, и векторный, и 3D. Всё в одном. Также можно использовать отдельно систему ТЭП, генерацию отчетов.

ИСУП: Как организована защита КПО «МикСИС» от несанкционированного доступа и фальсификации данных?

В. О. Лебедев: Защита от несанкционированного доступа у нас имеет несколько уровней. Самая надежная защита – структурная, на уровне конфигурации оконечного оборудования. Поскольку нет возможности посылать запрос и получать ответ, то к узлу вы не сможете получить доступ со своего узла никаким образом. Это абсолютное средство защиты. При этом важно выделение АСУ ТП в отдельную, физически развязанную с остальными сеть или группу сетей.

Второй уровень – это защита конфигурации ядра реального времени. Третий – защита интерфейса оператора. Есть и четвертый уровень – защита от удаленной настройки. У нас иерархическая структура се­ти, но иерархия эта собственная. Поэтому пролезть с одного уровня на другой стандартными средствами невозможно. Но самое главное – защита интерфейса пользователя: человек просто не может выйти за мнемосхему оператора.

ИСУП: А подсистема обработки видео- и аудиосигналов – о ней что можно рассказать?

В. О. Лебедев: Обработка видео- и аудиосигналов – функция, встроенная в на­шу систему, в ядро реального времени. Видео- и аудиосигналы являются для нас такими же сигналами, как аналоговые и дискретные. Просто в системе они разделены на разные ба­зы данных: есть ба­за аналоговых сигналов, ба­за дискретных сигналов, ба­зы видеосигналов и аудиосигналов. Ну или видео- и аудиопотоков. Естественно, по размерам две последние базы данных меньше: если аналоговых и дискретных сигналов – сотни тысяч, до миллиона, то видео- и аудиопотоков – по тысяче.

Они связаны между собой, то есть можно управлять дискретными сигналами по результатам обработки видеосигналов. И наоборот: по значениям аналоговых и дискретных сигналов можно менять обработку видеопотоков – например, количество кадров в секунду или разрешение. Имеется архивация видео, хо­тя, конечно, архивы видео- и аудиосигналов требуют совершенно других ресурсов, чем для дискретных или аналоговых сигналов. Соответственно, видеосигналы отображаются наряду с аналоговыми/дискретными сигналами на мнемосхемах (рис. 2). Их можно двигать, менять размеры, поверх видео изображать аналоговые и дискретные значения. С мнемосхем можно управлять камерами, поворачивать их и менять фокус. Можно проецировать видеоизображения на динамически меняющие свое положение и форму в зависимости от текущих значений параметров техпроцесса трехмерные фигуры. Кстати, все мнемосхемы в нашей системе трехмерные, просто обычно третье измерение не задействовано. Есть ли аналоги такого решения, да­же не знаю.

Рис. 2. Пример мнемосхемы с видео в полноэкранном режиме (увеличить изображение)

___________________________________________
1 АСУП – автоматизированные системы и сервисы управления предприятием.

Статья опубликована в журнале «ИСУП»

Статья на сайте журнала >>