Разработка системы контроля и управления доступом к охраняемым объектам

Класс «AbstractForm» содержит все обобщенные методы всех классов форм, такие как добавление, удаление, замена, которые открывают пользователю компоненты полей для ввода данных. Каждая из форм занимается отображением данных на экран, а так же их добавлением, удалением и заменой.

Так же на схеме присутствует вспомогательный класс. «SpringContextHelper»-этот класс обеспечивает получение данных из репозиториев к контроллерам. Вместо DAO классов используется PagingAndSortingRepository - это интерфейс библиотеки spring-data, который входит в состав фреймворка «Spring». Используя данную библиотеку, не требуется создавать абстрактную фабрику DAO и наследовать всеми DAO классами обобщенные методы. Но для нормальной передачи информации из базы данных, через репозитории, к контроллеру, необходмо создать SpringContextHelper. Внутри этого класса необходимо создать конструктор внутри которого передать переменную которая определяет набор методов, которые сервлет использует для связи с его контейнером сервлетов. В противном случае данные не выводиться не будут.

В классе «Components» описана разметка, которая будет применена к главной странице, там же инициализируются все компоненты интерфейса главной страницы.

2.4 Разработка аппаратной подсистемы

В качестве аппаратной подсистемы выступают устройства КУД. К ним относятся: считыватель (RFID -считыватель), управляющий элемент (контроллер). Также необходимо выбрать наиболее походящий интерфейс передачи данных между УС и контроллером. Совокупное взаимодействие этих аппаратных средств собственно и обеспечивает контроль и управление доступом.

Разработка структурной схемы устройства контроля и управления доступом (КУД)

Характерными особенностями проектируемого устройства КУД являются:

- наличие модуля NAND FLASH, с которого будет производиться загрузка операционной системы;

- наличие модуля SD/MMC для подключения карт памяти;

- использование ИБП для обеспечения постоянного питания устройств КУД, а также для автоматического обеспечения питания подключенных к ИБП устройств от встроенного аккумулятора в случае сбоев в электроснабжении;

- использование Ethernet-контроллера, для обеспечения связи сервера с проектируемым устройством.

Основными элементами структуры устройства КУД для аутентификации пользователей являются:

- считыватель RFID;

- микроконтроллер;

- Ethernet-контроллер;

- модуль DDR3;

- модуль NAND FLASH;

- модуль SD/MMC.

Ethernet-контроллер состоит из двух блоков. Блок Ethernet MAC отвечает за прием и формирование пакетов Ethernet. Блок PHY отвечает за формирование сигналов на линиях физического уровня интерфейса Ethernet. Блок PHY соединятся с блоком Ethernet MAC через интерфейс IEEE 802.3 MII (Media Independed Interface).

Для увеличения производительности контроллера к блоку MAC подключен буфер пакетов размеров 8 Кбайт. Увеличение производительности достигается за счет того, что внутренняя шина данных 32 разрядная, а внешний интерфейс для связи с микроконтроллером может быть как 32 разрядным, так и 8 или 16 разрядным. Опционально, к контроллеру Ethernet может подключаться энергонезависимая память для хранения различных настроек, таких например, как MAC адрес контроллера. К блоку PHY подключается внешний приемопередатчик для обеспечения подключения к шине Ethernet.

Выбор управляющего элемента

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

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

Основные критерии выбора микроконтроллера в порядке значимости:

­ пригодность для прикладной системы;

­ доступность;

­ поддержка разработчика;

­ информационная поддержка;

­ надежность фирмы производителя.

В качестве управляющего элемента был выбран микроконтроллер из семейства Integra ARMCortex-A8-- SK-iMX53, который полностью удовлетворяет всем вышеупомянутым критериям.

Микроконтроллер SK-iMX53 содержит процессор ARMCortex-A8.

Основные характеристики:

Основа платы - высокопроизводительный процессор фирмы FreeScale iMX536 (ARM Cortex-A8 до 1ГГц), имеет широчайший набор периферии и высокоскоростных интерфейсов (SATA, HS USB, Ethernet, LVDS...), встроенные сопроцессоры 3D (с поддержкой OpenGL ES 1.1 и OpenGL ES 2.0) и 2D графики, модуль кодирования-декодирования видео (декодирование 1080p - Full HD, кодирование 720p), модуль арифметики с плавающей точкой.

Подключенная периферия:

­ 256МБайт SLC NAND flash

­ Ethernet 10/100M

­ SATA HDD разъем

­ I2S TLV320 аудио CODEC

­ SPDIF выход

­ RS232 приемопередатчик

­ CAN

­ 2 x USB host (USB-A), питание одного из разъемов приведено через джампер, что позволяет использовать его как Device

­ 512MБайт (128Mx32) DDR3-800. Внимание!!! предыдущий вариант платы (V2) содержал 256МБайт DDR2-800

­ 2 x LCD LVDS, возможность подключения SK-ATM0700D4-Plug или SK-TFT1024x768TP-Plug c двумя раздельными системными Framebuffer.

­ 74 линии I/O, два разъема, один из которых подразумевает прямое подключение SK-HDMI-Plug (или аналогичной платы расширения), SK-VideoADC-Plug

Загрузка

- Штатная загрузка осуществляется с NAND flash

- Загрузка по USB

Выбор считывающего устройства

В разрабатываемой системе будем использовать Matrix III RD-ALL.

Применение:

Предназначен для работы с сетевыми и автономными системами безопасности контроля и доступа, а также платёжными и системами лояльности. Выход RS-232 и RS485 позволяет подключить считыватель к PC как непосредственно, так и на большом расстоянии до 1200 метров через конвертер USB 422(485). Для изделия отдельно поставляется комплект разработчика SDK-RDAll, позволяющий быстро освоить работу с изделием.

Основные характеристики:

- Одновременная работа в двух диапазонах 13,56MHz&125КHz

- Выбор коммуникационных интерфейсов

- Влага-и пыле защищенный корпус

- Привлекательная цена

- Гарантия: 18 месяцев с даты продажи, не более 24 месяцев от даты производства.

Технические характеристики:

- Рабочая частота: 13,56MHz & 125КHz одновременно

- Работа с картами: Mifare-UL (чтение и запись)

- Работа с картами&брелками: EM Marine,HID ProxCard II, Mifare

- Дальность чтения: 4-10 cm

- Напряжение питания: 8 - 18 В постоянного тока

- Потребление тока: 135mA(max)

- Звуковая/световая индикация: сигнал зумера, двухцветный светодиод

- Рабочая температура: -30°С +40°С

- Материал корпуса: ABS пластик

- Выходной интерфейс: RS-232, RS485, Wiegand 26, Dallas Touch Memory

- Размер(mm): 115х75х22

Так же будет использована еще одна модель RFID считыватель Z2-Usb.

Надежный настольный мультиформатный считыватель. Выход и питание USB. Одновременная работа с картами стандарта EM Marine 125Khz и Mifare 13.56Mhz. Все это позволит успешно применять считыватель Z-2 для дисконтных и платежных ситем, пункты проката, СКУД, идентификации, персонализации и других проектов использующих RFID технологии. Для изделия отдельно поставляется комплект разработчика SDK-Z2USB и бесплатная программа PlaceCard для автоматизации ввода номеров RFID карт в формы программ СКУД.Это позволяет быстро освоить работу с изделием.

Основные характеристики:

- Одновременная работа в двух диапазонах 13,56MHz & 125kHz
Питание и выход USB

- Технические характеристики:

- Рабочая частота: 13,56MHz&125КHz одновременно

- Чтение карт & брелков стандарта: EM Marine, HID, ProxCard II, Mifare (только чтение)

- Дальность чтения: 4-8 cm

- Питание: USB

- Звуковая/световая индикация: сигнал зуммера, двухцветный светодиод

- Рабочая температура: 0°С до +50°С

- Материал корпуса: ABS пластик

- Цвет корпуса: матовый чёрный

- Выходной интерфейс: USB

- Размер(mm): 110х80х24

Исполнительные устройства (УИ)

Согласно ГОСТ 51241-2008, устройства исполнительные (УИ) - это устройства или механизмы, обеспечивающие приведение в открытое или закрытое состояние УПУ (электромеханические, электромагнитные замки, электромагнитные защелки, механизмы привода шлюзов, ворот, турникетов и другие подобные устройства).

Для обеспечения блокирования двери при отсутствии проходов через нее и возможности автоматического ее отпирания при разрешении прохода применяются электрические управляемые замки и защелки, которые делятся на две основные категории:

- электромеханические;

- электромагнитные.

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

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

Врезной электромеханический замок модели EL480 финской компании ABLOY относится к группе замков соленоидного типа и предназначен для установки на узкие профильные двери. В отличие от других замков Abloy, этот электромеханический замок имеет независимые внешнюю и внутреннюю ручки, может работать в режимах «нормально открыт» и «нормально закрыт», имеет световую индикацию состояния и устанавливается как на «правые», так и на «левые» двери. При работе под управлением контроллера СКУД или «кнопки выхода» электромеханический замок блокирует / разблокирует только внешнюю ручку, а замок всегда можно открыть либо ключом, либо внутренней ручкой.

Специалисты ABLOY рекомендуют использовать электромеханический замок EL480 в качестве исполнительного устройства системы контроля и управления доступом (СКУД) для внутренних профильных дверей офисов, торговых помещений, общественных или административных зданий, складов, служебных помещений банков и др. Замок EL480 можно устанавливать на двери запасных выходов и на противопожарные двери. При необходимости электромеханический замок можно в любой момент открыть ключом или внутренней ручкой.

При работе EL480 под управлением СКУД, контроллер СКУД осуществляет блокировку или разблокировку внешней ручки электромеханического замка путем отключения или подачи напряжения питания на замок. В дежурном режиме электромеханический замок находится в запертом состоянии («нормально закрыт»), его внешняя ручка заблокирована и напряжение на замок не подается. Если на контроллер СКУД со считывателя поступает код владельца карты доступа, которому разрешен проход через дверь с EL480, контроллер подает на электромеханический замок напряжение, внешняя ручка замка разблокируется и дверь можно открыть извне. При этом внутренней ручкой электромеханический замок можно открыть всегда.

В зависимости от конфигурации СКУД электромеханический замок может управляться не только контроллером, но и считывателем, таймером, кнопкой выхода и другими устройствами. Схема подключения замка EL480 к устройствам СКУД представлена на рисунке 2.26.

В отличие от других замков ABLOY соленоидного типа, электромеханический замок EL480 имеет раздельные шпиндели оригинальной конструкции, благодаря чему ручки замка независимы друг от друга. Кроме того, EL480 универсален: его можно настроить для работы как на «правых», так и на «левых» дверях, перевести в режим «нормально открыт» или «нормально закрыт», поменяв направление соленоида, а также использовать источник постоянного тока напряжением 12 или 24 вольта.

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

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

Если во внутренних помещениях офиса, магазина, склада и других объектов двери должны быть разблокированы на открытие извне в дневное время и заблокированы в ночное, специалисты ABLOY рекомендуют использовать электромеханические замки EL480, настроенные на работу в режиме «нормально открыт». В этом случае, в дневное время суток напряжение питания на электромеханические замки не подается и внешние ручки замков не заблокированы. Чтобы электромеханический замок каждой двери перевести в запертое состояние, например, одновременно в 19-00, контроллер СКУД автоматически подает напряжение питания на все замки и блокирует их внешние ручки. Отпереть двери можно либо внутренней ручкой или ключем. После открытия и закрытия двери электромеханический замок снова заблокирует внешнюю ручку.

Как и другие замки Abloy, электромеханический замок EL480 сертифицирован по высшему классу устойчивости к взлому и имеет высокую износоустойчивость. Такие высокие эксплуатационные характеристики этих замков обусловлены особенностями их конструкции и применением запатентованных цилиндров Abloy. В зависимости от важности охраняемого объекта, в электромеханический замок этой модели можно установить цилиндры скандинавского овального или финского типа серий ASSA, Abloy Classic, Trio Ving, RUKO, Abloy Pro, а также цилиндры новой серии Protec, обладающие самой высокой надежностью в мире. Кроме того, от сверления и распиливания электромеханический замок предохраняют стальные шайбы и специальные пластины. Все детали замка EL480 выполнены из антикоррозионных сплавов, а ригель изготовлен из высококачественной стали.

Поскольку EL480 предназначен для установки в профильные двери, то электромеханический замок имеет очень малое расстояние от края двери до середины цилиндра (29 или 35 мм), узкую переднюю планку в 22 мм, а также скандинавский стандарт врезки. В корпус электромеханического замка встроен микропереключатель для установки положения ригеля, который выдвигается на длину до 14 мм. В комплект поставки EL480 входят переходные пластины, контактные муфты, крепежные винты, схема сверления и подключения, а также инструкция по монтажу замка на дверь.

Технические характеристики на электромеханический замок Abloy 480 представлены в таблице 2.2.

Таблица 2.2 - Технические характеристики замка EL480

Параметры	Значения
Индикация:	- положения ригеля - положения ручки (нажата - не нажата)
Рабочее напряжение:	12 или 24 В постоянного тока (-10% - +15%)
Рабочий ток:	- максимальный 0,35 А - ток покоя 0,12 А (12 В) или 0,07 А (24 В)
Диапазон температур:	-20°С…+60°С
Выход ригеля:	14 мм
Шпиндель замка:	8 мм
Обработка планки:	Хромирование
Комплект поставки EL480:	электромеханический замок, контактные муфты, крепежные винты, инструкция установке и монтажу, схема подключения замка

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

- контроллер не будет регистрировать взломы двери;

- открытый контролером замок будет запираться только по таймеру, а не сразу при закрытии двери;

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

Как правило, в качестве датчика открытия двери используется геркон (герметичный контакт, управляемый магнитом).

Работа датчика открытия двери основана на замыкании магнитных контактов геркона (контактное устройство) при приближении постоянного магнита (задающее устройство).

Разработка протокола передачи данных

СКУД может использовать следующие протоколы - это UDP, TCP/IP и HTTP.

UDP - самый быстрый и ненакладный протокол. Позволяет обмениваться пакетами размером не более одного Ethernet-кадра (примерно 1500 байт). Но в СКУД контроллер редко обменивается с ПК пакетами размером более 100 байт. Таким образом, за счет скорости и простоты UDP - первый кандидат на использование в системе реального времени. Недостаток UDP - отсутствие гарантированной доставки сообщений - легко обходится теми же методами, что и при работе с RS-485: квитированием, т.е. передачей подтверждения приема каждого пакета.

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

HTTP - это самый медленный из протоколов, он «надстроен» над TCP/IP и используется в качестве основного в WEB, т.е. именно с его помощью мы получаем информацию из Internet. Из этого следует, что он проходим практически в мировом масштабе, в чем его определенное преимущество. Но в системах реального времени его применение практически невозможно из-за медлительности.

Из краткого обзора очевидно, что для систем реального времени, какими являются системы управления доступом, предпочтительнее использовать протокол UDP.

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

- установление транспортного соединения;

- передача данных;

- разрыв транспортного соединения.

Функции, выполняемые транспортным уровнем:

- преобразование транспортного адреса в сетевой;

- межоконечное мультиплексирование транспортных соединений в сетевые;

- установление и разрыв транспортных соединений;

- межоконечное упорядочивание блоков данных по отдельным соединениям;

- межоконечное обнаружение ошибок и необходимый контроль за качеством услуг;

- межоконечное восстановление после ошибок;

- межоконечное сегментирование, объединение и сцепление;

- межоконечное управление потоком данных по отдельным соединениям;

- передача срочных транспортных блоков данных.

Протокол UDP, являясь дейтаграммным протоколом, реализует сервис по возможности, то есть не гарантирует доставку своих сообщений, а, следовательно, никоим образом не компенсирует ненадежность дейтаграммного протокола IP.

Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). Каждая дейтаграмма переносит отдельное пользовательское сообщение. Это приводит к естественному ограничению: длина дейтаграммы UDP не может превышать длины поля данных протокола IP, которое, в свою очередь, ограничено размером кадра технологии нижнего уровня. Поэтому если UDP-буфер переполняется, то данные приложения отбрасываются. Заголовок UDP-пакета, состоящий из четырех 2-байтовых полей, содержит поля порт источника, порт получателя, длина UDP и контрольная сумма.

Поля “Порт источника” и порт получателя идентифицируют передающий и получающий процессы.

Поле “Длина UDP” содержит длину пакета UDP в байтах.

Поле “Контрольная сумма” содержит контрольную сумму пакета UDP, вычисляемую по всему пакету UDP с добавленным псевдозаголовком.

В поле “Данные” передается следующая информация: код сотрудника, который получил доступ к охраняемому объекту, а также дата и время прохода через УПУ.

Поле “Протокол” (длина 8 бит) идентифицирует протокол из заголовка пакета IP. Для UDP это значение равно 17. Одной из областей, где UDP применяется особенно широко, является область клиент-серверных приложений.

Недостаток UDP - отсутствие гарантированной доставки сообщений решается при помощи квитирования, т.е. передачи подтверждения приема каждого пакета.

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

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

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

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

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

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

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

RS-232 - интерфейс передачи информации между двумя устройствами на расстоянии до 20 м. Информация передается по проводам с уровнями сигналов, отличающимися от стандартных 5В, для обеспечения большей устойчивости к помехам. Асинхронная передача данных осуществляется с установленной скоростью при синхронизации уровнем сигнала стартового импульса.

Широко используемый последовательный интерфейс синхронной и асинхронной передачи данных, определяемый стандартом EIA RS-232-C и рекомендациями V.24 CCITT. Изначально создавался для связи компьютера с терминалом. В настоящее время используется в самых различных применениях.

Интерфейс RS-232-C соединяет два устройства. Линия передачи первого устройства соединяется с линией приема второго и наоборот (полный дуплекс) Для управления соединенными устройствами используется программное подтверждение (введение в поток передаваемых данных соответствующих управляющих символов). Возможна организация аппаратного подтверждения путем организации дополнительных RS-232 линий для обеспечения функций определения статуса и управления.

Таблица 2.3 - Каналы передачи данных RS-232

Наименование	Направление	Описание	Контакт (25-контактный разъем)	Контакт (9-контактный разъем)
DCD	IN	Carrie Detect (Определение несущей)	8	1
RXD	IN	Receive Data (Принимаемые данные)	3	2
TXD	OUT	Transmit Data (Передаваемые данные)	2	3
DTR	OUT	Data Terminal Ready (Готовность терминала)	20	4
GND	-	System Ground (Корпус системы)	7	5
DSR	IN	Data Set Ready (Готовность данных)	6	6
RTS	OUT	Request to Send (Запрос на отправку)	4	7
CTS	IN	Clear to Send (Готовность приема)	5	8
RI	IN	Ring Indicator (Индикатор)	22	9

Интерфейс RS-232C предназначен для подключения к компьютеру стандартных внешних устройств (принтера, сканера, модема, мыши и др.), а также для связи устройств между собой. Основными преимуществами использования RS-232C по сравнению с Centronics являются возможность передачи на значительно большие расстояния и гораздо более простой соединительный кабель. В то же время работать с ним несколько сложнее. Данные в RS-232C передаются в последовательном коде побайтно. Каждый байт обрамляется стартовым и стоповыми битами. Данные могут передаваться как в одну, так и в другую сторону (дуплексный режим).

Различают 25-контактный (DB25P) или 9-контактный (DB9P) разъем для подключения RS-232C. Назначение контактов разъема приведено в таблице.

Назначение сигналов следующее:

- FG - защитное заземление (экран).

- TxD - данные, передаваемые компьютером в последовательном коде (логика отрицательная).

- RxD - данные, принимаемые компьютером в последовательном коде (логика отрицательная).

- RTS - сигнал запроса передачи. Активен во все время передачи.

- CTS - сигнал сброса (очистки) для передачи. Активен во все время передачи. Говорит о готовности приемника.

- DSR - готовность данных. Используется для задания режима модема.

- SG - сигнальное заземление, нулевой провод.

- DCD - обнаружение несущей данных (детектирование принимаемого сигнала).

- DTR - готовность выходных данных.

- RI - индикатор вызова. Говорит о приеме модемом сигнала вызова по телефонной сети.

Наиболее часто используются трех- или четырехпроводная связь (для двунапрвленной передачи).

Для двухпроводной линии связи в случае только передачи из компьютера во внешнее устройство используются сигналы SG и TxD. Все 10 сигналов интерфейса задействуются только при соединении компьютера с модемом.

Формат передаваемых данных показан на рисунке 2.34. Собственно данные (5, 6, 7 или 8 бит) соопровождаются стартовым битом, битом четности и одним или двумя стоповыми битами. Получив стартовый бит, приемник выбирает из линии биты данных через определннные интервалы времени. Очень важно, чтобы тактовые частоты приемника и передатчика были одинаковыми, допустимое расхождение - не более 10%). Скорость передачи по RS-232C может выбираться из ряда: 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 бит/с.

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

Для подключения произвольного УС к компьютеру через RS-232C обычно используют трех- или четырехпроводную линию связи (см. рис. 1.1), но можно задействовать и другие сигналы интерфейса.

Обмен по RS-232C осуществляется с помощью обращений по специально выделенным для этого портам COM1 (адреса 3F8h...3FFh, прерывание IRQ4), COM2 (адреса 2F8h...2FFh, прерывание IRQ3), COM3 (адреса 3F8h...3EFh, прерывание IRQ10), COM4 (адреса 2E8h...2EFh, прерывание IRQ11). Форматы обращений по этим адресам можно найти в многочисленных описаниях микросхем контроллеров последовательного обмена UART (Universal Asynchronous Receiver/Transmitter), например, i8250, КР580ВВ51.

Шина USB (Universal Serial Bus - универсальная последовательная шина) появилась по компьютерным меркам довольно давно - версия первого утвержденного варианта стандарта появилась 15 января 1996 года. Разработка стандарта была инициировна весьма авторитетными фирмами - Intel, DEC, IBM, NEC, Northen Telecom и Compaq.

Основная цель стандарта, поставленная перед его разработчиками - создать реальную возможность пользователям работать в режиме Plug&Play с периферийными устройствами. Это означает, что должно быть предусмотрено подключение устройства к работающему компьютеру, автоматическое распознавание его немедленно после подключения и последующей установки соответствующих драйверов. Кроме этого, желательно питание маломощных устройств подавать с самой шины. Скорость шины должна быть достаточной для подавляющего большинства периферийных устройств. Попутно решается историческая проблема нехватки ресурсов на внутренних шинах IBM PC совместимого компьютера - контроллер USB занимает только одно прерывание независимо от количества подключенных к шине устройств.

Возможности USB следуют из ее технических характеристик:

- Высокая скорость обмена (full-speed signaling bit rate) - 12 Mb/s

- Максимальная длина кабеля для высокой скорости обмена - 5 m

- Низкая скорость обмена (low-speed signaling bit rate) - 1.5 Mb/s

- Максимальная длина кабеля для низкой скорости обмена - 3 m

- Максимальное количество подключенных устройств (включая размножители) - 127

- Возможно подключение устройств с различными скоростями обмена

- Отсутствие необходимости в установке пользователем дополнительных элементов, таких как терминаторы для SCSI

- Напряжение питания для периферийных устройств - 5 V

- Максимальный ток потребления на одно устройство - 500 mA

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

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

Питание непосредственно от USB возможно только для устройств с малым потреблением, таких как клавиатуры, мыши, джойстики и т.п.

Сигналы USB передаются по 4-х проводному кабелю

Таблица 2.4. - контакты USB

Номер контакта Назначение Цвет провода 1 V BUS Красный 2 D- Белый 3 D+ Зеленый 4 GND Черный Оплетка Экран Оплетка

Здесь GND - цепь "корпуса" для питания периферийных устройств, VBus - +5V также для цепей питания. Шина D+ предназначена для передачи данных по шине, а шина D- для приема данных.

Разработка структурированной кабельной системы (СКС)

Структурированная кабельная система (СКС) - это универсальная кабельная система здания, группы зданий, предназначенная для использования достаточно длительный период времени без реструктуризации.

Универсальность СКС подразумевает использование ее для различных систем:

- компьютерная сеть;

- телефонная сеть;

- охранная система;

- пожарная сигнализация.

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

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

- структурированная кабельная система должна быть выполнена в соответствии со стандартами - международным (ISO 11801), европейским (EN 50173);

- все коммуникации этажа должны быть сведены в единый центр коммутации (этажный распределитель), что ускоряет обслуживание сети и уменьшает время, затрачиваемое на переключение абонентов;

- СКС проектируется с учетом избыточности, как по числу абонентов, так и по пропускной способности, таким образом, закладывается возможность для дальнейшего ее расширения без реструктуризации;

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

- если на момент построения сети не известно точное количество необходимых рабочих мест, то СКС проектируется из расчета - одно рабочее место на каждые 6 м².

- на каждое рабочее место должно быть подведено два взаимозаменяемых разъема RJ45.

Устройства контроля и управления доступом предполагается устанавливать на двери, ведущие к следующим помещениям банка: кредитному отделу, отделу обслуживания частных клиентов, бухгалтерии, приемной дирекции, комнате охраны, отделу обслуживания корпоративных клиентов, серверной, отделу технической поддержки, отделу по связям с общественностью, отделу WEB-дизайна, а также кабинету начальника отдела технической поддержки. Помимо этого, предполагается установить устройство КУД на дверь, ведущую из приемной в общий коридор отделения банка, для учета рабочего времени сотрудников банка (для этого необходимо установить два устройства КУД, на вход и на выход). Значит, общее количество устанавливаемых устройств КУД равно двенадцати.

3. Реализация информационно-компьютерной системы контроля и управления доступом

В состав информационно-компьютерной системы контроля и управления доступом к охраняемым объектам предприятия входят аппаратная и программная подсистемы.

3.1 Реализация структуры базы данных

Основными критериями, предъявляемыми к информационной БД являются:

- простота и удобство в создании базы данных и последующей работе с ней;

- удобный пользовательский интерфейс, который позволяет иметь доступ к любой информации, а также оперативно менять информацию в БД;

- удобное и наглядное отображение результатов поиска нужной информации;

- возможность вывода на печать любой информации из БД.

Прежде чем начать создавать любую базу данных, надо четко определить следующее:

- назначение базы данных;

- как БД будет использоваться;

- какие сведения в этой базе данных будут храниться, т.е. надо выявить цель создания базы данных.

В разрабатываемой БД будут содержаться сведения:

- о группе (название);

- об уровне доступа (номер доступа);

- о рабочем месте (номер кабинета);

- о пользователях (Ф.И.О., адрес, телефон, фото, паспортные данные, дата рождения);

- о зарплате (месяц, зарплата, время проведенное на рабочем месте);

- о пропусках по болезни (дата начала больничного, дата окончания больничного);

- о переходе (время проведенное, переход из, переход в, индикатор удачного перехода, причина запрета, время входа, время выхода);

- о комнате (номер комнаты, уровень доступа);

- об этаже (номер этажа, путь к макету чертежа);

- о зданиях (адрес, номер здания, путь к макету плана);

Т.к. создается реляционная БД, то выделение объектов предметной области - это один из важных этапов проектирования БД.

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

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

Интуитивный подход - сразу устанавливаются типовые объекты предметной области и их взаимосвязи.

Наиболее рационально - это сочетание обоих подходов, т.к. на начальном этапе, как правило, нет полных сведений обо всех задачах.

Далее выполняется информационный анализ, который включает в себя:

- структурирование информации предметной области, т.е. ее представление отдельными структурными единицами - реквизитами и их размещение в источниках - документах (структурные единицы информации - реквизиты);

- формализация и моделирование данных, для их организации и обработки во внутримашинной сфере.

Проектирование БД начинается со сбора информации обо все объектах предметной области.

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

При построении модели данных в каноническом виде совокупность реквизитов объектов должна отвечать требованиям нормализации.

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

- объект должен содержать уникальный идентификатор - ключ;

- между описательными реквизитами не должно быть функциональных зависимостей;

- все реквизиты, входящие в составной ключ, должны быть взаимонезависимы;

- каждый описательный реквизит должен функционально полно зависеть от ключа;

- каждый описательный реквизит должен зависеть от ключа нетранзитивно, т.е. не должен зависеть через другой промежуточный реквизит.

Выполнение требований нормализации обеспечивает построение реляционной БД без дублирования данных и возможность поддержания целостности при внесении изменений.

Анализируя цель создания БД системы контроля и управления доступом, есть возможность сразу выделить объект «Оператор», который будет иметь следующие характеристики, приведенные на рисунке 3.34.

Таблица 3.1 - Описание таблицы «GroupWorker»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор группы пользователей.
groupname	Varchar(255)	not null	Название группы

Данные этого объекта отвечают требованиям нормализации:

- имеет уникальный идентификатор - ключ;

- между описательными реквизитами нет функциональной зависимости;

- каждый описательный реквизит функционально зависит от ключа.

Т.е. в полученных объектах все описательные реквизиты логически связаны.

Также, в проектируемую БД необходимо ввести еще девять объектов: «Уровень доступа», «Рабочее место», «Пользователь», «Пропущено по болезни», «Зарплата», «Переход», «Комната», «Этаж» и «Здание» описаны в таблицах 3.2-3.10.

Таблица 3.2 - Описание таблицы «AccessLevel»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор уровня доступа.
levelnumber	bigint(20)	not null	Уровень доступа к комнате, которую разрешено посещать

Таблица 3.3 - Описание таблицы «WorkBench»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор рабочего места.
workbenchNumber	bigint(20)	not null	Номер помещения- являющееся рабочим местом

Таблица 3.4 - Описание таблицы «User»

Название колонки	Тип данных	Ограничения	Описание
id	bigint(20)	not null	Первичный ключ, уникальный идентификатор работника.
FirstName	bigint(20)	not null	Имя сотрудника
LastName	Varchar(255)	not null	Фамилия сотрудника
birthday	Date	not null	Дата рождения
job	Varchar(255)	not null	Должность сотрудника
salary	Bigint(20)	not null	ставка
address	Varchar(255)	not null	Домашний адресс
phone	Varchar(255)	not null	Телефон
PassportData	Varchar(255)	not null	Серия и номер паспорта
photo	Varchar(255)	not null	Путь к фотографии на сервере
departmentName	Varchar(255)	not null	Название отдела
obligedspendTime	Bigin(20)	not null	Обязательное время проведенное на рабочем месте

Таблица 3.5 - Описание таблицы «ReralSalary»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор заработной платы.
Date	Date	not null	Номер помещения- являющееся рабочим местом
RealTimeWork	Bigint(20)	not null	Время проведенное на рабочем месте, за месяц
Salary	Bigint(20)	not null	Насчитанная заработная плата с учетом штрафов, больничных и премиальных

Таблица 3.6 - Описание таблицы «MissedByIllnes»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор больничного.
FromDate	Date	not null	Дата начала больничного
ToDate	Date	not null	Дата окончания больничного

Таблица 3.7 - Описание таблицы «Transition»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор перехода.
fromRoom	Bigint(20)	not null	Номер помещения
Io	Varchar(255)	not null	Время проведенное на рабочем месте, за месяц
isAccessPermited	Tinyint(1)	not null	Насчитанная заработная плата с учетом штрафов, больничных и премиальных
Reason	Varchar	not null	Причина запрета доступа
spendTime	Bigint(20)		Проведенное время в помещении
timeIn	Date	not null	Время входа
Timeout	Date	not null	Время выхода
toRoom	Bigint(20)	not null	Номер помещения из которого выходим

Таблица 3.8 - Описание таблицы «Room»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор помещения.
roomNumber	Int(11)	not null	Номер комнаты
acessLevel	Int(11)	not null	Уровень доступа

Таблица 3.9 - Описание таблицы «Stage»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор этажа.
StageNumber	Int(11)	not null	Номер этажа
svgFilePath	Date	not null	Путь к SVG файлу

Таблица 3.10 - Описание таблицы «Buildings»

Название колонки	Тип данных	Ограничения	Описание
Id	bigint(20)	not null	Первичный ключ, уникальный идентификатор больничного.
Address	Varchar(255)	not null	Дата начала больничного
buildingsNumber	Int(11)	not null	Дата окончания больничного
svgFilePath	Varchar(255)	not null	Путь к SVG файлу

Были выделены все объекты предметной области, опираясь на фундаментальное базовое понятие функциональных зависимостей. Совокупность реквизитов объектов предметной области отвечает требованиям нормализации. Связи между объектами предметной области приведены в таблице 3.3.

Таблица 3.11 - Связи объектов предметной области

Главный объект	Подчиненный объект	Тип связи	Ключ связи
Группа	Рабочее место	1:М	Код_группы
Группа	Уровень доступа	1:М	Код_ группы
Группа	Пользователь	1:М	Код_ группы
Пользователь	Зар. плата	1:М	Код_пользователя
Пользователь	Пропуск по болезне	1:М	Код_ пользователя
Пользователь	Переход	1:М	Код_ пользователя
Переход	Календарь	М:1	Код_календаря
Переход	Комната	М:1	Код_комнаты
Здание	Этаж	1:М	Код_здания
Этаж	Комната	1:М	Код_этажа

3.2 Описание процесса автоматизации сборки

Процесс сборки проводился с помощью Maven. Для иллюстрации настроек данного программного обеспечения, рассмотрим содержимое файла настроек pom.xml:

<?xml version="1.0" encoding="UTF-8"?>

<project>

<modelVersion>4.0.0</modelVersion>

<groupId>com.vaadin.tutorial</groupId>

<artifactId>Skudy</artifactId>

<packaging>war</packaging>

<version>1.0</version>

<name>Vaadin Web Application</name>

<properties>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<vaadin.version>7.0.0</vaadin.version>

<vaadin.plugin.version>${vaadin.version}</vaadin.plugin.version>

</properties>

<repositories>

<repository>

<id>vaadin-addons</id>

<url>http://maven.vaadin.com/vaadin-addons</url>

</repository>

<repository>

<id>vaadin-snapshots</id>

<url>http://oss.sonatype.org/content/repositories/vaadin-snapshots/</url>

<releases>

<enabled>false</enabled>

</releases>

<snapshots>

<enabled>true</enabled>

</snapshots>

</repository>

</repositories>

<pluginRepositories>

<pluginRepository>

<id>vaadin-snapshots</id>

<url>http://oss.sonatype.org/content/repositories/vaadin-snapshots/</url>

<releases>

<enabled>false</enabled>

</releases>

<snapshots>

<enabled>true</enabled>

</snapshots>

</pluginRepository>

</pluginRepositories>

<dependencies>

<dependency>

<groupId>com.vaadin</groupId>

<artifactId>vaadin-server</artifactId>

<version>${vaadin.version}</version>

</dependency>

<dependency>

<groupId>com.vaadin</groupId>

<artifactId>vaadin-client-compiled</artifactId>

<version>${vaadin.version}</version>

</dependency>

<dependency>

<groupId>com.vaadin</groupId>

<artifactId>vaadin-client</artifactId>

<version>${vaadin.version}</version>

<scope>provided</scope>

</dependency>

<dependency>

<groupId>com.vaadin</groupId>

<artifactId>vaadin-themes</artifactId>

<version>${vaadin.version}</version>

</dependency>

<dependency>

<groupId>javax.servlet</groupId>

<artifactId>servlet-api</artifactId>

<version>2.4</version>

<scope>provided</scope>

</dependency>

<dependency>

<groupId>org.eclipse.persistence</groupId>

<artifactId>javax.persistence</artifactId>

<version>2.0.4.v201112161009</version>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-core</artifactId>

<version>4.1.9.Final</version>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-entitymanager</artifactId>

<version>4.1.9.Final</version>

</dependency>

<dependency>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

<version>5.1.23</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-core</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-context</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-web</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-context-support</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-orm</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-aop</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-beans</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.11</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-jdbc</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-test</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework.data</groupId>

<artifactId>spring-data-jpa</artifactId>

<version>1.3.0.RELEASE</version>

</dependency>

<dependency>

<groupId>org.aspectj</groupId>

<artifactId>aspectjweaver</artifactId>

<version>1.7.1</version>

</dependency>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-aspects</artifactId>

<version>3.2.1.RELEASE</version>

</dependency>

<dependency>

<groupId>com.vaadin.addon</groupId>

<artifactId>jpacontainer</artifactId>

<version>3.0.0.beta1</version>

</dependency>

</dependencies>

<build>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<configuration>

<source>1.6</source>

<target>1.6</target>

</configuration>

</plugin>

<!-- As we are doing "inplace" GWT compilation, ensure the widgetset -->

<!-- directory is cleaned properly -->

<plugin>

<artifactId>maven-clean-plugin</artifactId>

<version>2.4.1</version>

<configuration>

<filesets>

<fileset>

<directory>src/main/webapp/VAADIN/widgetsets</directory>

</fileset>

</filesets>

</configuration>

</plugin>

<plugin>

<groupId>com.vaadin</groupId>

<artifactId>vaadin-maven-plugin</artifactId>

<version>${vaadin.plugin.version}</version>

<configuration>

<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>

<!-- <runTarget>mobilemail</runTarget> -->

<!-- We are doing "inplace" but into subdir VAADIN/widgetsets. This

way compatible with Vaadin eclipse plugin. -->

<webappDirectory>${basedir}/src/main/webapp/VAADIN/widgetsets

</webappDirectory>

<hostedWebapp>${basedir}/src/main/webapp/VAADIN/widgetsets

</hostedWebapp>