От экспертов «1С-Рарус»: Система управления машинным зрением. Анализ работы в общепите, АРМ и сетевые столовые. Часть 2

В первой части статьи о системе управления машинным зрением были рассмотрены основные моменты, которые оказывают существенное влияние на процесс эксплуатации системы в промышленных условиях. Учет особенностей использования машинного зрения в сфере общественного питания, вносимые коррективы при промышленной эксплуатации, место системы управления в большой функционирующей системе — вот лишь небольшой перечень вопросов, которые мы осветили.

Накопление и поддержание в актуальном состоянии данных для формирования «Датасета» формирует твердый фундамент для решения дальнейших задач. Аккумулирование данных в системе, инвентаризация и выбраковка — все это позволяет сформировать максимально корректный набор данных.

Какие дальнейшие задачи требуют решения при эксплуатации систем на основе машинного зрения? Как обеспечить работу пользователей в 1С:Предприятие для решения этих задач? Давайте обозначим широту и многообразие реализованного нами функционала без глубокого погружения в технические детали в силу ограниченности объёма статьи.

Анализ чеков как механизм для мониторинга стабильной работы

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

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

Аккумулирование и интерпретация данных — это задачи, которые необходимо решать уже в рамках самой системы управления. Эти задачи важны, так как заказчики в большинстве своем хотят видеть полную картину происходящего у них на объекте в прозрачном и понятном виде.

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

Разметка изображений как инструмент улучшения качества распознавания

Разметка изображений в машинном зрении представляет собой процесс добавления меток и аннотаций к визуальным данным. Метки преобразуют картинки в структурированную информацию, понятную для алгоритмов. Впоследствии это помогает алгоритмам машинного зрения эффективнее распознавать и классифицировать объекты.

Как и при анализе чеков, задача разметки изображений включает в себя несколько достаточно крупных подзадач. Сбор и доставка данных — тут все аналогично задаче анализа чеков. Отдельной подзадачей будет используемый инструмент установки регионов на изображение — тут могут быть использованы как сторонние программные продукты, так и собственные наработки. Ну и, конечно, хранение результатов работы разметчиков — эта подзадача будет решаться в рамках системы управления.

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

Борьба за производительность для повышения скорости работы системы управления

По мере функционирования и развития системы управления машинным зрением все более остро стояла задача оптимизации производительности системы. Промышленная эксплуатация систем сопряжена с накоплением больших объемов данных.

Прежде всего это данные, которые система управления получает по мере работы терминалов на объектах — чеки, изображения блюд и подносов, меню на каждый день. Степень интенсивности работы объектов отличается в зависимости от компании, но при этом всегда нужно быть готовым к тому, что объемы будут большими.

Другими блоками данных, которые будут храниться и обрабатываться в системе управления, являются производная от исходных данных информация — датасеты, результаты разметки.

Все это в связке с первичной разработкой системы на небольшом объеме данных привело к тому, что возникает необходимость в проведении оптимизации работы системы управления в сторону увеличения скорости работы.

Доступность и удобство просмотра информации для восприятия и анализа

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

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

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

Сложность и наукоемкость решаемых задач

Как можно увидеть выше, эксплуатация и развитие системы управления машинным зрением ставит большое количество интересных и сложных задач перед разработчиками. Формирование и доставка чеков, аккумулирование и анализ данных, развитие инструмента разметчика, оптимизация быстродействия системы — все этом достаточно комплексные задачи, от реализации которых зависит не только корректное функционирование системы управления, но и успех запуска проектов. Часто «львиную» долю времени на решение данных задач разработчики тратят на предварительную проработку решения. Это обусловлено необходимостью использования знаний из других областей науки для выработки решения.

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

Система управления — облачная или локализированная?

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

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

В случае выбора данного варианта работы необходимо отдельно формировать отправку всех необходимых данных (чеки, подносы, изображения, меню) с терминала клиента в систему управления. При этому у заказчика нет необходимости разворачивать систему управления у себя в организации на отдельном сервере. Так же этот вариант существенно облегчает поддержку и помощь заказчику от разработчиков системы управления, так как они видят происходящее в системе управления в реальном времени. В случае отсутствия «стоп-факторов» данный вариант взаимодействия предлагается заказчику в первую очередь.

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

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

Анализ чеков

Необходимо выполнять анализ для отслеживания и корректировки стабильности работы

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

Чек является индикатором стабильности и корректности работы терминала. Именно на основании данных, получаемых с чеками, можно анализировать рабочий процесс и, по необходимости, вносить в него коррективы. Анализ чеков является очень важной задачей, так как именно он позволяет выявить нарушения в стабильности работы системы при эксплуатации.

Отличия привычного розничного чека от чека системы управления

Классический розничный чек — это документ, который подтверждает факт покупки товара или услуги. Он формируется при помощи контрольно-кассовой техники и содержит сведения о приобретенный товарах/услугах, а также о продавце.

Чек в системе управления в определенной мере соответствует классическому розничному чеку, но при этом имеет ряд очень важных особенностей, которые отражают ход и результаты процесса распознавания блюд. Как и розничный, чек в системе управления отражает факт покупки товара, и содержит информацию о перечне блюд. Также в чеке есть информация об общей стоимости продажи — если такая информация присутствует на терминале. Что же отличает чек системы управления от классического?

Структурно чек состоит из двух частей — изображения подноса чека и состава данных о классах.

Изображение подноса чека представляет собой фотографию подноса, на основании которой осуществляется процесс распознавания блюд. Прежде всего, изображение подноса чека — это источник, на основании которого детектор выделяет отдельные регионы и идентифицирует их как изображения классов. Но кроме этого, изображение подноса чека позволяет нам выполнять визуальный анализ распознавания путем сопоставления того, что мы видим на фотографии, и состава определенных классов.

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

Результаты распознавания показывают данные о предсказанных и фактических классах. Предсказанный класс — это класс, к которому, по мнению модели распознавания, относится выделенное изображение блюда. Фактический же класс — это класс, который выбрал оператор, и к которому, по мнению оператора, относится выделенное изображение блюда. Наличие информации, и предсказанных, и фактических классах позволяет не только отслеживать ход процесса распознавания, но и осуществлять анализ, как стабильности и качества работы модели распознавания, так и корректности работы оператора.

Информация, которую получаем с чеками. Что позволяет отследить?

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

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

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

Дополнительные параметры распознавания. Включают в себя предсказанные классы по каждой из моделей, а так же данные с топ-5 предсказанных классов. Наличие этих данных особенно важно в случае, когда предсказанный и фактический классы отличаются.

Потоки информации по чекам в системе управления

Чек в системе управления содержит большой объем информации, который характеризует не только процесс продажи, но и ход операции распознавания. Далее рассмотрим, в каком виде вся эта информация поступает в собственную систему управления машинным зрением.

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

Первое направление — это сообщение со структурой чека и данными о продаже и процессе распознавания. Это сообщение является основным источником для формирования чека. В этом сообщении приходит весь блок данных, которые важны для анализа и отслеживания в системе распознавания. На основании данных с этого сообщения в системе формируется документ «Чек»:

Второе направление — сообщение с изображением подноса чека. Оно доставляет в систему данные с фото подноса, которые было выполнено при пробитии чека и выполнении операции распознавания. Изображение подноса чека хранится в системе с использованием механизма присоединенных файлов и соотносится с документом «Чек». Изображение подноса чека отражается в нижней части документа.

Как видно на картинке, в данном случае в систему управления уже пришли и данные о чеке, и данные об изображении подноса. Но что делать, если фото подноса чека попало в систему раньше, чем данные о структуре чека? Когда необходимо сформировать присоединенный файл к документу «Чек», а сам чек еще не сформирован:

В этом случае используется механизм «позднего связывания». Суть его в следующем. При возникновении ситуации, когда изображение подноса приходит в систему управления раньше, чем сам чек, формируется пустой документ «Чек», который содержит только изображение подноса. Далее, по мере поступления в систему управления сообщения со структурой чека, данные в документе «Чек» дополняются и новый документ не формируется. В результате формируется полноценный чек, которые содержит и данные, и изображение подноса.

Третье направление — это сообщения с изображением блюд. При выполнении распознавания блюд на подносе выполняется формирование изображений блюд для распознанных классов, которые отдельным сообщением поступают в систему управления. В собственной системе управления машинным зрением эти изображения хранятся с использованием механизма присоединенных файлов и ассоциируются со справочником «Меню», где хранятся классы (блюда). Изображения блюд отражаются в рабочем месте «Управление данными терминалов».

Особенности распознавания при формировании чеков

Добавленные позиции чека. Почему мы их не «увидели»?

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

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

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

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

Удаленные оператором регионы. Ошибка распознавания, или ошибка оператора

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

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

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

Расследованию данной ситуации способствует визуальный анализ изображения подноса чека по конкретному региону.

Корректность распознавания и предсказания. При различии — ошибка распознавания или неверный выбор оператором?

Возникновение ситуации несовпадения предсказания и распознавания наиболее интересно с точки зрения расследования причин его возникновения. Эта ситуация подразумевает случай, когда предсказанный детектором и указанный оператором классы различаются.

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

• Класс неверно определен системой распознавания. Причины этого различны, и о них мы поговорим ниже.
• Оператор ошибочно указал класс. Человеческий фактор никто не отменял.

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

Слияние блюд. Гарнир с гуляшом

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

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

Слияние блюд. Многоштучные блюда

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

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

Причины различия предсказанного и фактического класса. С какими случаями столкнулись?

По классу не проводилось обучение. Класс добавлен недавно или по нему было недостаточно изображений для обучения

В процессе эксплуатации может возникнуть ситуация, когда в состав меню добавлено новое блюдо. Такая ситуация случается достаточно часто, так как меню на объекте варьируется постоянно. На момент выполнения операции распознавания система не обладает данными об этом блюде:

• Информацию о блюде еще не успели внести в систему.
• По блюду не было ни одного изображения.
• По изображениям блюда не осуществлялось обучение.

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

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

Похожие внешне блюда

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

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

Изменение вида блюда с течением времени

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

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

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

Классификатор посчитал другое блюдо более приоритетным

Сопоставимая оценка степени уверенности появления блюда также может стать причиной неверной идентификации. И не обязательно, что блюда очень похожи. Просто конкретное изображение блюда на подносе, при его текущем положении и виде, по мнению системы распознавания, с большей степенью уверенности (и порой на совсем немного баллов) соответствует другому блюду. В таких случаях часто можно увидеть, что корректное блюдо в перечне вариантов идет на 2-м или 3-м месте с небольшим отрывом. Это свидетельствует о том, что система распознавания также рассматривала корректное блюдо, но отдала предпочтение другому.

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

Меняется формат блюда (1,1,5, 2 сосиски)

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

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

Инструменты для анализа продаж

Документ чек

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

Чек позволяет осуществить визуальный анализ по изображению подноса чека, а также сопоставить увиденное с составом, который определен оператором при пробитии чека. Более детально мы рассматривали чек выше.

Форма анализа распознавания

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

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

Еще один интересный механизм — это анализ данных по предсказанным классам. При работе моделей в систему управления машинным зрением приходит не только окончательный вариант ответа по предсказанному классу, но и первые 5 вариантов с весами.

Опираясь на эти данные, можно ответить на многие возникающие вопросы. «Почему выбран тот или иной класс?», «Рассматривался ли фактический класс моделью?», «Почему предпочтение отдано именно этому классу» — на все это даст ответ именно эта информация.

Анализ причин нераспознавания

Отчет «Анализ причин нераспознавания» предназначен для предоставления сводной информации по случаям неверного распознавания за указанный период на терминале. По предоставляемым данным есть возможность оценить общую картину в плане распознавания и выполнить первичный анализ, не погружаясь «вглубь». Какие же параметры анализируются?

Прежде всего, это предсказанный и фактический классы. Система показывает выбор модели и оператора в каждом конкретном случае. И, так как анализирует нераспознавание, классы всегда будут различны.

Для анализа работы моделей показан отдельный блок, который показывает следующие данные:

• Какой из моделей отдано предпочтение.
• Топ-5 классов с весами при распознавании. Эти данный позволяют предположить, по каким критериям было отдано предпочтение конкретной модели, и был ли результирующий класс в рассмотрении.

Анализ распознавания по классам

Отчет «Анализ распознавания по классам» показывает сводную картину по процессу распознавания блюд. Данные показаны не только в числовом виде, но и в форме «тепловой карты». Это инструмент наблюдения за системой в реальном времени в плане распознавания, что позволяет вовремя увидеть проблемы и, по необходимости, внести соответствующие коррективы.

Для каждого блюда в указанный период показано общее количество распознаваний и доля успешных распознаваний. Цветовая подсветка показывает общую картину визуально — зеленый цвет это хорошее состояние, красный — плохое.

Как же нам быть, если нужно перейти от общей картины к частной? Если после просмотра всей картины мы хотим более подробно проследить проблемные распознавания по классам? Для этого можно воспользоваться детальным отчетом по классу.

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

Анализ работы терминалов (тепловая карта)

Стабильная работа терминалов является одним из условий успешной промышленной эксплуатации системы. Клиенты всегда крайне болезненно реагируют на ситуации, когда при работе терминалов наблюдаются сбои. А уж тем более критические ошибки, которые ведут к остановке работы терминала.

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

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

Инструменты для разметки изображений

Необходимость разметки изображений подносов для обучения детектора

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

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

Следует отметить, что помимо собственно разметки, важную роль играет ранжирование самих изображений подносов. Засветка, плохое качество снимка, отсутствие полного изображений подноса на изображении — вот лишь небольшой перечень причин, на основании который стоит исключить изображений подноса из разметки и не использовать его в дальнейшем при обучении.

Для решения задачи разметки изображений подносов существует специальное программное обеспечение. Каждый может выбрать подходящее под задачи проекта программное обеспечение на свое усмотрение. При этом ничто не мешает написать свой инструмент разметки. Именно так мы и сделали в системе управления машинным зрением.

Выделение различных типов регионов

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

В системе управления машинным зрением в качестве основного мы используем регион «Еда», в качестве служебного — «Маска». Остальные регионы, представленные на изображении, использовались ранее при разметке, и сейчас необходимы для возможности просмотра размеченных ранее изображений подносов до необходимого уровня детализации.

Использование стороннего программного обеспечения для разметки. Переход в систему управления

Для выполнения разметки изображений существует различное программное обеспечение. Какое использовать — это вопрос не только функциональности, но и удобства. Прежде всего, у разметчика должна быть возможность размечать изображения в соответствии с требованиями системы обучения. Но разметчик — он тоже человек, и с учетом объема обрабатываемой информации громоздкое и неудобное программное обеспечение может затянуть весь процесс и вызвать отторжение.

Первоначально для осуществления разметки изображений использовалось программное обеспечение LabelMe.

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

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

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

Организация процесса разметки. Механизм установки регионов

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

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

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

Организация процесса разметки. Хранение истории разметок

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

На самом деле разметка — это скорее творческий процесс, при которым механическому распределению регионов предшествует предварительный анализ рабочей поверхности, выбор оптимального алгоритма разметки и многое другое.

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

Организация процесса разметки. Связь разметки и статусов подносов

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

Для ранжирования изображений подносов в системе управления машинным зрением мы используем дробление на статусы:

• Новый. Этот статус устанавливается подносу по умолчанию. Поднос с этим статусом недавно появился в системе и еще не был обработан разметчиком.
• Активный. Поднос с этим статусом обработан разметчиком и допущен для использования в процессе обучения.
• Бракованный. Поднос с этим статусом обработан разметчиком и исключен из использования в процессе обучения.
• Отложен. Поднос с этим статусом находится в работе у разметчика, его окончательное состояние еще не определено.

В обучении участвуют только подносы со статусом «Активный». Это позволяет использовать в процессе обучения исключительно размеченные подносы, у которые нет изъянов во внешнем виде.

Тонкости работы с «сетевыми столовыми»

Ситуация, когда для различных терминалов блюда идентичны

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

Как оказалось, существуют проекты, где заказчик однозначно утверждает, что на всех терминалах у него абсолютно одинаковые блюда, и изображения класса с одного терминала необходимо использовать для идентичного класса другого терминала. И фраза «это исключение, которое только подтверждает правило» перестала быть просто фразой.

Что же делать в этой ситуации? Полностью перерабатывать исходный подход? Вовсе нет. Указанная схема отлично укладывается в разработанный подход хранения изображений классов в разрезе проектов и терминалов. С одним лишь исключением — необходимо реализовать синхронизацию данных по изображениям классов между терминалами. Терминалы будут формировать так называемую «сетевую столовую». Это приведет к тому, что изображение класса, полученное на одном из терминалов, будет использоваться как изображение всех аналогичных классов остальных терминалов. Именно это нам и нужно согласно постановке.

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

Топология сети «Звезда»

«Звезда» является базовой топологией сети, в которой все терминалы сети присоединены к центральному узлу. Весь обмен информацией в данном случае идет через центральный узел.

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

Синхронизация данных при поступлении изображений от терминала в данном случае будет осуществляться следующим образом:

• новое изображение поступает на терминал;
• с терминала изображение отправляется на центральный узел;
• с центрального узла изображение уходит на все остальные терминалы.

Топология сети «Кольцо»

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

К преимуществам данной топологии можно отнести простоту установки, отсутствие дополнительного оборудования, возможность масштабирования без лишних затрат. Главный недостаток — надежность. При выходе из строя одного терминала вся сеть перестает работать.

Синхронизация данных при поступлении изображений в данном случае будет осуществляться следующим образом:

• новое изображение поступает на терминал;
• с терминала изображение отправляется на соседний терминал.

С соседнего терминала изображение отправляется на следующий терминал. И так до тех пор, пока не появится на каждом терминале.

Полносвязанная топология сети

В сети с данной топологией каждый терминал соединен со всеми терминалами сети. Соответственно терминал может одновременно обмениваться данными с каждым терминалом сети.

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

Синхронизация данных при поступлении изображений в данном случае будет осуществляться следующим образом:

• Новое изображение поступает на терминал.
• С терминала изображение отправляется на все терминалы сети через прямой канал связи.

Выбранные вариант топологии, реализация

Полносвязанная топология сети терминалов взята за основу при реализации «сетевой столовой» в системе. Один из основных критериев выбора данной топологии — это высокая надежность и отказоустойчивость. Выход из строя одного из соединений не будет приводить к потере данных между двумя терминалами, так как данные могут быть переданы через другие, пусть и более длинные, пути связи. Другим критерием, повлиявшим на выбор данной топологии, стала высокая скорость обновления изображений на терминалах. Это реализуется за счет наличия каналов связи между каждой парой терминалов.

Однако, в случае организации сетевой столовой, полносвязная топология может претерпевать определенные изменения. Например, в определенных случаях может не быть соединения каждого терминала с каждым. Одним из вариантов такого поведения может быть соединение в сеть нескольких кластеров терминалов. При этом все терминалы в рамках кластера будут соединены друг с другом, а кластеры между собой — одним соединением типа «мост».

При доступности терминалов, осуществляется отправка изображений. Следует отметить, что новые изображения оправляются в первую очередь, что обеспечивает отправку наиболее актуальных данных. Как и в случае с брокером сообщений, при синхронизации данных в «сетевой столовой» используется механизм «обратной квитанции» для повышения надежности.

Использование системы управления для регулирования процесса

Система управления машинным зрением может быть использована для управления процессом синхронизации изображений между терминалами «сетевой столовой». Что же изменится при организации управления синхронизацией через систему управления? Как будет выглядеть механизм в этом случае?

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

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

На основании данных о терминале система управления определяет состав терминалов сети, в которые необходимо отправить изображение, и проверяет его наличие в них. В том случае, если изображения на терминале нет, формируется запись в таблицу регистрации о необходимости отправки изображения в указанный терминал. Формирование сообщений и отправка их в брокер сообщений осуществляется по мере срабатывания фонового задания на основании данных таблицы регистрации. Мониторинг и управление процессом синхронизации изображений в системе управления осуществляется из рабочего места «Управление данными терминалов»:

Заключение

Преимущества, которые дает наличие инструмента управления

В заключении следует отметить, что запуск систем на основе машинного зрения в работу является достаточно сложной и комплексной задачей. Причем функционирование системы — это только основной этап, «начало разговора» так сказать. Не следует упускать из вида такие важные сопутствующие задачи, как мониторинг и управление процессом. Ибо во время эксплуатации системы у заказчика могут возникать не только вопросы по наличию ошибок.

Многие заказчики со своей стороны хотят понимания и прозрачности процесса работы системы, и вопросы могут сместиться от «почему не работает?» к «почему работаем именно таким образом?».

Именно система управления машинным зрением позволит ответить на эти вопросы и обеспечит и разработчиков, и заказчиков, необходимыми инструментами для мониторинга и анализа процесса.

Влияние промышленной эксплуатации на систему управления

Существенные коррективы, которые вносит промышленная эксплуатация систем на основе машинного зрения, являются не только интересными «вызовами» в профессиональной деятельности команды разработки, но и определяют пути дальнейшего развития системы управления машинным зрением. Причем речь идет не только о таких периодических процессах, как дообучение датасета, инвентаризация картинок, получение и анализ чеков.

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

Отдельным вопросом стала задача оптимизации производительности системы, которая появилась по мере интенсивного роста объема хранимых данных и возникающей необходимости обработки больших объемов информации. Высокая наукоемкость, вечное несоответствие функционирования «на бумаге» и «в полях», необходимость поиска решений в еще не до конца изученных областях — все это лишь повышает интерес к проекту, обуславливает необходимость совершенствоваться и развивать систему управления машинным зрением.