Автоматизация процессов поверх видеоданных в KVM-инфраструктуре

Автоматизация процессов поверх видеоданных

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

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

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

Чем видеоданные отличаются от сырых параметров

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

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

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

Пример: динамическая реакция на изменение значения

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

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

Где такой подход полезен

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

Контроль подмены сайта

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

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

Такой метод не требует получать данные из CMS или веб-сервера. Он проверяет именно то, что увидел бы пользователь. Для задач защиты бренда и мониторинга публичного интерфейса это важное свойство: система контролирует внешний результат, а не внутренний статус сервиса.

Контроль камер и сообщения No Signal

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

Для человека надпись No Signal означает отсутствие изображения. Для системы, которая анализирует видеопоток, это тоже распознанный визуальный признак. Поэтому такую надпись можно использовать как триггер: если в одном из окон появилась строка No Signal, система определяет источник, находит подпись камеры, формирует уведомление и отправляет письмо оператору или инженеру. В письме может быть указан номер камеры, например Camera 123, если этот текст найден в зоне подписи.

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

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

Аналоговые приборы и коммунальная инфраструктура

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

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

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

Почему нужны натурные испытания

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

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

Ограничения автоматической реакции

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

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

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

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

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

Как работает ATEN RCM

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

Зоны, образы и коэффициент совпадения

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

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

Текстовая проверка работает аналогично. Система ищет заданную строку или распознает текст в выбранной зоне. Например, после обнаружения No Signal она может прочитать подпись камеры, чтобы понять, какой источник потерян. Далее этот текст используется в уведомлении: система формирует письмо с описанием события и вставляет найденный номер камеры.

Блок-схема условий и действий

Такие сценарии удобно описывать как блок-схему. Есть старт, входной поток, блок поиска образа, ветка true при совпадении, ветка false при отсутствии совпадения, блок распознавания текста, блок отправки письма, блок управления реле или внешний вызов. Это делает автоматизацию понятной для проектировщика и заказчика: видно, какая проверка выполняется первой, какие условия обязательны, какие действия запускаются после события.

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

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

Надстройка над рабочими местами

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

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

Запись действий операторов

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

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

Технические логи и их ограничения

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

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

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

Запись KVM-сессии

Для подробного анализа используется запись сессии. В этом случае фиксируется не только видео рабочего места, но и действия ввода: нажатия клавиш, движения мыши, клики, служебные клавиши, комбинации вроде Ctrl+C и Ctrl+V, Shift, Backspace, Enter. При просмотре записи можно увидеть, что происходило в интерфейсе, и одновременно посмотреть, какие конкретно клавиши нажимал пользователь.

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

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

Пример: несколько операторов и один источник

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

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

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

Расследование инцидентов и оптимизация процессов

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

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

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

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

Безопасность и комплексный контроль

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

Ошибки авторизации и подбор пароля

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

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

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

Когда запись действий нужна бизнесу

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

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

ATEN CCVSR и особенности внедрения

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

Формат записи и защита от подмены

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

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

Хранение, 4K и стоимость

Запись KVM-сессий требует много места. Это видео, причем часто видео рабочих мест с высоким разрешением. Если пишутся 4K-источники, объем архива быстро растет. Кроме хранения нужно учитывать количество одновременных сессий, нагрузку на сервер, политику ретенции, резервирование и права доступа к архиву.

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

Что нужно закладывать в проект

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

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

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