Проект видеоаналитики у интегратора часто начинается с таблицы функций. Детекция людей, подсчёт транспорта, контроль касок, пересечение линии. Заказчик видит длинный список, соглашается, система запускается, на панели растут графики. Через полгода выясняется, что события никто не открывает, а расширять проект на другие площадки заказчик не хочет. Формально всё работает. Деньги на следующий этап не выделяют, потому что никто в компании не может сказать, какую свою проблему он этим решил.
Мы занимаемся компьютерным зрением для предприятий с 2016 года и такой сценарий на рынке видели часто. Причина почти всегда одна: проект собирали от возможностей системы, а заказчик платил за ответ на конкретный вопрос своего процесса.
С чего начинать обследование
Первый разговор полезнее вести с тем, кто отвечает за процесс, а не со службой безопасности или ИТ. Начальник склада скажет, что у него теряются места при отгрузке и непонятно, на каком участке. Технолог упаковки скажет, что в коробки иногда докладывают не то число пачек и это всплывает у покупателя. Из такой фразы и получается задача: какой факт система должна зафиксировать, кто получит сигнал и в какую систему он попадёт.
Последний пункт интеграторы часто откладывают на потом, хотя от него зависит, будет ли проектом пользоваться смена. Событие с кадром, которое уходит в WMS, журнал смены или чат мастера, кто-то увидит и обработает. Событие, которое лежит только на отдельной панели видеоаналитики, через месяц перестанут смотреть.
Пилот на видео заказчика
Второй источник разочарований — обещания, перенесённые с чужих внедрений. Точность на демонстрационном ролике производителя ничего не говорит о конкретной линии: другой свет, другой ракурс, другая укладка товара. На странице, где мы описываем, как устроено компьютерное зрение для бизнеса (https://visor-group.ru/uslugi/kompyuternoe-zrenie/?utm_source=novostiitkanala&utm_medium=article&utm_campaign=goal5000_novostiitkanala), это вынесено отдельно: числовые показатели зависят от объекта и из коробки не переносятся.
Показательный пример из нашей практики — пилот подсчёта пачек в коробке на линии ручной упаковки. Модель, обученная на сторонних фотографиях, на записях этой линии не посчитала верно ни одну из 26 коробок. Подсчёт доработали под реальную укладку, после чего на роликах, которые модель при настройке не видела, сошлись 28 коробок из 28. На потоковой проверке верный итог получился по 52 коробкам из 56. И даже это остаётся результатом пилота на записях, следующий шаг — замер на оборудовании самой линии. Если бы систему поставили сразу в эксплуатацию, первые недели ушли бы на споры с заказчиком, а не на работу (рис. 1).
Ограничения записываются в ТЗ
Перекрытия, неудачный ракурс и слабый свет снижают точность на любой платформе. Интегратору выгоднее назвать это до договора и заложить в техническое задание: какие камеры придётся переставить, где нужен дополнительный свет, при каких условиях сценарий не работает. Критерии приёмки фиксируются заранее, на видео заказчика. Тогда разговор на сдаче идёт о цифрах, о которых договорились, и проект не превращается в спор о впечатлениях.
Что это даёт интегратору
Проект, собранный вокруг одного вопроса, легче защитить внутри компании заказчика: у него есть владелец, понятный результат и место в учётной системе. Дальше его проще расширять. Камеры на объекте уже стоят, и на них можно добавлять следующие задачи: после подсчёта на упаковке — контроль средств защиты в цехе, после учёта паллет — контроль зон хранения. Каждая новая задача снова начинается с вопроса конкретного руководителя, и заказчик сам приходит со следующей, когда видит, что предыдущая закрыта.
Список функций в коммерческом предложении никуда не денется, по нему сравнивают поставщиков. Но решение о втором и третьем этапе принимают по тому, ответила ли система на первый вопрос.
Источник: Антон Савельев, ведущий специалист по компьютерному зрению, Visor Group
Иллюстрация предоставлена пресс-службой компании
