CC BY
88
Доклады ТУСУРа. 2004 г. Автоматизированные системы обработки информации, управления и проектирования УДК 519.688
РАСПРЕДЕЛЕННАЯ СИСТЕМА ВИДЕОНАБЛЮДЕНИЯ И ИДЕНТИФИКАЦИИ ОБЪЕКТОВ
Б.А. Соловьев, В.Т. Калайда
В статье рассматривается пример создания программной системы управления прикладными процессами в системах видеонаблюдения и идентификации объектов как части систем обеспечения безопасности предприятия.
Видеонаблюдение занимает особое место при организации систем обеспечения безопасности объекта. Не секрет, что основную долю информации о внешней среде человек получает в визуальном виде. Органы зрения позволяют составить наиболее ясную модель внешнего мира, не говоря уже о том, что любую информацию человек стремится представить в виде схем и таблиц. Для того чтобы оценить происходящее или узнать человека или другой объект, не обязательно вступать в контакт с объектами, на которые в данный момент направлено внимание. По имеющейся визуальной информации можно сформировать представление о ситуации, действующих лицах и последствиях происходящего. Таким образом, для лучшего понимания ситуации, своевременной и адекватной реакции необходимо вести за объектами визуальное наблюдение. Человек же может в один и тот же момент времени находиться только в одном месте и уделить внимание только одной-единственной сцене. Для наблюдения за большим числом сцен человеку необходимы средства, позволяющие ему оценить ситуацию на большом расстоянии и с разных точек зрения. Для этого разрабатываются различные системы видеонаблюдения.
На первых этапах развития системы видеонаблюдения представляли собой набор камер, направленных на объект наблюдения, каждая из которых была подключена к монитору. Оператор вел постоянное наблюдение за территорией с помощью этих мониторов. Таким образом, задача немного упрощалась. Позже, для уменьшения числа дорогостоящих камер, на них стали ставить поворотные устройства, что позволило с помощью всего одной камеры вести наблюдение за большей территорией. Дальнейшее развитие систем видеонаблюдения привело к появлению устройств, позволяющих одновременно выводить изображение с нескольких камер на один монитор и вести видеозапись. Таким образом удалось уменьшить стоимость оборудования и снять часть нагрузки с оператора, так как наблюдать за одним монитором легче, чем за несколькими.
Современные системы видеонаблюдения строятся в виде распределенных программно-технических систем. Как правило, вывод изображения производится на монитор компьютера, программное обеспечение которого позволяет снимать изображения одновременно с нескольких камер, вести запись видео, а также автоматически отслеживать движение на наблюдаемой территории. Кроме того, современные системы видеонаблюдения позволяют получать изображение с камер не на один монитор, а с помощью сетевого интерфейса передавать видео на удаленную машину.
Современные системы безопасности требуют интеграции в них подсистем, отвечающих за различные аспекты обеспечения безопасности, которые по тем или иным причинам создавались и развивались, независимо. Они могут включать в себя подсистемы пожарной безопасности, охраны периметра, контроля доступа сотрудников, учета рабочего времени и т.д. Однако на сегодняшний момент такие интегрированные системы безопасности остаются лишь набором подсистем, слабо связанных между собой. Каждая из них отвечает за свою область деятельности и не ориентирована на присутствие рядом другой подсистемы, что позволяет решать задачи только в частном виде. Например, если система контроля доступа и система видеонаблюдения разрабатывались как отдельные функциональные части со своими внутренними правилами, то одна система не способна влиять на функционирование другой. Для использования ресурсов одной системы в другой необходимо обратиться к разработчику с просьбой об интеграции подсистем видеонаблюдения и контроля доступа. Это приводит к созданию новой системы, изменение или добавление новых функций в которую снова потребует ее перестройки.
Современные программные системы характеризуются сложностью структуры и широким спектром решаемых задач. Такие программные системы строятся из большого числа элементов, как правило, разрабатываемых разными специалистами в разных отделах и, возможно, на разных предприятиях. Проблемы стыковки элементов этих систем решаются по-разному и обычно приводят к появлению множества библиотек функций или классов. В связи с этим возникают проблемы частичной или полной несовместимости различных программных элементов и существенная ограниченность их возможностей [1, 2].
Последние методологии программирования, основанные на идее позднего связывания программных компонентов, позволяют программистам довольно изящно решать эти проблемы с помощью введения заранее оговоренных протоколов взаимодействия компонентов. Такой подход приводит к существенным выигрышам при сопровождении, обновлении и изменениях в программной системе, затрагивающих какой-то отдельный элемент, но не при изменении какого-либо из свойств системы в целом. Также появляется возможность наращивать функциональность системы по желанию пользователя без внесения изменений в саму систему и уже имеющиеся в ней на данный момент элементы простой поставкой нового элемента, реализующего нужные функции и заранее оговоренный интерфейс, с помощью которого остальные элементы системы смогут взаимодействовать с новым элементом. Естественно, что такие решения не позволяют вносить в систему существенные изменения. Структура системы жестко привязана к решаемой ею задаче, то есть является сугубо специфичной. Для придания системе существенно новых свойств потребуется пересмотреть всю ее структуру. И в этом случае программисту придется переписывать систему, ориентируя ее на решение новых задач, при этом начиная работу, практически, с нуля. Кроме того, все элементы подобных систем взаимодействуют друг с другом, имея определенные знания о составе системы в целом и существовании и содержании соседних элементов.
Целью работы является создание такой программной среды, которая позволяла бы в любой момент функционирования системы менять ее содержание и связи между элементами, задавать новые цели функционирования системы или отказываться от старых. Администратор
системы должен иметь возможность составлять из ее элементов конфигурацию, удовлетворяющую задачам, которые, по его мнению, должна решать система. Для этого программная среда, обеспечивающая взаимодействие элементов, не должна быть привязана к какой-либо заранее известной цели функционирования системы и не должна иметь никаких априорных знаний о возможном составе системы и связях внутри нее. Элементы системы также не должны иметь знаний об окружающей их среде и не должны быть ориентированными на взаимодействие с каким-то определенным элементом.
Таким образом, задача, решаемая системой в целом, разбивается на множество подзадач, каждую из которых может решить один элемент системы. Элемент сообщает внешней среде информацию о данных, которые он может принимать и обрабатывать, а также предоставить вовне. Пользуясь этими знаниями, администратор создает связи между элементами системы, ориентируя ее для решения своих задач [3].
Вся система представляется в виде иерархии подсистем, каждая из которых содержит элементы или другие подсистемы, выполняющие вполне определенные действия в рамках решения одной подзадачи. Таким образом, вместо модели «клиент-сервер» предлагается новая модель взаимодействия процессов, более естественная с точки зрения решения сложных задач. Теперь вместо терминов «сервер видеоперехвата», «сервер диспетчеризации событий», приходят понятия «подсистема видеоперехвата» и «подсистема диспетчеризации», и взаимодействие происходит не между клиентами и серверами, а между элементами подсистем.
Предлагаемая система состоит из набора элементов, взаимодействующих не между собой, а со средой передачи информации, в которой все эти элементы существуют. Реакция элемента на то или иное изменение информации также не направлена от одного элемента другому, а является причиной нового возмущения, на которое обязательно прореагируют какие-то элементы системы. Деление на подсистемы является условным, лишь для того, чтобы более наглядно представить работу системы в целом. Поэтому при построении нашей программной системы, обеспечивающей функционирование элементов по описанному принципу, задача поддержания структуры является не первостепенной для функционирования системы и решения ее задач. Служба поддержания структуры будет выступать в роли отображения реально существующего сложного графа прикладных задач и связей между ними в понятный пользователю вид. Кроме того, так как система в общем случае будет распределенной среди множества машин в сети, администратору интуитивно будет ясно, что элементы одной подсистемы лучше размещать на одной машине, так как связей между элементами одной подсистемы и плотность потоков, как правило, больше, чем между элементами разных подсистем. Это утверждение не всегда верно, поэтому проектируемая программная система должна иметь ряд средств, позволяющих ей оценить эффективность выбранной топологии как на этапе создания структуры системы, так и во время функционирования. По получении информации система сообщит администратору о возможности улучшения структуры системы с целью повышения качества функционирования.
Рассмотрим типовую структуру системы. На самом высоком уровне она может быть представлена в виде, показанном на рис. 1.
Далее на самом нижнем уровне декомпозиции, каждая из подсистем разбивается на составляющие элементы и выглядит, как показано на следующем рис. 2.
Рис. 1 - Упрощенная структура системы безопасности
Рис. 2 - Схема взаимодействия элементов системы
На этом уровне видны только сами элементы и связи между элементами. Особое внимание стоит обратить на то, что связи между элементами односторонние. То есть элемент поставляет какую-то информацию в среду, посредством которой осуществляется взаимодействие, и не заботится об ответе. В этом и заключается главное отличие нашей модели взаимодействия от модели «клиент-сервер».
Подсистемы показаны на рисунке пунктиром только для того, чтобы обратить внимание на то, что взаимодействие происходит на уровне элементов, а не на уровне подсистем. Так, в системе обеспечения безопасности элемент, отвечающий за идентификацию человека по лицу и находящийся в подсистеме контроля доступа, может пользоваться информацией, поставляемой элементом подсистемы видеоперехвата, отвечающим за снятие изображения с определенной камеры, например установленной на входной двери.
Состав системы будет постоянно изменяться, в нее будут вноситься новые возможности или улучшаться старые за счет внесения в нее новых элементов и связей. Для обеспечения совместимости новых элементов со старыми необходим механизм, позволяющий соединять между собой те элементы, которые потенциально могут быть соединены. То есть нельзя соединить между собой два элемента, один из которых поставляет на выход кадры изображения, а второй получает на вход звуковой сигнал. С этой целью в системе создается база данных типов сигналов. Каждый тип сигнала имеет уникальный идентификатор, который и позволяет определить, какой тип информации может быть получен от определенного элемента и в какой информации элемент нуждается.
База данных типов сигналов содержит глобальный идентификатор типа, описание типа в словесной форме и определение структуры сигнала, если таковое возможно. Эта информация может потребоваться впоследствии для мониторинга сигналов и для отладки отдельных прикладных процессов. Описание структуры сигнала состоит из полей, ссылающихся на один из базовых типов поля или на другой определенный в системе тип, словесного описания значения поля и размера поля, выраженного в количестве элементов данного типа. Возможны следующие базовые типы сигналов: двойное слово, целое и символ. На базе этих типов и по мере наращивания базы данных можно составлять более сложные типы с вложенными структурами.
Рассмотрим более детально процесс взаимодействия рабочих элементов. Этот процесс скрыт как от самих рабочих элементов, так и от администратора. Так как система в общем случае распределена по сети, необходимо организовать прозрачность взаимодействия элементов, находящихся как локально по отношению друг к другу, то есть на одном компьютере, так и удаленно. Для этого вводится компонент, обеспечивающий эту прозрачность, он отвечает за подключение элементов к информационной среде и доставку сообщений между ними в соответствии со структурой, заданной администратором. Условно назовем этот компонент шиной. Данный компонент должен присутствовать на каждой машине в сети, где находятся элементы системы. Шина создает виртуальный канал для каждой связи между элементами. В обязанности шины входит также оптимизация доставки сообщений и синхронизация там, где это требуется.
Оптимизация доставки сообщений достигается за счет уменьшения числа копирования сообщений. Шина берет на себя обязанность выделения памяти для каждого сообщения и организации очереди сообщений. Все сообщения существуют в одном адресном пространстве. В случае локальной передачи сообщения всем элементам передается ссылка на текущий элемент в очереди этого сообщения. Копирование происходит только на этапе создания нового сообщения и при передачи его через сеть шине другого компьютера, которая принимает это сообщение. Дальнейшие действия, связанные с этим сообщением, такие как рассылка элементам на удаленной машине и синхронизация, производит шина удаленного компьютера.
Здесь важен следующий момент. При асинхронной передаче сообщений всем элементам может возникнуть ситуация, когда сообщения достигают элементы в разное время или начинают обрабатываться не в том порядке, в котором они были сгенерированы. В этом случае взаимодействие элементов становится хаотичным, а результат работы системы в целом - непредсказуемым. Во избежание подобной ситуации делается попытка одновременной передачи сообщения всем заинтересованным сторонам и выдача разрешения на его использование в тот момент, когда все нуждающиеся элементы получили сообщение и его обработка может происходить более или менее синхронно. В случае доставки сообщения локальным элементам этот эффект достигается за счет примитивов синхронизации операционной системы. Все потоки, которые отвечают за обработку данного сообщения, находятся в состоянии сна до тех пор, пока не будет сгенерировано событие о начале обработки. В случае удаленной передачи в дело вступают протоколы сетевого мультикастинга, которые позволяют передавать сообщения группе пользователей одновременно. Таким образом, обеспечивается согласованное взаимодействие элементов и гарантируется последовательная их обработка.
Кроме описанного вида синхронизации иногда может возникнуть необходимость в дополнительной синхронизации нескольких потоков на входе какого-либо элемента. Например, в системе существует элемент, который обрабатывает сообщения нескольких типов. И эти сообщения должны приходить к нему в одно время в виде пакета сообщений. Для этого перед входом элемента создаются группы синхронизации сигналов. Группа синхронизации в момент прихода сообщения откладывает его доставку до момента срабатывания условия синхронизации. Здесь возможно несколько ситуаций. Первая - сигналы доставляются в момент, когда пакет полностью сформирован, то есть имеется весь набор сообщений, необходимых для работы. Вторая - когда пакет доставляется получателю в момент прихода синхронизирующего сигнала. И третья - временные метки сообщений отличаются не более чем на заданное значение.
Сказанное выше можно представить в виде, показанном на рис. 3.
Рис. 3 - Схема подключения элементов системы к шине
В дальнейшем планируется введение возможности изменения протоколов передачи данных в зависимости от их содержания, то есть, наряду с регистрацией нового типа сообщения и его структуры, будет возможность регистрации способа передачи данных этого типа.
В этом случае на стороне источника и приемника будет загружаться модуль, отвечающий за передачу и прием этих данных. Такая необходимость возникает при передаче, например, видеосигнала большого размера, но с нежесткими требованиями к качеству, в этом случае на стороне передатчика может происходить сжатие видеоинформации, а на стороне приемника -ее декомпрессия.
Таким образом, достигается совместное функционирование подсистем системы безопасности в распределенной среде. Предлагаемая модель является более естественной с точки зрения взаимодействия элементов сложных систем.
Так как количество элементов в реальной системе, а также связи между ними изменяются в процессе функционирования, каждый элемент должен выступать в роли изолированного элементарного рабочего модуля, а задача поддержания связей и взаимодействие элементов берет на себя разрабатываемая система.
ЛИТЕРАТУРА
1. Рихтер Дж. Windows для профессионалов: создание эффективных Мп32-приложений с учетом специфики 64-разрядной версии Windows. - М.: Издательско-торговый дом «Русская редакция», 2001. - 752 с.
2. Вильямс А. Системное программирование в Windows 2000 для профессионалов. -СПб.: Питер, 2001. - 624 с.
3. Рихтер Дж. Программирование серверных приложений для Microsoft Windows 2000 / Дж. Рихтер, Дж. Д. Кларк. - М.: Издательско-торговый дом «Русская редакция», 2001. - 592 с.
