![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/b/2930/180575.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/1.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/2.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/3.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/4.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/5.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/6.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/7.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/8.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
![Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]](/i/d/4899/180575/450/9.png "Математические модели и программные средства распределенных систем видеонаблюдения и идентификации объектов [Электронный ресурс]")
Содержание к диссертации
Введение
1. Методы построения распределенных систем безопасности 11
1.1. Состав современных систем видеонаблюдения и контроля 11
1.2. Методы реализации программного обеспечения 16
1.2.1. PelcoMATCH Facial Recognition System . 21
1.2.2. Acsys Biometrics , 23
1.2.3. A4Vision (Applications for Vision) 24
1.2.4. Videolnspector 26
1.3. Подходы к реализации распределенных систем 29
1.3.1. RPC 31
1.3.2. Java RMI 32
1.3.3. COM 34
1.3.4. CORBA 38
1.4. Формулировка требований к современным распределенным системам 41
1.5. Выводы ...42
2 Методология и программный комплекс для разработки распределенных систем «Базис» 43
2.1. Формулировка требований к методологии и комплексу «Базис» ...43
2.2. Предлагаемый вариант решения 44
2.2.1. Модель прикладных объектов. 47
2.2.2. Объект-модуль 49
2.2.3. Типы сигналов. 50
2.2.4. Объект-значение 51
2.2.5. Входы и выходы прикладного объекта 52
2.2.6. Именование объектов «Базис» 52
2.2.7. Шина объектов «Базис» 53
2.2.8. Менеджер конфигураций «Базис» 57
2.2.9. Внутренние механизмы «Базис» 59
2.2.9.1. Модели организации потоков данных 59
2.2.9.2. Управление прикладными объектами 64
2.2.9.3. Рекомендации по организации потоков исполнения в прикладных объектах 66
2.2.10. Управление конфигурацией «Базис» 71
2.2.11. Счетчики производительности «Базис» 75
2.2.12. Журнал событий «Базис». 80
2.2.13. Перенос и развертывание объектов «Базис» 82
2.2.14. Безопасность , 84
2.3. Имитационное моделирование систем, построенных по методологии «Базис» 87
2.4. Модели конфликтных ситуаций при распределении нагрузки... 92
2.5; Моделирование алгоритма подстройки интенсивностей потоков данных...95
2.6, Выводы .101
3. Построение распределенной системы видеонаблюдения и контроля доступа с использованием программного комплекса «Базис» , 102
3.1. Проект прикладного объекта «Базис» 102
3.2. Средства управления и отладки объектов «Базис» 106
3.3. Системная база данных 108
3.4. Компоненты интегрированной системы безопасности 114
3.4.1. Компонент отображения видеопотока 114
3.4.2. Компонент выделения лиц на изображении , 115
3.4.3. Компонент опознавания личности по изображению лица 117
3.4.4. Компонент перехвата видеопотока 120
3.4.5. Датчик движения и покоя 121
3.4.6. Совместная работа модулей унаследованной системы Лик 122
3.4.7. Компонент видеоперехвата для нескольких потоков 123
3.4.8. Компонент считывания ключей системы «Лик» 124
3.4.9. Компонент управления исполнительными устройствами системы «Лик» 125
3.4.10. Контроллер источника. 126
3.4.11. Протокол доступа и видеонаблюдения 126
3.4.12. Оповещение о наличии сигнала. 128
3.5. Интегрированная система безопасности на базе комплекса «Базис» 128
3.6. Оценка характеристик программного комплекса для построения распределенных систем видеонаблюдения и идентификации объектов «Базис». 133
3.7. Выводы 141
Заключение. 142
Список используемой литературы.
- PelcoMATCH Facial Recognition System
- Предлагаемый вариант решения
- Управление конфигурацией «Базис»
- Компонент видеоперехвата для нескольких потоков
Введение к работе
Актуальность работы. В настоящее время процесс создания комплексных системы безопасности требует интеграции в них различных подсистем, отвечающих за множество отдельных аспектов безопасности, которые по тем или иным причинам разрабатывались параллельно и независимо. К таким подсистемам относятся системы пожарной безопасности, охраны периметра, контроля доступа сотрудников, учета рабочего времени и т. д. Хотя интеграция этих систем является актуальной проблемой, они по-прежнему остаются лишь набором слабо связанных между собой подсистем, а иногда и неспособных работать в комплексе. Каждая из них отвечает за свою область деятельности и не ориентирована на присутствие рядом другой системы. Таким образом, остро стоит вопрос о создании технологии обеспечивающей унифицированный подход к построению и управлению интегрированных систем безопасности, обеспечивающей возможность постоянного дополнения функциональности систем и изменения списка подсистем, отвечающих за новые аспекты обеспечения безопасности.
До 1990 года интеграция планировалась только на очень серьезных объектах и представляла собой простое проводное соединение специализированного "интегрируемого" оборудования. Между тем, такое объединение различных систем обладает ограниченными возможностями, причем связано это с исходной неприспособленностью интегрируемого оборудования к решению задач системного уровня.
Широко представленные в прессе проекты для большого спектра областей применения выделяют обобщенную схему их реализации, где предлагается трехуровневая иерархическая модель, включающая уровень полевого оборудования, уровень интеллектуальных контроллеров и серверов реального времени и уровень операторских станций. Каждый из уровней предполагает индивидуальный подход к разработке программного обеспечения (ПО), зависящий от решаемых на выбранном уровне задач, что не решает вопроса о взаимодействии компонент разных производителей.
Существуют решения, где разработчики предпринимают попытку создания своих моделей для решения широкого круга задач обеспечения безопасности с ис- пользованием программного и аппаратного обеспечения различных производителей. Такие попытки приводят к появлению в системах множества модулей-драйверов и адаптеров, в то же время четко определяя функции и положение каждого из типов компонентов, как в сети, так и в подсистеме. Так четко выделяются сервера видеонаблюдения, сервера пожарной сигнализации, операторские станции, система аудио-оповещения и т.д., работающие по правилам ядра системы безопасности, предоставляемого каждым из разработчиков. К таким системам, поддерживающим довольно много производителей можно отнести Интегра-С и Lyrix.
Новейшие методологии программирования, основанные на идее позднего связывания программных компонентов (такие как COM/DCOM, CORBA, JAVA, ОРС и т.д.), позволяют программистам решить проблемы совместимости различных подсистем с помощью введения заранее оговоренных протоколов взаимодействия компонентов. Как правило, разработчики уделяют мало внимания на возможности интеграции систем от разных производителей. Кроме того, структура большинства распределенных систем жестко привязана к решаемой ей задаче. Для придания системе "существенно новых" свойств, потребуется пересмотреть всю ее структуру. Кроме того, все элементы подобных систем взаимодействуют друг с другом имея определенные знания о составе системы в целом и существовании и содержании соседних элементов, а взаимодействие компонентов системы рассчитано на заранее определенные типы компонентов, что отрицательно влияет на масштабируемость больших информационных систем.
Из всего сказанного следует, что необходима методология построения интегрированных распределенных систем безопасности, которая должна быть универсальной, и не накладывать ни каких требований к внутренней реализации самого объекта и используемым в нем технологиям. Такая методология остро необходима в современных условиях роста спектра функций выполняемых системами безопасности и тенденций к интеграции их с другими подсистемами жизнеобеспечения. Она позволит формализовать процесс создания распределенных систем, ориентированных на решение не только существующих задач, но и задач, которые появятся со временем. Кроме того, существует настоятельная потребность решения задач интеграции не только применительно к системам безопасности, но и к сложным информацион- ным системам, использующихся в автоматизации производства и распределенных систем моделирования. Новая методология-должна существенно повысить эффективность построения распределенных программных комплексов и взаимодействия процессов программного обеспечения.
Основная цель работы: повышение эффективности проектирования, создания и администрирования распределенных интегрированных систем безопасности, путем введения модели формальных компонентов, для обеспечения унифицированного способа управления, и модели взаимодействия элементов источник-приемник, обеспечивающей оптимальное взаимодействие процессов в программной системе.
Для достижения поставленной цели, необходимо решить следующие задачи:
Определение модели объектов;
Разработка метода и реализация управления объектами (удаленное и локальное); :
Создание модели связи между объектами и способа взаимодействия, как между локальными, так и удаленными относительно друг друга объектами в среде с разнородными данными;
Моделирование процесса функционирования системы для оценки работоспособности;
Разработка метода и реализация механизма управления конфигурацией системы;
Разработка метода и реализация управления скоростью потоков данных для ограничения нагрузки на локальную систему и сеть;
Моделирование конфликтных ситуаций, возникающих при настройке интен-сивностей потоков данных;
Методы исследования. В качестве основных методов исследования выбраны метод математического моделирования и эксперимент, проводимый по замкнутой схеме, опирающийся на: математический аппарат статистического анализа; методы математического программирования; численные методы; методы функционального, объектно-ориентированного программирования.
Защищаемые положения:
Модель программного компонента распределенной системы, включающая три категории компонентов: генератор, приемник и комплексный объект, обеспечивающая унифицированный способ управления потоками данных, компонентами и связями между ними.
Имитационная модель распределенной программной системы, построенной по схеме взаимодействия источник-приемник и объект-посредник, позволяющая выявлять возможные ситуации переполнения очередей данных и перегрузки системы, возникающие в процессе функционирования подобной системы на этапе проектирования.
Методология построения распределенных программных систем, по схеме источник-приемник и объект-посредник для доставки сообщений, обеспечивающая формализацию процесса создания и администрирования приложений, содержащих обратные связи любой топологии.
Модель объекта-посредника передачи данных между программными компонентами, реализующая распределенную среду передачи, позволяющая обеспечить обработку информационного потока одновременно всеми компонентами цепи обработки.
Алгоритм управления потоками данных в системе в условиях неполной информации о текущей конфигурации и производительности ее компонентов, на основе анализа текущего состояния параметров компонент системы обеспечивающий их оптимальную настройку и предотвращающий возникновение конфликтных ситуаций.
Достоверность результатов диссертационной работы подтверждается экспериментальными данными, полученными при использовании программно-технических систем созданных при непосредственном участии соискателя, имеющими как научную, так и практическую ценность. Достоверность результатов, выводов и положений диссертационной работы обеспечивается: тщательной разработкой методик и алгоритмов создания и функционирования распределенных систем; - совпадением параметров распределенной системы при моделировании и проведении экспериментальных испытаний; практическим использованием систем в производственных условиях ООО «Радио и сигнальные системы», Томского управления исполнения наказаний и ФГУП НИИ ПП, г. Санкт-Петербург.
Научная новизна:
Создана модель компонента программной системы, основанная на использовании объектов генераторов, приемников и комплексных объектов, обеспечивающая построение распределенной вычислительной системы произвольной топологии.
Построена имитационная модель распределенной вычислительной системы, основанная на взаимодействии последовательных процессов и обеспечивающая оценку загрузки каждой компоненты и выявление потенциально критических ситуаций.
Разработана методология построения программных систем, основанная на модели формального элемента и объекта-посредника, обеспечивающая организацию взаимодействия элементов распределенных систем масштаба предприятия любой топологии, содержащих обратные связи.
Разработан алгоритм управления потоками данных в условиях неполной информации о производительности компонентов и текущей конфигурации системы, позволяющий индивидуально настраивать параметры каждого компонента без возможного зависания процесса.
Практическая значимость:
Разработанная методология построения распределенных вычислительных систем послужила основой для создания программного инструментального комплекса «Базис» — универсальной системы реализации распределенных программно-технических комплексов любой сложности и топологии масштаба предприятия.
С использованием комплекса «Базис» реализованы распределенная по локальной сети система видеонаблюдения и контроля доступа «Лик» и локально-распределенная (реализованная на одном компьютере) система идентификации личности по документам «Аккорд — Т»,
Разработанные в диссертации методические, алгоритмические и информационные средства имеют практическую значимость независимо от топологии и архитектуры локальной вычислительной сети, типов ЭВМ и операционных сред.
4. Результаты исследований используются в учебном процессе на факультете автоматизированных систем ТУ СУР при чтении курса лекций и проведении лабораторных работ по дисциплине «Теория вычислительных процессов» и при выполнении научно-исследовательской работы студентами кафедры АСУ.
Апробация работы. Основные научные результаты работы докладывались и обсуждались на следующих конференциях: международная научная студенческая конференция «Студент и научно-технический прогресс», НГУ (г. Новосибирск, 2002, 2003, 2004, 2005); Всероссийская научно-техническая конференция студентов и молодых ученых «Научная сессия ТУ СУР», ТУ СУР (г. Томск, 2003, 2005); ежегодная международная научно-техническая конференция студентов и аспирантов «Радиоэлектроника, электротехника и энергетика», Московский Технический Университет (г. Москва, 2004); всероссийской научной конференции студентов-физиков, АСФ (г. Екатеринбург, 2005). Результаты исследований докладывались на научных семинарах кафедры Автоматизированных систем управления Томского государственного университета систем управления и радиоэлектроники.
Основное содержание диссертации отражено в 14 научных работах (в'том числе в 4-х научных статьях, 10 докладах на конференциях различного уровня).
Структура и объем работы: Диссертация изложена на 151 страницах, содержит 47 рисунков и 15 таблиц, и состоит из введения, трех глав, заключения, и списка используемой литературы из 93 наименовании и работ соискателя.
PelcoMATCH Facial Recognition System
Pelco, крупнейший в мире производитель систем безопасности, добился крупного прорыва в технологии идентификации по лицу. PelcoMATCHTM Facial Recognition System, первая в США система идентификации по лицу, была внедрена 26 октября 2001 года в международном аэропорту г. Фресно, штат Калифорния. Эта технология разработана для идентификации лиц, причастных к террористическим группировкам. Система получает снимки людей на проверочных пунктах аэропорта и сравнивает их с хранящимися в базе данных фотографиями лиц, подозреваемых в террористических актах. Если сходство определено, система подает сигнал полиции.
Основная часть программного обеспечения была разработана специально для данной системы Массачусетским технологическим институтом и биометрической компанией Viisage.
Система PelcoMATCHTM включает патентованные камеры с высокими техническими характеристиками, мощные, высокоскоростные компьютеры, встроенное устройство цифровой записи с камер, а также опоры для камер.
Идентификационная система DX9000 PLUS — это решение проблемы безопасности в аэропортах. Разработанная специально для наблюдения за пассажирами в аэропортах и транспортных терминалах, DX9000 PLUS это комплекс, использующий систему идентификации по лицу PelcoMATCH наряду с системой цифровой видео записи Ре] со DX9000.
DX9000 PLUS может сигнализировать офицерам одновременно по всему зданию, этим гарантируется своевременность ответных мер. Любая активность на отслеживаемом участке записывается, и пользователи могут быстро получить изображение места до, в течение и после сигнала тревоги. Удаленные пользователи могут также переключиться в режим реального времени.
DX9000 PLUS предназначена для установки совместно с металлодетектором. Пассажиров просят пройти через него под наблюдением персонала из службы безопасности. Видимая часть системы устанавливается на высоте шесть футов, а металлическая стойка расположена около пятнадцати футов позади металлоискателя. Одна стойка приходится на один проход металл оискателя. На этой стойке устанавливаются видеокамера высокого разрешения и сигнальные лампочки, которые помогают регулировать пассажирский поток.
Терминал наблюдения спроектирован для управления за четырьмя проходами: Записывающее видеоустройство связано через модем или сеть с удаленными терминалами.
Помимо этого, система может управлять сигнальными лампочками на проверочных постах. Когда конкретный человек проходит через металлодетектор, на экране высвечивается ПРОХОДИТЕ зелеными буквами. Система сравнивает лица в момент прохода через огороженный участок. Если установлено сходство с базой данных, индикатор меняется на красный СТОП, и подается сигнал тревоги. Металлодетектор используется просто для ограничения свободы передвижения субъекта, что дает возможность камере сделать снимок лица[22].
Acsys Biometrics представляет на рынке ряд своих продуктов для систем контроля доступа с использованием биометрических методов проверки идентичности личности. Она начала свое продвижение на рынок биометрических систем безопасности весной 2003 г. Среди продуктов Acsys множество различных решений для государственных департаментов, банков, игорных заведений, электронной коммерции, а так же в сферах безопасности и медицины. Программное обеспечение настраивается в зависимости от требований заказчика.
Ядром технологии биометрической идентификации фирмы Acsys является технология HNet (Holographic Neural Technology). В HNeT используется модель человеческого мозга. Фактически в ней реализованы все понятия нейрофизиологии, такие как корка мозга и синапсы.
Технология HNet определяет как отдельные нейронные ячейки способны узнавать образы немедленно в реальном времени. Технология основана на симметричных нейронных сетях. При установке простой системы на обычный компьютер, сеть реализованная в программе способна запоминать до десятков тысяч образов и узнавать образ среди этих десятков тысяч в течение одной секунды[30].
Система видеонаблюдения Acsys состоит из трех следующих компонентов. Один или более клиентов видеонаблюдения, сервера видеонаблюдения и одного или более мобильных устройств для передачи сообщений о событиях.
Каждый клиент системы видеонаблюдения отвечает за выделение лиц и поиск их в реальном времени в собственной базе изображений размером до 5000 личностей.
Сервер наблюдения получает от клиентов статичные изображения. Эти изображения передаются клиентом на сервер в случае, если клиент не смог самостоятельно опознать субъекта, сервер может производить опознание среди 100000 записей.
Мобильное устройство для сообщений - это беспроводной карманный компьютер, который получает сообщения и изображения от клиента видеонаблюдения. Мобильный компьютер получает изображения опознанных личностей.
Сервер и клиенты системы видеонаблюдения могут работать только в случае когда подключены к одной и той же локальной сети и находятся в одно и том же домене.
Предлагаемый вариант решения
Система поддержки распределенных систем «Базис» предназначена для построения распределенных систем обработки разнородных данных на базе Microsoft Windows. Использование предложенной в «Базис» модели взаимодействия компонентов значительно упрощает разработку и администрирование распределенных систем. Обеспечивается прозрачность взаимодействия компонент, обрабатывающих данные, расположенных как в локальной системе, так и на удаленном компьютере. «Базис» основан на модели компонентных объектов Microsoft[46, 48].
Основным строительным элементов «Базис» является прикладной объект. Прикладной объект реализует какую-либо функцию распределенной системы, в которой он функционирует. Он принимает данные из внешней информационной среды и/или передает сгенерированные в нем данные в эту информационную среду. В зависимости от назначения объекта он может принадлежать к одному из перечисленных классов: пустой объект, этот объект не принимает и не предоставляет ни каких данных, а выполняет какую-либо вспомогательную функцию, не относящуюся к обработке данных; объект-приемник, объект, который имеет один или более входов, но не имеет выходов; объект-генератор, не принимает ни каких данных из информационной среды, но имеет один или более выходов; комплексный объект объединяет в себе объект-приемник и генератор и имеет как входы, так и выходы. Назначение и функции системы определяются ее прикладными объектами и связями между ними.
Объекты объединяются в подсистемы. Один и тот же объект не может быть компонентом двух подсистем, если он не находится в дочерней подсистемы относи тельно другой но любой объект одной подсистемы может без помех взаимодействовать с любым объектом другой подсистемы, если они работают с данными одного типа[47].
На рисунке представлена схема взаимодействия объектов подсистемы видеонаблюдения. Объекты типа «Источник видео» получают с внешних устройств видео-потоки и передают их в информационную среду. Комплексный объект «Мультиплексор видеосигналов» преобразует эти потоки в один для удобства обработки. Затем полученный видео-поток направляется двум объектам приемникам для визуализации видео на мониторах операторов системы охраны и объекту «Детектор движения», который анализирует видео-поток и, в случае обнаружения движущихся объектов там где их быть не должно, выдает обработанный поток объекту визуализации на пульте охраны и передает звуковое сообщение объекту, ответственному за оповещение персонала.
Объекты и связи между ними, а так же подсистемы целиком могут появляться и исчезать останавливаться и начинать работу в процессе функционирования всех подсистем.
Схема, приведенная на рисунке 2.2, иллюстрирует отношения между объектами и базовым программным обеспечением «Базис».
Схема «Базис» Каждый объект подключается к так называемой шине объектов. Шина объектов ответственна за управление объектом и взаимодействие его с общей информационной средой. Шина объектов функционирует на каждом компьютере, включенном в «Базис» и существует на нем в единственном экземпляре. Пользуясь локальной базой данных, в которой хранится конфигурация «Базис» для локального компьютера, шина передает объектам управляющие сигналы, такие как запуск, останов и т.д. Шина передает в объект затребованные им потоки данных и передает всем заинтересованным объектам данные, сгенерированные объектами, принадлежащими этой шине. Шина берет на себя всю работу по доставке данных через сеть, шинам (компьютерам), на которых функционируют объекты, заинтересованные в сгенерированном значении. Так же шина ответственна за сбор информации о статусах объектов, подчиненных ей. Менеджер конфигураций это компонент «Базис» существующий в единственном экземпляре в рамках всей распределенной системы, этот компонент имеет полное представление о том, какие объекты существуют и функционируют на каждой из шин системы. Менеджер конфигураций выполняет сразу несколько функций; поддержание базы данных с информацией обо всех объектах системы, и их статусах; передача информации об изменении конфигурации системы всем шинам; передача управляющих сигналов шинам; останов и старт всей системы в целом; останов и старт отдельно взятой подсистемы; управление скоростью потоков данных.
Менеджер конфигурации в любой момент времени может предоставить информацию обо всей системе в целом[49]. Таким образом, для поддержания целостной и непротиворечивой картины все управляющие воздействия передаются сначала менеджеру конфигураций, затем этот компонент передает эту информацию шинам, заинтересованным в ней, а каждая из шин, если это необходимо, передает воздействие объектам.
Управление конфигурацией «Базис»
Вопрос хранения конфигурации и управления ей частично затрагивался в разделе, посвященном менеджеру конфигураций. Теперь рассмотрим его подробней. Для работы базой данных по конфигурации «Базис» существует ряд вспомогательных классов[59]: CValueListK — предназначен для работы со списком объектов-значений; CValueKeeper - работа с конфигурацией объекта-значения; CObjectListK - список прикладных объектов; GObjectKeeper - работа с конфигурацией прикладных объектов; CGroupKeeper - работа со списком адресов рассылки данных; CGroupListK — список адресов рассылки данных; CSignalTypesListK - список типов данных, зарегистрированных в системе; CSTKeeper— конфигурация типа сигнала; CUnitListK - список объектов-модулей; CUnitKeeper - конфигурация объекта-модуля; CUnitBusesListK - список шин, на которых может быть установлен прикладной объект, порождаемый от указанного объекта-модуля; RegistryKeeper - предназначен для работы со всей конфигурацией в целом.
Каждый из классов, предназначенный для работы с конфигурацией объекта системы «Базис» имеет одинаковый набор методов: метод для получения конфигурации объекта с заданным именем, установки значений полей конфигурации объекта, создания нового объекта, приведения конфигурации объекта к последовательному виду для хранения в файле и передачи по сети и метод для восстановления конфигурации из потока. Каждый класс может работать в режиме локальной шины или в режиме менеджера конфигурации. В случае работы в режиме менеджера конфигураций производится работа с информацией о конфигурации, хранящейся в поддереве СМ дерева «Базис». Активируется этот режим копированием в строку cm класса для работы с объектом строки, содержащей "\СМ". Все перечисленные классы являются обертками для функций обращения к системному реестру и преобразуют информацию, хранящуюся в реестре в структуру, хранящуюся в классе и наоборот. Класс RegistryKeeper имеет следующие методы; GetLocalPath - получить путь к директории, где «Базис» создает временные файлы; ExportBasisCfg - экспорт конфигурации всей системы в файл; ImportBasisCfg - импорт конфигурации из файла; ImportBasisCfgToCM - импорт конфигурации из файла в базу менеджера конфигурации; GetMylPAddress - получить IP-адрес локальной шины; AddPerfCounter - добавить счетчик производительности.
Как уже говорилось ранее, при изменении конфигурации какого-либо объекта или при установке нового объекта, об этом необходимо сообщить всем шинам «Базис». Эту работу выполняет менеджер конфигурации. Для этого, все изменения записываются в поток и передаются менеджеру конфигураций, который обновляет свою копию базы данных, и в свою очередь передает поток всем шинам системы.
Для приведения конфигурации к виду, пригодному к записи в поток, каждый класс работы с объектами реализует методы Serialize и UnSerialize. Класс RegistryKeeper, так же имеет методы для приведения к последовательному виду всей базы данных. Формат потока имеет специальный вид. В самом начале потока должна содержаться строка [Basys_configuration_file]. Эта строка говорит о том, что в потоке содержится информация о конфигурации «Базис». Заканчиваться поток должен строкой [Con-figuration_file_end]. Между этими тегами может содержать любое количество информации об изменениях в конфигурации. Эта информация помещается в тегах, указывающих к какому объекту данная информация относится. Возможны следующие теги: [Group] - информация о группе рассылки данных объекта-значения; [Object] - информация о конфигурации прикладного объекта; [Unit] - конфигурация объекта-модуля; [Value] - конфигурация объекта-значения; [SignalType] - информация о новом типе сигнала; [Input] - конфигурация входа объекта; [Output] - конфигурация выхода объекта. Количество тегов в потоке не регламентировано.
Следом за тегом [Group] должен следовать IP-адрес групповой рассылки и имя значения, соответствующего группе рассылке, или "-1" в том случае, если информацию о группе необходимо удалить.
После тега [Object] необходимо расположить следующую информацию: имя прикладного объекта, конфигурация которого изменяется; IP-адрес шины, на которой функционирует объект; тип объекта (1 - генератор, 2 - приемник, 3 - комплексный объект); информация о том разрешен объект, или нет (1 — разрешен, 0 - запрещен); имя объекта-модуля, от которого порождается объект. Далее, если объект является приемником, располагается тег описания его входов [Input], за этим тегом следует количество описанных в потоке входов и информация о входе в следующем виде:
Компонент видеоперехвата для нескольких потоков
Компонент считывания ключей системы «Лик» предназначен для снятия данных с восьми ПИН-считывателей, подключенных к коммутатору «Лик» и находится в модуле LikReader. Компонент является чистым генератором и имеет один выход, который поставляет в систему данные в виде совокупности {идентификатор источника, ключевые данные}. Так как, считывание происходит на восьми каналах, компонент позволяет каждому из восьми считывателей, подключенных к коммутатору назначить идентификатор источника. Схематичное изображение этого компонента показано на рисунке 3.17. UkReader SourceKey
Схема компонента считывания ключей для системы «Лик» При первой инициализации компонента все каналы помечены как неопределенные и входные данные не обрабатываются. При вводе с ПИН-считывателя пароля, компонент гасит световой диод на соответствующем считывателе, что свиде-тельствует о том, что введенный код принят и находится в процессе обработки.
Данный компонент находится в модуле LikLock и предназначен для управления сигнальными светодиодами и замками, подключенными к коммутатору «Лик». Коммутатор позволяет подключить восемь исполнительных устройств, на каждом из которых присутствуют звуковой сигнализатор и два свето диода: зеленый для ин дикации того, что дверь открыта и красный для индикации готовности к работе.
На вход компонента поступают сигналы, содержащие идентификатор источника, с которым ассоциировано исполнительное устройство, подключенное к коммутатору, идентификатор пользователя, ассоциированного с текущим действием и идентификатор действия. Схематичное изображение компонента показано на рисунке 3.18.
Схема компонента управления исполнительными устройствами «Лик» Для каждого из исполнительных устройств в компоненте создается поток, который управляет индикацией и сигнализацией. При поступлении на вход сигнала о закрытии двери, поток соответствующего исполнительного устройства последовательно инициирует три звуковых сигнала и мерцания красного свето диода на устройстве, а затем блокирует дверь и зажигает красный свето диод для индикации готовности устройства к работе.
1 Компонент контроллера источника служит для того, чтобы проверять правильность введенного пользователем пароля, проверки доступа пользователя к помещению, куда запрашивается доступ, а так же проверки времени, в которое пользователь может проходить в данное помещение.
AccessControi Рис. 3.19 - Схема компонента контроля доступа По входным данным, содержащим введенный ключ и источник, компонент находит запрещающее правило на проход через данный источник в данное время. Если такового не имеется и имеется разрешающее правило с теми же параметрами, то на выходе компонента генерируется пакет, содержащий идентификатор источника, идентификатор пользователя и ассоциированное событие: пропустить, запретить вход в связи с недостатком полномочий. Данный компонент не имеет ни окна представления ни конфигурирования, вся манипуляции по настройке данного компонента происходят в программе DataAdmin, описанной выше.
