Anthonybatow

Мы участвовали со стендом. То есть смотрели на выставку не только как посетители, но и как люди, которым два дня подряд задавали вопросы. А это, знаете ли, очень отрезвляющий опыт. Посетитель может уйти от хаоса. Участник стоит в нём по расписанию. Я регистрировался на мероприятие и как посетитель. И меня сильно достали письмами с "самым последним выгодным предложением покупки входного билета" и проверкой моего настроения после выставки. Навязчиво. Утомительно.

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

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

Главная проблема GITEX была не в масштабе. Масштаб как раз был. Главная проблема была в том, что масштаб не превратился в ясность.

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

Мой коллега отлично описал эту серию выставок:

"...тут всё на как повезёт, люди ходят разные, есть бабули-несуны, которым нужна раздатка и халявные флешки, а есть и действительно интересующиеся и ищущие, но вот как их вычленить из этой орущей и ничего не понимающей толпы - загадка. Остаётся надеяться на то, что каким-то образом стенд привлечёт внимание именно того человека именно в тот момент. Ну, и понты конечно!"

Самый частый вопрос на нашем стенде в первый день был: «А что это и где применяется?»

И вот тут, признаться, мне стало немного грустно. Потому что вопрос сам по себе нормальный. Человек может не знать продукт. Человек может интересоваться. Но когда таких вопросов очень много, возникает ощущение, что значительная часть посетителей не понимала, куда пришла, зачем пришла и что именно ищет. Они ходили между стендами как герои Достоевского по Петербургу: тревожно, душно, с внутренним вопросом «что же всё это значит?» Только вместо Сенной, Фонтанки и топора были бейджи, пакеты и презентационные буклеты.

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

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

Из содержательных разговоров у меня получились встречи с компаниями из своего и смежных рынков: Avigilon, Seagate, Intant, Bitrix24, Asbis. Вот там можно было говорить предметно, потому что есть продукты, задачи, рынок, применение, опыт. С остальными часто возникала странная ситуация: либо говорить было не о чем, либо на стенде стояли люди, которые сами не до конца понимали, зачем они здесь.

И это, пожалуй, главный вывод по GITEX: событие шумное, сырое, но, в какой-то мере, перспективное. Потенциал есть. Интерес есть. Рекламная машина работает. Казахстан действительно хочет выглядеть технологической площадкой региона. Но пока между лозунгом «AI-first future» и реальной выставочной практикой лежит большое поле, на котором разбросаны провода, баннеры, случайные стенды и посетители с вопросом «а что это?».

Вопросы вроде бы правильные. Но есть одна неприятная деталь: если начать с них, можно очень уверенно спроектировать систему, которая технически работает, но практически не решает задачу. Любая подсистема безопасности, будь то СВН, ОПС, СКУД, периметральная охрана (я имею ввиду ТСОБ) или что0то другое должна начинаться с самого важного документа - КСБ - концепция систем безопасности, где будет описаны основные требования и определения.

Если закупать оборудование по принципу "вот тут надо посмотреть за входом, а там дальше разберёмся" то получается почти всегда плохо. Камеры показывают картинку. Регистратор пишет архив. Монитор выводит изображение. Сервер обрабатывает потоки. Всё включается, мигает, записывает и даже иногда радует заказчика первые пару недель. А потом происходит инцидент, и выясняется, что лица не видно, номер не читается, оператор не понял, куда смотреть и что делать с тем что увидел, архив нашли только через три дня, а нужный фрагмент почему-то не записался или уже затёрся.

На этом месте обычно начинается великая русско-интеграторская драма: заказчик говорит, что система плохая, проектировщик говорит, что всё было по СНИПам, ГОСТам, нормам, монтажник говорит, что поставил как нарисовали и как заплатили, поставщик говорит, что камеры хорошие, а служба эксплуатации молча смотрит в монитор и думает о смене профессии.

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

Что такое эксплуатационные требования

Эксплуатационные требования это не просто список технических характеристик. Это описание того, какую задачу система должна решать в реальной жизни. Не «камера 5 Мп, объектив 2.8 мм, ИК-подсветка 30 метров», а: что мы хотим увидеть; зачем мы хотим это увидеть; в какой ситуации это должно произойти; кто будет смотреть; как быстро человек должен отреагировать; что будет считаться успешной работой системы; какие действия должны последовать после обнаружения события; достаточно ли видеонаблюдения для решения этой проблемы; можно ли обойтись другой системой.

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

Если у вас исчезает что-то ночью со склада, возможно, сначала нужно поставить нормальные светильники? Если проблема в том что по территории "шаряться не понятные элементы", возможно, сначала нужны ограждения, ворота, СКУД и правила доступа? Если проблема в том, что охрана проспала кражу, видеонаблюдение может помочь, но оно не заменит управление персоналом. Хотя было бы удобно: поставил камеру на охранника, и дисциплина сама выросла. Спойлер: нет.

Эксплуатационные требования помогают ответить на главный вопрос: какую реальную функцию должна выполнять система видеонаблюдения в конкретном месте?

Четыре этапа нормального проектирования

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

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

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

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

Первый уровень требований: сначала проблема, потом камера

Эксплуатационные требования первого уровня нужны для того, чтобы понять саму природу проблемы. Перед тем как решать, где ставить камеры, нужно ответить на более простые и более неприятные вопросы: Какие угрозы есть на объекте? Где именно они возникают? Кого или что мы защищаем? Какие последствия будут, если инцидент произойдет? Какие зоны наиболее критичны? Какие заинтересованные стороны должны быть вовлечены? Какие меры уже существуют? Может ли проблема быть решена без видеонаблюдения? Это уровень не про оборудование. Это уровень про управленческую и эксплуатационную задачу.

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

Кража с полки, конфликт у кассы и идентификация человека на входе требуют разных ракурсов, разной детализации, разных сценариев наблюдения и, скорее всего, разных камер. Если всё это свалить в одну кучу, получится классическое «поставьте, чтобы всё было видно». А «чтобы всё было видно» обычно означает, что потом ничего толком не видно там, где это действительно нужно. Очень часто после такого "проектирования" опытный монтажник на объекте прикручивает к потолку длиннющего коридора гостиницы камеру с фиксированным объективом 2,8мм и плачет...

План объекта как инструмент мышления

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

Это крайне простая вещь, но именно она часто отделяет проектирование от шаманства над каталогом оборудования.

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

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

Заинтересованные стороны: кто потом будет жить с этой системой

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

Служба безопасности хочет видеть инциденты и иметь доказательства. Эксплуатация хочет, чтобы систему можно было обслуживать без акробатики и проклятий. IT хочет, чтобы к ним с этим вообще не лезли видеонаблюдение не положило сеть. Охрана хочет, чтобы интерфейс был понятным, а не как кабина сбитого инопланетного корабля с Альфа-Центавра, рассчитанная на 9,5-руких цефалоподов. Юристы хотят, чтобы записи можно было использовать корректно и законно.

Если на этапе требований эти интересы не собрать, то они не исчезнут, они всё равно появятся позже. Только уже в виде конфликтов, доработок, претензий и фразы «а почему нас раньше никто не спросил?».

Оценка рисков: не все угрозы одинаково важны

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

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

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

Критерии успешности: что значит «система работает»

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

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

инцидент обнаруживается только после жалобы, а не в момент события.

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

Хороший критерий успешности отвечает не на вопрос «какая камера стоит», а на вопрос «какое действие мы можем выполнить благодаря системе».

Второй уровень требований: что именно мы хотим наблюдать

После того как мы поняли общую проблему, можно переходить к требованиям второго уровня. Здесь появляются вопросы "Что я хочу наблюдать?" и "Почему я хочу наблюдать именно это?". Это звучит почти примитивно, но на практике такие вопросы часто не задаются. Вместо них говорят: «Поставим камеру сюда, чтобы было видно вход». Хорошо. А что именно должно быть видно на входе? Общий поток людей? Факт прохода? Лицо человека? Документ в руках? Попытка несанкционированного прохода? Направление движения? Очередь?

Конфликт? Оставленный предмет? Каждый ответ приводит к разному проектному решению.

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

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

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

Видеонаблюдение как часть системы, а не волшебная таблетка

Отдельно стоит проговорить: видеонаблюдение никогда не "сработает в одиночку". Оно должно быть частью комплекса мер затрагивающих: - освещение; - физические барьеры; - СКУД; - охранную сигнализацию; - регламенты действий персонала; - работу операторов; - маршруты патрулирования; - процедуры доступа к архиву;/ - обучение сотрудников; - интеграцию с другими системами.

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

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

Почему расследование после факта не всегда победа

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

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

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

Именно поэтому четвертый этап, верификация, нельзя воспринимать как формальность.

Верификация: проверять нужно не наличие картинки, а выполнение требований

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

Главная ошибка: путать техническое задание и список оборудования

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

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

Если функция не описана, оборудование подбирается почти вслепую. Иногда опытный проектировщик вытаскивает проект на интуиции. Иногда монтажник на объекте спасает здравый смысл. Иногда заказчику просто везет. Но проектирование на везении это не методология. Это плохое казино с RegirstedJack-ом и утекающими PoE-бюджетами.