Статьи

ПРОЕКТИРОВАНИЕ ПЛАТФОРМОНЕЗАВИСИМЫХ СИСТЕМ УПРАВЛЕНИЯ И РАСПОЗНАВАНИЯ НА БАЗЕ ЯЗЫКОВ СТАНДАРТА IEC 61499

В настоящее время всё больше растёт популярность фреймворков, предоставляющих модельно-ориентированную среду разработки и проектирования (Matlab Simulink, LabVIEW, Scratch и пр.). Данный подход существенно ускоряет прототипирование и разработку системы за счёт повторного использования готовых блоков из доступных библиотек.

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

Для решения вышеперечисленных проблем предлагается обратиться к стандарту IEC 61499, который регламентирует разработку и реализацию программного инструментария для интеллектуальных систем, а также задает распределённую событийную архитектуру разрабатываемых систем. Они строятся на основе элементарных единиц – функциональные блоки, решающие определенные задачи. Блок состоит из интерфейса, описанного на расширяемом языке разметки XML, и исходного кода. Он может быть написан на языке C++ при разработке с помощью фреймворка 4diac IDE с последующим выполнения средой 4diac FORTE. Forte предполагает реализацию логики функциональных блоков на языке С++. Большое количество нейросетевых алгоритмов и алгоритмов обработки изображений разрабатываются на Python. Для повышения скорости и гибкости разработки может быть целесообразным предоставить пользователю возможность вести разработку функциональных блоков для IEC 61499 на языке Python. Проект с открытым исходным кодом DINASORE предлагает реализацию среды исполнения IEC 61499 на баз Python. Однако, на текущий момент в DINASORE нет стандартного способа работы с алгоритмами обработки изображений.

В текущий момент существует библиотека функциональных блоков, которые можно разделить на следующие категории:

- Функциональные блоки ввода/вывода, предоставляющие функционал по работе с файлами и файловой системой.
- Алгоритмические блоки – блоки реализующие высокоуровневые задачи. В рамках данной категории были разработаны блоки, решающие классические задачи технического зрения (фильтрация изображения, классификация, обнаружение, трекинг объектов).
- Сервисные блоки необходимые для разработки самой системы или используемые для отладки и просмотра промежуточных результатов обработки данных.

В качестве примера применения предлагаемого подхода была реализована система для определения объектов и их отслеживания на изображении ниже:

Пайплайн системы технического зрения для среды исполнения Dinasore

Данная система была реализована для исполнения в среде DINASORE, однако используемые блоки также имеют реализацию для исполнения на C++. При разработке систем обработки изображений в IEC 61499 существует проблема неэффективной работы с памятью при передаче данных (в текущей системе – изображения) между блоками. Для её устранения в функциональные блоки для работы с изображениями был добавлен специальный флаг (идентификатор очереди QUEUE_ID), который позволяет разместить данные в общей памяти и изменять их по ассоциативному ключу. Данный ключ должен передаваться на вход каждому блоку, где необходима работа с этими данными. Для окончания работы с ними был реализован удаляющий фреймы функциональный блок.

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

Основной сложностью данных систем является получение и синхронизация изображений с нескольких камер. При использовании пары web камер, разница во времени снятия кадров может достигать до 0.3 секунды. При построении 3D модели статического объекта, данная разница не является критичной, однако при использовании в системах с динамическим объектом, данная разница очень критична. Чтобы синхронизировать камеры необходимо использовать аппаратную или программную синхронизацию.

Для получения синхронизированных кадров используются блоки CAMERA_S и CLK_GEN. Блок CLK_GEN генерирует событие, по которому камеры должны одновременно сделать снимок и положить в очередь под ID, который пришел от блока CLK_GEN. После успешного снятия изображения, блок CAMERA_S генерирует об успешном снятии изображения.

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

Блок STEREO_MATCHER получает стереоизображение из очереди и строит по нему карту глубины. В текущей реализации карта глубины строится с помощью алгоритма StereoBM. Параметры необходимые для работы алгоритма, блок получает из входных полей: SWS, PFS, preFiltCap, minDisp, numOfDisp, txtrThrshld, unicRatio, spcklRng, spklWinSze. Полученную карту глубины блок передает следующему блоку в пайплайне.

Блок REPROJECT – преобразует карту глубины в 3D координаты объекта с помощью матрицы преобразования Q (может быть получена при калибровке).

Пайплайн системы получения 3D координат объекта с помощью стереозрения

Унификация блоков не только позволяет абстрагироваться от привязки к языку программирования, но и создавать неоднородные системы управления, состоящие из агентов разных аппаратных платформы (x86, aarch64) и работающих на разных операционных системах (Linux, Kaspersky OS, Microsot Windows, и пр.)
Пример мультиагентной системы с разными средами исполнения

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