Как выбирать систему видеоаналитики

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

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

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

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

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

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

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

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

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

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

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

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

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

Если нужно добавить в систему камеры, есть два варианта действий:

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

Системы видеоаналитики представляют собой сложные инженерные системы. Их выбор требует специальной экспертизы, которой большинство ИТ-департаментов предприятий не обладают.

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

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

При использовании 10–15 камер оптимальный срок для установки и тестирования системы – одна-две недели. Заказчик предоставляет сервер, а ИТ-специалисты выделяют два-три дня на развертывание решения, которое затем тестируется в течение 5–10 дней. Если же у поставщика нет наработок или готового решения, он, скорее всего, не сможет в такой срок продемонстрировать результат, поскольку не успеет внести в систему изменения для учета специфики камер заказчика. 

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

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

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

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

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

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

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

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

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

* * *

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>