СКУД Артонит

Билетная система Артонит Тикет

Парковочная система Артонит ПаркОфис

СКУД Артонит 10

СКУД промышленные предприятия

Артонит Сити

СКУД жилой комплекс

Артонит Сити интеграционная платформа СКУД

СКУД он-лайн

Артонит Тикет

Билетная система.


Штрих-код

Система автоматизированной on-line парковки и сбора платежей

Парковочная система без  затрат.

Модернизация старых парковочных систем.

Главная Библиотека Учебные материалы Основная задача СКУД и методы ее решения - Информационная модель СКУД.

Консультации и поддержка

support@artonit.ru

(926)-228-7314


Отдел продаж

sale@artsec.ru

+7-495- 970-46-86

+7-926- 526-71-41

Основная задача СКУД и методы ее решения - Информационная модель СКУД.
19.02.2013 09:59
Индекс материала
Основная задача СКУД и методы ее решения
Основная задача СКУД
Логические сущности СКУД. Контроллер СКУД.
Способы решения задачи СКУД. Валидатор.
Основные и дополнительные условия валидации. Место валидатора в СКУД.
От анализа к синтезу. Взлетаем!
Информационная модель СКУД.
Раздел 3. Абстрактная модель программного обеспечения СКУД.
От теории к практике!
Все страницы

Информационная модель СКУД.

Информационная модель СКУД создана на базе задачи СКУД и предназначена для определения основных потоков информации, необходимых для практической реализации СКУД (программ, контроллеров, других модулей).
В основе информационной модели лежат следующие постулаты:
1.    Есть минимально необходимый набор данных (базовые данные), без которых задачу решить невозможно:
a.    Код карты доступа.
b.    Точка прохода.
c.    Набор временных зон как условие дополнительной валидации (Рассматривать упрощенную модель - без временных зон - смысла нет).
2.    Процесс валидации возложен на контроллеры СКУД, который является основным элементом принятия решения. ВНИМАНИЕ! Это очень важный момент, ибо на основании этого постулата и формируются информационная модель СКУД.
Информационная модель база данных СКУД (БД СКУД).
После добавления условия валидации по времени задача СКУД приобретает следующий вид:

...Точка прохода 1 Точка прохода 2 Точка прохода N
Код карты 1 Проход запрещен Маска временных зон Маска временных зон
Код карты 1 Маска временных зон Проход запрещен Маска временных зон
Код карты N Маска временных зон Маска временных зон Маска временных зон

Обратите внимание, что в запрет прохода и отсутствие дополнительных условий валидации (маска временных зон, равная 0x0000) - не одно и то же.
Маска tz=0x0000 означает проход без ограничений по времени.

Информационная модель контроллера СКУД.

Контроллер СКУД с точки зрения информации рассматривается как аналог центральной базы, сокращенной до возможностей контроллера СКУД, и который хранит те же самые данные, что и центральная база данных, а именно:
a.    Коды карты доступа.
b.    Список точек прохода, что в случае с физическим контроллером СКУД обычно называется каналом (или дверью). В рамках одного контроллера СКУД каналов может быть 1 и более.
c.    Набор временных зон как дополнительное условие валидации.

Валидность карты в рамках контроллера СКУД.

В рамках контроллера код карты считается валидным, если:
1.    Код карты для двери – источника есть в базе данных контроллера СКУД (основное условие).
2.    Время получения кода карты лежит в диапазоне хотя бы одной временной зоны (дополнительное условие).
Если карта валидна, то проход реле управления должно быть включено.

Система команд контроллера СКУД.

Система команд контроллера СКУД необходима для заполнения БД контроллера СКУД внешними приложениями.
Минимальный набор команд включает в себя следующие команды:
№ п/п    Команда    Пояснения    
Reportstatus    Ответ позволяет получить информацию о состоянии объекта, его текущей версии и т.п.    
Getversion    Получение версии контроллера    
ClearKey    Очистка встроенной базы данных    
WriteKey    Запись кода карты во встроенную базу данных.    
DeleteKey    Удаление кода карты из встроенной базы данных.    
Readkey    Чтение имеющейся информации о свойствах кода карты.    
Чтение журнала событий    Должен быть механизм, позволяющий читать журнал события контроллера.    
Реализация этого набора команд позволяет правильно заполнить БД контроллера СКУД, чего достаточно для правильной валидации.

Взаимодействие моделей БД СКУД и контроллеров СКУД.

После формирования информационных моделей БД СКУД и контроллеров СКУД становится ясно как можно реализовать работу всей системы.
Результатом работы программного обеспечения является:
1.    передача списков кодов карт из БД СКУД в контроллеры СКУД (как основное условие валидации).
2.    Передача параметров дополнительных условий валидации.
3.    Сбор журнала событий из контроллеров в журнал событий БД СКУД.
Информационная модель полностью совпадает с задачей СКУД.

Рисунок 1 Взаимодействие моделей СКУД.
На рисунке показан пример передачи данных для двух разнотипных контроллеров.
На рисунке видно, что коды карт для двери Door1 необходимо передать в контроллер К1 СКУД; коды карт по дверям Door2 и  Door3 необходимо передать в контроллер К2, который обслуживает 2 двери (обозначены как потоки с номером 1).
Кроме того, необходимо в каждый из контроллеров загрузить параметры дополнительной валидации (временные зон и список рабочих дней. Поток с номером 2).
Данные из журнала событий контроллеров необходимо передать в общий журнал событий (поток номер 3).

Техническое задание на ПО СКУД.

После формирования информационной модели можно формировать техническое задание к программному обеспечению пакета СКУД:
1.    Обеспечить загрузку карт из БД СКУД в БД контроллеров СКУД.
2.    Обеспечить передачу условий валидации из БД СКУД в БД контроллеров СКУД.
3.    При изменении данных в БД СКУД обеспечивать аналогичные изменения в БД контроллеров (т.е. обрабатывать добавление, удаление и изменения в таблице прав).
4.    Обеспечить сбор журналов событий контроллеров в единый журнал СКУД.
5.    Предоставить инструменты контроля за работой системы и ее обслуживания.
6.    Обеспечить пользователем разумно удобный способ работы с системой (ввод данных, получение отчетов и т.п.).

Дополнительные требования к ПО СКУД.

В ходе анализ задач добавились следующие уточнения:
1.    Заранее не определено, на какой именно СУБД будет сделать база данных СКУД.
2.    Архитектура физической СКУД может быть распределенной, кластерной, и необходимо обеспечить работу ПО в рамках этой архитектуры.
3.    Надежность каналов связи не гарантируется.
4.    Конкретная модель контроллеров СКУД заранее не определена.
Если дополнительные требования удастся реализовать, то можно будет получить следующий результат:
1.    Возможность использовать различные СУБД.
2.    Кластерная структура позволит снять ограничение на размер СКУД.
3.    Высокая надежность при работе с плохими (или медленными) линиями связи.
4.    Использование оборудование различных производителей в рамках одной системы, что позволит включать в систему уже установленное оборудование.