Файл: Дипломный проектработа тема работы.pdf

31
Технические характеристики:

Габаритные размеры – 123х97х8 мм.

Дистанция считывания – не менее 70 мм;

Диапазон рабочих температур – от минус 20 до + 50
°
С;

Напряжение питания – от 10 до 15 В;

Ток потребления, не более 180 мА;
3.4 Преобразователь интерфейсов "USB-RS485"
Рисунок 3.4 Преобразователь интерфейсов «USB-RS485»
Преобразователь интерфейсов «USB-RS485» предназначен для преобразования сигналов интерфейса USB в сигналы двухпроводного магистрального интерфейса RS-485 с гальванической изоляцией.

Электропитание осуществляется от USB-порта ПК;

Работает в среде ОС Windows образуя виртуальный COM- порт.
Технические характеристики:
1.
Напряжение питания – USB порт ПК;
2.
Потребляемый ток, не более – 200 мА;
3.
Скорость передачи данных, Бод – 110, 300, 1200, 2400, 4800,
9600, 19200, 38400, 57600, 115200;
4.
Диапазон температур – от минус 30 до +50
°
С;
5.
Относительная влажность воздуха – до 93 % при +40
°
С;
6.
Габаритные размеры – не более 17 х 53 х 8 мм.

32
3.5 Общая схема системы
Рисунок 3.5 Схема системы
3.6 Принцип работы пары: бесконтактная карта - считыватель.
Принцип работы пары бесконтактная карта – считыватель показан на рисунке 3.6.
Рисунок
3.6 Принцип работы пары: бесконтактная карта - считыватель.
Считыватель содержит генератор высокой частоты G, который запитывает антенну считывателя Lc. За счет наличия электромагнитной связи

33
М между антенной считывателя и антенной идентификатора (карты) LK в последней наводится переменное напряжение, величина которого зависит от конструктивного исполнения и расстояния между картой и считывателем.
Наведенное напряжение используется для питания микросхемы карты DK через выпрямитель, образованный диодом VDп и фильтрующим конденсатором Сф.
Микросхема карты DK модулирует напряжение в антенне Lк путем ее шунтирования резистором Rш. За счет связи антенн модуляция появляется в антенне считывателя Lc, детектируется диодом VDд и поступает на микросхему считывателя Dc, которая дешифрирует код карты и передает его на контроллер через интерфейс Int.
3.7 Программирование ключей
Для программирования ключей используется персональный компьютер и программа "UProg.exe", которая входит в комплект поставки оборудования
Контроллер доступа С2000-2 (Рисунок 3.7). Данная программа позволяет добавлять и удалять ключи, задавать и изменять атрибуты ключей, сохранять список ключей в файл, загружать список ключей из файла в прибор и т.д.

34
Рисунок 3.7 Окно программирования ключей.
Кроме того, запрограммировать ключи можно без использования компьютера, с помощью одного или нескольких МАСТЕР-ключей. МАСТЕР- ключом может быть любой идентификатор, для которого задан тип ключа –
МАСТЕР. Предъявление МАСТЕР-ключа включает режим программирования ключей. Предъявляемые в этом режиме новые ключи заносятся в память контроллера с типом ключа "основной", наследуют уровень доступа МАСТЕР- ключа и имеют неограниченный срок действия.

35
4 Разработка базы данных
4.1 Выбор хранилища данных
Для решения поставленных задач было решено в качестве хранилища данных, в создаваемой информационной системе, использовать систему управления базами данных, поддерживающую реляционную модель представления данных и язык запросов SQL.
Для обеспечения сетевого многопользовательского доступа к данным решено использовать СУБД, поддерживающую клиент-серверную архитектуру, а хранение данных должно быть централизовано.
4.1 Таблица Обзор популярных СУБД
СУБД
Сетевой доступ к данным
Семейство
ОС
Поддержка
Лицензия
Стоимость
Опыт разработки
Microsoft
SQL
Server
Да
Windows
Есть
Коммерч.
Высокая -
Oracle
Да
Windows и *nix
Есть
Свободная/
Коммерч.
Высокая -
MySQL
Да
Windows и *nix
Есть
Свободная/
Коммерч.
-
Есть
Firebird
Да
Windows
Нет
Свободная
-
-
Согласно представленным данным наиболее оптимально использование
MySQL в связи с тем, что

данная СУБД обладает всеми необходимыми возможностями;

может быть развернута практически на любой из широко распространенных операционных систем;

существует два варианта использования данной СУБД, коммерческое использование подразумевает поддержку производителя
СУБД, но при этом допускается свободное использование без приобретения лицензии;

36

в настоящее время еѐ наличие обеспечивается большинством дата центров;

имеется положительный опыт разработки приложений с использованием данной СУБД.
4.2 Схема базы данных
Исходя из требований, заявленных на этапе создания технического задания, были выделены сущности и разработан первый вариант схемы базы данных.
Основные сущности:
1. тип события;
2. должность;
3. владелец карты;
4. отдел;
5. автотранспорт;
6. событие;
7. место события;
8. идентификационная карта;
9. дежурства.

37
Спроектирована следующая модель базы данных.
Событие
PK
Id
Дата начала
Время начала
Дата окончания
Время окончания
Id тип события
Id дежурство
Id место события
Id карта
Владелец карты
1
FK
,
PK
Id
ФИО
Фото id карты
Статус
Id должность
Id отдел
Id автотранспорта
Идентификационная карта
2
FK
,
1
FK
,
1
FK
,
PK
Id
Дата выдачи
Дата окончания
Номер карты физическии
Место
1
FK
,
1
FK
,
PK
Id
Название
Описание
Тип события
1
FK
,
1
FK
,
PK
Id
Название типа события
Описание типа события
Дежурства
1
FK
,
1
FK
,
PK
Id
Дата начала
Дата окончания
Время начала
Время окончания
Id владелец карты (ответственныи)
Роль ответственного
Должность
1
FK
,
1
FK
,
PK
Id
Название
Отдел
1
FK
,
1
FK
,
PK
Id
Название отдела
Автотранспорт
1
FK
,
1
FK
,
PK
Id
Марка
Модель
Цвет
Гос. номер
Разрешение (допуск)
Рисунок 4.2. Схема базы данных.
Данная модель является прототипом, в ней учтены основные сущности и отображены связи между ними. При разработке физической модели базы данных при необходимости структура может быть дополнена, а сами таблицы оптимизированы с целью приведения их к нормальной форме.
4.3 Физическая модель базы данных
Для более удобного перехода к физической модели базы данных в таблице приведено соответствие элементов представленных в схеме базы данных элементам в физической модели данных. Имена и типы данных выбраны с учетом требований выбранной СУБД.

38
Таблица 4.3 Соответствие элементов схемы и физической модели базы данных
Схема базы данных
Физическая модель базы данных
Тип данных, примечание
Персона
persona
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Фамилия familia varchar(50)
Имя imya varchar(50)
Отчество otchestvo varchar(50)
Фото foto blob
Владелец карты
vlad_kard
Таблица
Id id int(10)
Id персоны id_persona int(10)
Id карты id_card int(10)
Id статус id_status int(10)
Id должность id_dolznost int(10)
Id отдел id_otdel int(10)
Id автотранспорт id_avto int(10)
Id присутствие id_prisust int(10)
Должность
dolznost
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Название nazvanie varchar(50)
Отдел
otdel
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.

39
Таблица 4.3 продолжение
Название отдела nazv_otdel varchar(50)
Тип события
tip_sob
Таблица
Id id int(10)
Название типа navz_tip_sob varchar(50)
Описание типа opis_tip_sob varchar(50)
Присутствие
prisust
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Название tip_prisust varchar(50)
Описание opis_tip_prisust varchar(50)
Автотранспорт
avto
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Марка marka varchar(50)
Модель model varchar(50)
Цвет cvet varchar(50)
Гос. Номер gos_nomer varchar(50)
Разрешение (допуск) dopusk varchar(50)
Событие
sobitie
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Дата и время data_vremya
Datetime
Id тип события id_tip_sob int(10)
Id дежурство id_dezurstv int(10)
Id место id_mesto_sobitia int(10)

40
Таблица 4.3 продолжение
Id карта id_ident_card int(10)
Место события
mesto_sobitia
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Название места nazv_mesta varchar(50)
Описание места opis_mesta varchar(50)
Роль ответственного
rol_otvetstv
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Название роли nazv_roli varchar(50)
Описание роли opis_roli varchar(50)
Дежурства
dezurstv
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Дата и время начала data_vremya_nac
Datetime
Дата и время окончания data_vremya_okonc
Datetime
Ответственный (id карты) id_vladelec_kart int(10)
Id роль ответственного id_rol_otvetstv int(10)
Идентификационная карта
ident_card
Таблица
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Дата окончания data_okoncan
Datetime
Дата выдачи data_vidaci
Datetime
Номер карты физический nomer_karta varchar(50)
Статус
status
Таблица

41
Таблица 5.3 продолжение
Id id int(10), не нулевое, авто инкрементальное, ключевое.
Название статуса navz_status varchar(50)
Описание статуса opis_status varchar(50)
В СУБД MySQL реализована технология т.н. представлений, существенно облегчающих работу с данными, когда необходимо сделать связную выборку данных из разных таблиц. В нашем случае для того, чтобы узнать находится ли человек на территории и сформировать соответствующий отчет необходимо каждый раз обращаться к нескольким таблицам. Что бы облегчить работу, было решено создать представление «статус персоны», в результате работы которого, мы получим отдельную таблицу со значениями
«Фамилия», «Имя», «Отчество», «Описание присутствия».
Скрипт, набор команд, на языке SQL приведен в Приложении 2.
Результатом выполнение данного скрипт на сервере MYSQL является спроектированная физическая база данных.
Схема физической модели базы данных приведена в Приложении 2.
4.4 Общий алгоритм работы диспетчера службы охраны.
Существует два режима работы системы: автономный и с участием диспетчера службы охраны. Описание алгоритма работы с участием оператора:

посетитель подносит карту к считывателю;

контроллер доступа получает номер карты и передает его в АРМ диспетчера службы охраны;

42

АРМ получив код карты, отправляет запрос в базу данных и отображает посредствам интерфейса данные о владельце карты, доступе и событии;

диспетчер службы охраны сверяет личность посетителя, в случае подтверждения личности разрешает доступ посетителю.
В автономном режиме участие оператора не требуется, система сама принимает решение о доступе посетителя согласно разрешениям из базы данных.
Детальный алгоритм работы системы приведен в приложении 1.
Рисунок 4.4 Интерфейс главного окна «АРМ диспетчер охраны»
4.5 Интерфейс отчета о присутствии персон
Для отображения информации о местонахождении сотрудников в техническом задании было заявлено требование, согласно которому был

43 разработан соответствующий функционал. Оператор может вызвать из главного окна форму, в которой будут отображены сотрудники в зависимости от их присутствия на территории охраняемого объекта.
Рисунок 4.5 Интерфейс отчета о присутствии«АРМ диспетчер охраны»

44
Министерство образования и науки Российской Федерации
Федеральное государственное автономное образовательное учреждение высшего образования
«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ
ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
ЗАДАНИЕ ДЛЯ РАЗДЕЛА
«ФИНАНСОВЫЙ МЕНЕДЖМЕНТ, РЕСУРСОЭФФЕКТИВНОСТЬ И
РЕСУРСОСБЕРЕЖЕНИЕ»
Студенту:
Группа
ФИО
З-8301
Горностаев Павел Викторович
Институт
Кибернетики
Кафедра
Вычислительной техники
Уровень
образования
Инженер
Направление/специальность
Вычислительные машины, комплексы системы и сети
Исходные данные к разделу «Финансовый менеджмент, ресурсоэффективность и ресурсосбережение»:
1. Стоимость ресурсов научного исследования (НИ):
материально-технических,
энергетических,
финансовых, информационных и человеческих
2. Нормы и нормативы расходования ресурсов
3. Используемая
система налогообложения, ставки
налогов, отчислений, дисконтирования и кредитования
Перечень вопросов, подлежащих исследованию, проектированию и разработке:
1. Оценка
коммерческого
потенциала
инженерных
решений (ИР)
2. Формирование плана и графика разработки и
внедрения ИР
3. Обоснование необходимых инвестиций для разработки и
внедрения ИР
4. Составление бюджета инженерного проекта (ИП)
5. Оценка ресурсной, финансовой, социальной, бюджетной
эффективности ИР и потенциальных рисков