Вахтель_VKR (1229959), страница 3
Текст из файла (страница 3)
– установить режим <вход под принуждением> (незаметно для окружающих охране подается сигнал тревоги);
– охраннику дается право на самостоятельное принятие решения о разрешении на проход посетителя (при считывании карты на монитор охранника выводится фотография владельца, которая сличается с изображением, выдаваемым видеокамерой);
– установить режим счетчика на использование карты (количество чтений карты на конкретном считывателе ограничивается);
– установить скрытый контроль в помещении (подать сигнал тревоги на пульт охраны при проникновении в защищаемое помещение и отсутствии соответствующих прав, причем для злоумышленника факт обнаружения остается неведомым).
2.4 СКУД на ООО «Саммит Моторс (Хабаровск)»
Здесь мы рассмотрим систему контроля и управления доступом. Данная СКУД относится к группе систем по способу управления.
Универсальная – включающая функции как автономной, так и сетевой системы, работающая в сетевом режиме под управлением центрального устройства управления и переходящая в автономный режим при возникновении отказов в сетевом оборудовании, в центральном устройстве или обрыве связи системы.
Данная сетевая система контроля применяется, поскольку требуется постоянный контроль состояния помещения, возможность оперативного вмешательства в работу системы и получение различных статистических данных о движении персонала [2].
Управление доступом системе в основном осуществляется автоматически, на основе объектных и временных ограничений доступа, задаваемых как для отдельных владельцев ключей, так и для групп владельцев, выделенных по какому-либо признаку с помощью специальной программы. Оператор имеет возможность работать с базами данных пользователей, регистрировать и редактировать права доступа. При запущенной программе все события, происходящие в системе, выводятся на монитор в режиме реального времени и протоколируются для последующего получения отчетов по каждому пользователю. Система позволяет получить полный набор стандартных отчетов о перемещениях сотрудников, а также вести учет рабочего времени. Сети связи в системе защищены от злоумышленников аппаратно и программно. Данная система оптимальна для применения в небольших и средних офисах или предприятиях (до 256 контролируемых точек прохода).
Плюсом данной системы является в том, что идет трансляция на монитор в режиме реального времени и оператор имеет возможность корректировать права доступа, чего нет, к примеру, в автономных СКУД.
В настоящее время на СМХ используется понимание «системы контроля доступа» как средства организации контрольно-пропускного режима. В качестве пользователей понимаются сотрудники предприятия, и наибольшее внимание уделяется непосредственному обеспечению безопасного доступа в зоны и помещения. Такое использование СКУД, способствует уменьшению расходов предприятия на организацию безопасности.
2.5 Особенности контроля доступа, как системы реального времени
В силу своей специфики, система контроля доступа является системой реального времени (СРВ). СРВ, как аппаратно-программный комплекс, включает в себя датчики, регистрирующие события на предприятии, модули ввода-вывода, преобразующие показания датчиков в цифровой вид, пригодный для обработки этих показаний на компьютере, и, наконец, компьютер с программой, реагирующей на события, происходящие на объекте [3].
В настоящее время СРВ ориентирована на обработку внешних событий. Ее основная задача – реагировать в предсказуемые времена, на непредсказуемый поток внешних событий. Это означает, что система должна отреагировать на событие, произошедшее на предприятии, своевременно, то есть в течение времени, критического для этого события. Величина критического времени для каждого события определяется предприятием и самим событием, и, естественно, может быть разной и время реакции системы предсказано (вычислено) при создании системы. Отсутствие реакции в предсказанное время считается ошибкой для системы реального времени на СМХ [3].
Кроме этого, эта система успевает реагировать на одновременно происходящие события. Даже если два или большее число внешних событий происходят одновременно, система успевает среагировать на каждое из них в течение временных интервалов, критических для этих событий.
Данная СКУД относится к СРВ« мягкого реального времени», в свою очередь она допускает некоторые задержки времени реакции системы, в отличие от СВР «жесткого времени», которые не допускают этого. Система мягкого реального времени СМХ характеризуются тем, что задержка реакции допустима, хотя и может привести к увеличению стоимости результатов и снижению производительности системы в целом.
3 Моделирование СКУД
3.1 Подходы и инструментарий
Основной целью данной выпускной работы является написание эффективного приложения. Эффективного во всех смыслах: надежного, удобного, расширяемого. Поэтому, стояла цель выбрать удобный и понятный используемый подход, чтобы меньше совершить ошибок и меньше затратить времени на написание программы.
Был выбран объектно-ориентированный подход, позволяющий абстрагироваться от алгоритма, как последовательности указаний. Объектно-ориентированный подход представил абстрактные сущности программы в виде взаимодействующих между собой объектов. Такой подход более близок и понятен человеку, поскольку он наиболее удобно отражает окружающий реальный мир. Объектное мышление позволяет представлять и понимать все более сложные системы [4].
В погоне за дальнейшей эффективностью и снижением времени разработки программной системы, одного существования такого подхода и соответствующих объектно-ориентированных языков программирования оказалось мало. Требовались специальные средства, помогающие продумать, промоделировать систему, избежать фатальных ошибок. Требовались средства, позволяющие визуально изобразить объекты, их взаимодействия, методики, позволяющие последовательно найти и изучить взаимодействующие объекты, продумать процесс разработки, адаптировать к изменяющимся потребностям [5].
Модели позволили наглядно продемонстрировать структуру и поведение системы. Модели визуализировали и позволили управлять архитектурой системы, минимизировать риск и позволили добиться лучшего понимания системы.
Необходимость универсализации подхода к построению модели привела к использованию универсального языка моделирования (UML = Unified Modeling Language). Использовались CASE-средства, которые позволили визуализировать этот процесс, объединить модели с документацией.[6]
Одним из наиболее известных средств этого типа является Rational Rose компании Rational. Созданное авторами UML это CASE - средство наиболее полно поддерживает нотации языка и его диаграммы. Оно позволяет организовать генерацию заголовков классов и некоторых простейших функций на основе созданных моделей, что позволяет вносить даже существенные изменения в существующую структуру системы [5].
3.2 Структура СКУД СМХ
Система СКУД способна автоматизировать множество процессов, связанных с организацией доступа к ПНД. Сюда входят регистрация (пользователей и персонала) и (распределение ролей/прав доступа между пользователями) СКУД, непосредственное предоставление доступа к ПНД, организация контроля работы персонала, сбор и предоставление статистики о функционировании системы и многое другое [6].
Данная СКУД, ориентирована на обслуживание большого числа клиентов и имеет модульную структуру, позволяющую организовать рабочие места для различных служб, обеспечивающих эффективное функционирование системы. Модульная схема на предприятии обеспечивается за счет использования архитектуры клиент-сервер. Набор модулей на СМХ:
– «бюро пропусков»- рабочее место менеджера по работе с клиентами. Эта служба занимается регистрацией новых клиентов, выдачей электронных карт, назначением прав доступа группам и отдельным пользователям.
– «АРМ оператора» - рабочее место оператора (охранника). Оператор отвечает за корректное функционирование системы в течение своей смены. Он контролирует работу системы, реагирует на внештатные ситуации.
– «АРМ администратора». Администратор осуществляет настройку системы, прием карт-идентификаторов, регистрацию персонала.
– «Генератор отчетов». Используется для построения различных отчетов о работе системы.
3.3 Описание предметной области
Модель предметной области СМХ представлена на рисунке 2.
Группа представляет собой объединение сотрудников предприятия. Каждый человек в системе обязательно приписан какой-либо группе. Доступ пользователей к своим учетным записям осуществляется по паролю. Когда новый пользователь регистрируется, для него создается группа, и он считается ее администратором. Администратор имеет следующие полномочия:
– Добавлять в группу новых членов,
– Настраивать права и расписания доступа членов группы,
– Устанавливать ассоциации для своей группы.
Для того, чтобы сотрудник мог воспользоваться системой, ему выдается карта. На каждую учетную запись может быть выдано не более одной карты. Несколько учетных записей не могут использовать одну карту.
Для того чтобы построить иерархию групп, между ними можно устанавливать связи. Группа обязательно содержит хотя бы одного члена (ее администратора) [7].
Рисунок 2 – Модель предметной области СМХ
4 Архитектурные механизмы
Трактовка СКУД как системы реального времени на СМХ строилась на реализации механизмов диспетчеризации, межобъектного взаимодействия и средств работы с таймерами. Параллелизм в обработке одновременно происходящих внешних событий обеспечивался за счет использования многопоточности. Клиент-серверный подход внес необходимость реализации механизма и способов взаимодействия между сервером и приложениями, а общие требования безопасности и надежности заставили выбрать особые способы хранения данных и работы с ними [7].
4.1 Организация взаимодействия объектов
В настоящее время на предприятии для организации взаимодействия объектов используется Диспетчер сообщений, с целью реализации механизма межобъектного взаимодействия. Диспетчер «знает» все объекты, которые желают обмениваться сообщениями, а эти объекты в свою очередь «знают» о существовании диспетчера. Помимо таблицы зарегистрированных объектов, важной частью диспетчера является очередь сообщений. Принцип отправки сообщения можно описать следующим образом (рисунок 3).
– Объект-отправитель создает сообщение и инициализирует его данными. Затем он вызывает функцию отправки сообщения (SendEvent) диспетчера.
– Диспетчер осуществляет постановку сообщения в очередь, проверяет, запущен ли поток обработки очереди сообщений. После этого управление возвращается объекту отправителю.
– Поток обработки сообщений извлекает следующее сообщение из очереди, ищет объект-получатель по таблице зарегистрированных объектов и вызывает функцию обработки сообщения получателя (ProcEvent), передавая ей в качестве параметра сообщение. Когда управление возвращается диспетчеру, поток осуществляет проверку наличия сообщений в очереди.
– Поток обработки сообщений извлекает следующее сообщение из очереди, ищет объект-получатель по таблице зарегистрированных объектов и вызывает функцию обработки сообщения получателя (ProcEvent), передавая ей в качестве параметра сообщение. Когда управление возвращается диспетчеру, поток осуществляет проверку наличия сообщений в очереди. Если сообщения отсутствуют, то поток завершается, в противном случае поток осуществляет обработку сообщения.
Перед вызовом функции ProcEvent получателя осуществляется запуск таймера. Если к моменту таймаута управление не возвращено объекту диспетчера, то поток прерывается и запускается снова со следующего элемента очереди сообщений. Если же получатель знает, что время обработки сообщения превышает время таймаута, то он запускает свой поток и возвращает управление диспетчеру системы.
Очередь сообщений диспетчера представляет собой массив элементов сообщений. Сообщения в очередь укладываются последовательно. При достижении конца очереди следующее сообщение записывается на первое место, таким образом, очередь зациклена. Обработка очереди потоком прекращается, когда номер следующего обрабатываемого элемента равен номеру следующего добавляемого элемента, что означает, что в очереди отсутствуют сообщения.
Выделение объекта диспетчера с его очередью сообщений разрешает все проблемы синхронизации многопоточного взаимодействия, при условии, что взаимодействие объектов осуществляется только через очередь обработки сообщений диспетчера системы [8].
Каждый взаимодействующий объект (пользователь) в данной системе характеризуется тремя значениями: номером класса, номером объекта и дополнительным кодом. Для уникальной идентификации объекта используются первые два значения. Номера объектов выдаются диспетчером последовательно, с заполнением пустот (т.е. объект занимает первый свободный номер). Дополнительный код призван выражать пользовательскую нумерацию объектов. Кроме того, он может быть использован для поиска объектов в системе.
Трудоемкость поиска элемента по таблице взаимодействующих объектов является логарифмической от числа объектов, принадлежащих классу искомого. Объясняется тем, что диспетчер работает с классами, как элементами массива фиксированной длины, а с объектами класса как с массивом. Поиск по списку объектов осуществляется дихотомически.
Тем самым диспетчер способен поддерживать неограниченное количество объектов. Единственным «узким» местом может выступить очередь сообщений: поскольку она зациклена, то ее переполнение может закончиться потерей ряда начальных сообщений.
Диспетчер событий. Для реализации возможности подписки одних объектов (пользователей) на события других диспетчер сообщений был расширен функциями диспетчера событий. Это выразилось в добавлении таблицы подписчиков и функций работы с событиями. Объект, желающий заявить о событии, создает объект-сообщение и заполняет часть его полей, касающихся события. После этого осуществляется вызов функции уведомления о событии (ThrowEvent). Эта функция находит всех подписчиков, и отправляет им сообщения о событии, удаляя их подписные записи из таблицы. Если объект желает получить событие снова, он должен опять на него подписаться [9].
Объекты имеют возможность подписываться на события монопольно (для этого в объекте сообщения предусмотрен соответствующий атрибут). При возникновении события диспетчер определяет наличие монопольных подписок, и рассылает сообщения, уведомляя подписчиков, была ли заявлена монопольная подписка и является ли он монопольным подписчиком. В зависимости от этого объект принимает решение о соответствующей реакции на событие.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
