Основная задача СКУД и методы ее решения | | Печать | |
19.02.2013 09:59 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Введение.В ходе разработки ПО Артонит были сформулированы постулаты, которые и легли в основу и программного, и аппаратного обеспечения:
Логика работы программного обеспечения Артонит построена на этих постулатах. Результат - простое, надежное и достаточно универсальное решение, мало зависящие от физического оборудования, от размера системы, от сложности решаемых задача (в рамках СКУД). Очевидно, что другие формулировки задачи СКУД также позволят получить результат, но про решения в других базисах пусть напишет тот, кто это сделал. Основная задача СКУД.Для решения любой задачи необходимо эту задачу формализовать. Для СКУД задача ставится следующим образом:
Анализ задачи выявляет несколько любопытных вопросов:
Можно ли попытаться формализовать задачу СКУД, не зная ответов на поставленные вопросы? Успех решения задачи зависит от правильности выбранных переменных. Автор предлагает следующие ответы на поставленные вопросы:
Т.о., в задаче СКУД появились термины: Точка прохода - абстрактное устройство, которое может выполнять 2 действия: пускать или не пускать. Код карты - набор данных, который однозначно характеризует пользователя. В рамках выбранных терминов задачу СКУД можно выразить в форме таблицы: Табличное представление задачи СКУД. Правила прохода.
Здесь: Door0, Door1 и т.д. - названия точек прохода. Key1, Key2 и т.д. - коды карт. + означает разрешение на проход через точку прохода. - означает запрет на проход через точку прохода. Под разрешением прохода следует понимать реализацию мер, позволяющих коду карты пройти в указанную дверь. В табличной форме отражена вся задача СКУД, и практическая её реализация является задачей разработчиков СКУД. Обеспечить проход карт пользователей в соответствии с таблицей правил прохода есть основная задача СКУД! Второстепенные задачи СКУД. Журнал событий.Обеспечив решение основной задачи СКУД разработчик столкнется с очевидными требованиями:
Тут необходимо сделать однозначное ограничение: второстепенные задачи СКУД могут входить в общее решение СКУД, но не обязательно. Резюме:
Логические сущности основной задачи СКУД.Выделим логические сущности, наличие которых позволит решать основную задачу СКУД. Ограничим предметную область:
После ограничения предметной области система выглядит таким образом: Считыватели Сч каким-то образом читают признаки пользователя и передают в среду передачи код ключа. Далее, очевидно, необходимо проверить этот код по таблице прав проходов, и на ее основании нужная дверь должна открыться. Сразу же возникают очевидные проблемы:
Т.о., реальная картина принимает несколько иной вид, и ее отличия таковы:
Картинка приобретает вид: Тут: Контроллер - логическое устройство, в рамках которого определяется связь считывателя и двери. На картинке считывателю Сч1 соответствует дверь Door1. Контроллер обеспечивает взаимодействие с физическими устройствами (считывателямя, замками, другими датчиками). Валидатор - логическое устройство, которое выполняется проверку валидности кода карты для двери. Данные от считывателя Сч1 попадают в контроллер. Контроллер по каким-либо настройкам знает, что он привязан к двери Door1. Контроллер передает код карты валидатору, указав, что проверку делать надо для двери Door1. Валидатор выполняет проверку таблицы прав, и выдает результат валидации в контроллер. В зависимости от результата контроллер выдает (или не выдает) команду управления дверью Door1.
Варианты организации контроллера.В приведенной выше картинке одному считывателю соответствует одна дверь. Могут ли быть более сложные варианты контроллера? Недолгое размышление дает очевидный ответ на этот вопрос: могут. Приведу некоторые примеры: Одна дверь на 2 считывателя.В приведенном примере видно, что для прохода в одну сторону необходимо поднести карту к считывателю Сч1, а для прохода в другую сторону - к считывателю Сч2. Если ли для таблицы прав прохода разница в количестве подключенных считывателей? С точки зрения задачи СКУД разницы нет, ибо основная задача решается однозначно (пускать или не пускать). А вот с точки зрения контроля за работой системы разница есть, ибо контроль потребует дать ответ на вопрос: в какую сторону был проход? Тут мы наблюдаем интересную взаимосвязь: второстепенные задачи оказывают влияние на основную задачу. Ведь для основной задачи нет разницы к какому считывателю была поднесена карта. Проверка осуществляется по набору данных дверь - код карты, и позволяет однозначно выдать решение. А второстепенная задача - определение направления прохода - требует внести изменения в таблицу прав т.о., чтобы можно было определить направление прохода. Что, задача СКУД сформулирована неправильно? Нет, задача СКУД сформулирована правильно. Просто предлагаемая конфигурация в задаче СКУД рассматривается как две независимые двери. По совокупности требований задача оборудования 1 двери двумя считывателями требует следующей организации: Если все пользователи могут ходить туда-сюда через дверь, то данные в колонках Door1 и Door2 совпадают. Door1 можно рассматривать как Вход двери, Door2 можно рассматривать как Выход двери. Более того, ничто не мешает построить систему с любым количеством входов и выходов, и рассматривать это все как одну дверь. Шлюз или турникет.Другая типовая задача - это реализация шлюза. Задача шлюза сводится к тому, чтобы не допустить одновременное открывание обоих дверей. Между дверями Door1 и Door2 как правило находится замкнутое пространство, и механизм шлюза позволяет более строго контролировать проход пользователей. Анализ работы показывает такие же противоречия, как и при работе с системой 1 дверь на два считывателя: для СКУД достаточно одного контроллера и проверки по одной двери, а для неосновной задачи требуется разделение дверей. При этом возникает дополнительное взаимодействие между контроллерами, чтобы обеспечить нужный режим работы шлюза: Для основной задачи СКУД шлюз рассматривается как 2 независимые точки прохода. Это позволит на каждую дверь иметь свой список валидных карт. Для дополнительных задач такая схема тоже удобна, ибо позволяет контролировать направление прохода. Тонкости взаимодействия дверей возложены на контроллеры, которые нужным образом взаимодействуют другу с другом, обеспечивая правильный режим работы шлюза. В описанном примере видно, что конфигурация Шлюз должна рассматриваться на уровне контроллеров, и никак не влияет на основную задачу СКУД. Резюме:
Основные и дополнительные условия валидации. Место валидатора в СКУД.Глагол "валидация" следует рассматривать как производное от английского глагола to validate, что переводится как "делать действительным", "признавать имеющим силу".
Главное условие валидации.В рамках модели СКУД карта считается валидной, если выполнены основное и дополнительное условие валидации. Очевидно, что если не выполнено основное условие валидации, то остальные условия проверять не имеет смысла. Дополнительное условие валидации.Дополнительные условия валидации выполняются после успешного выполнения главного условия и подразумевают под собой разного рода дополнительные проверки. Дополнительное условие валидации может и отсутствовать (что характерно для простых моделей СКУД, либо для упрощенных режим использования современных СКУД). В общем случае под дополнительным условием валидации могуть быть любые специфические варианты его реализации. Самое очевидное и востребованное дополнительное условие валидации – это ограничения прохода по времени (использование временных зон). Рассмотрим способы взаимодействия контроллеров, валидаторов и основной задачи СКУД. Место валидатора в СКУД. Один валидатор, много контроллеров.Оборудование (считыватели, двери,турникеты) подключены к контроллерам. Поток данных от контроллеров поступает в валидатор, единый на всю систему. Валидатор имеет доступ к таблице СКУД. Получив событие или запрос от контроллера, на основании данных код карты - дверь валидатор выполняет проверку (валидацию) по таблице СКУД. Вариант валидации (по двери или по карте) выбирается исходя из наибольшего быстродействия. Место валидатора в СКУД. Валидатор на каждый контроллер.Оборудование (считыватели, двери,турникеты) подключены к контроллерам. Поток данных от контроллеров поступает в валидаторам, причем для каждого контролера есть свой валидатор. Каждый валидатор имеет доступ к таблице СКУД. Получив событие или запрос от контроллера, на основании данных код карты - дверь валидатор выполняет проверку (валидацию) по таблице СКУД. Вариант валидации (по двери или по карте) выбирается исходя из наибольшего быстродействия. Место валидатора в СКУД. Один валидатор и один контроллер.Необходимо отметить, что возможен и такой вариант реализации системы: Оборудование (считыватели, двери,турникеты) подключены к одному контроллеру. Поток данных от контроллера поступает в валидатор. Валидатор имеет доступ к таблице СКУД. Получив событие или запрос от контроллера, на основании данных код карты - дверь валидатор выполняет проверку (валидацию) по таблице СКУД. Вариант валидации (по двери или по карте) выбирается исходя из наибольшего быстродействия.
Резюме:
|
... | Точка прохода 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. Использование оборудование различных производителей в рамках одной системы, что позволит включать в систему уже установленное оборудование.
Целью создания абстрактной модели СКУД было:
1. Выделить минимальный набор абстрактных сущностей СКУД,
2. Определить порядок и механизм взаимодействия абстрактных сущностей.
Выделение абстрактных сущностей позволяет создать программное обеспечение, минимально зависящее от способов реализации конкретных элементов системы.
По результатам моделирования были выделены следующие абстрактные сущности:
1. БД СКУД как хранилище прав прохода,
2. Контроллер СКУД, как основной механизм валидации карты.
Абстрактная БД СКУД.
Независимо от способа реализации БД СКУД рассматривается как некая таблица, в которой хранятся права прохода.
Механизм реализации этой таблицы может быть различным (не обязательно в таком виде, как это указано в информационной модели).
Задача: выделить механизм, который позволяет получить таблицу прав независимо от способа реализации этой таблицы.
Вариант решения задачи: таблица прав прохода формируется как ряд последовательных действий по добавлению и удалению записей.
Если этот набор действия зафиксировать и сделать доступным извне, то повторение этих операций приведет к получению копии таблицы прав.
Т.о., достаточно иметь очередь команд на формирование таблицы прав в открытом доступе, чтобы привести в соответствие любую подчиненную таблицу прав (в контроллерах).
Реализация этой очереди для каждого из контроллеров СКУД позволит добиться однозначного соответствия БД контроллера СКУД базе данных СКУД.
Т.о., БД СКУД должна предоставить:
1. Таблицу очереди команд,
1. Процедуру вставки событий.
В ходе дальнейшего развития может предоставляться доступ и к другим элементам базы данных (например, к функциям для интеграции)
Абстрактный контроллер СКУД.
Контроллер СКУД должен обеспечить поддержку и реализацию минимального набора команд, перечень которых изложен в разделе Информационная модель СКУД.
Наличие этого набор обеспечит прием команд из очереди команд БД СКУД, и БД контроллера СКУД и БД СКУД будут совпадать, что и требуется для решения задачи.
Связь между БД СКУД и контроллером СКУД.
Между БД СКУД и контроллером СКУД должен быть набор ПО, который удовлетворяет требованиям технического задания на ПО СКУД.
Вариантов может быть много, и некоторые из них описаны в Приложении 4.
Очевидно, что появляется уровень передачи данных
Т.к. набор команд абстрактного контроллера СКУД известен, то очевидно, что уровень передачи данных должен реализовать этот набор команд.
В результате абстрактная модель программного обеспечения СКУД имеет такой вид:
Рисунок 2 Абстрактная модель программного обеспечения СКУД
При таком уровне абстрагирования система может быть реализована в различных модификациях. При таком подходе:
1. для БД СКД может быть использована любая СУБД.
2. При реализации уровня передачи данных можно не учитывать специфику контроллеров СКУД и уделить внимание вопросам надежности.
3. Абстрактная модель контроллера СКУД позволяет:
a. Использовать разнотипные физические контроллеры СКУД.
b. Использовать программно реализованные объекты СКУД.
Этот раздел написан 3 апреля 2020 г, через 7 лет после публикации первых разделов.
На мой взгляд, теперь изложенный материал получил логическое завершение: показан путь от теории к практике.
Пришла пора рассмотреть вопрос: а как же теория реализуется на практике?
Ниже я даю ответ на этот вопрос.
База СКУД - основное хранилище всей информации.
Набор прав хранится в таблице cardidx. Cardidx - это реальное название таблицы в базе данных СКУД ShieldPro.gdb.
Карты для Door1 должны ходить через точку прохода Door1А, работающей под управлением Контролера А.
Карты для Doorr2 должны ходить через точку прохода Door1Б, работающей под управлением Контролера Б.
Карты для DoorN3 (на рисунке не указана, но надо понимать, что точек прохода в базе много) должны ходить через точку прохода Door1В, работающей под управлением Контролера В.
и т.д. для все точек прохода.
Тут же, в БД СКУД, хранится журнал событий, в котором фиксируются все события (таблица Events).
Двери Door1А, Door1Б, Door1В и соответствующие им считыватели подключены к Контроллерам А, Б и В.
Как же решить задачу СКУД?
Очевидно, что надо записать нужные карты в нужные контроллеры. Для этого драйвер должен обратиться к базе данных, выбрать список карт для своего контроллера, и записать карты в контроллер. Драйвер "знает" протокол обмена со своим контроллером, и процесс загрузки карт проходит без проблем.
Задача СКУД решена: в каждой точке прохода пройдут только те карты, которым там можно ходить.
Таблица прав постоянно меняется.
Пришел новый сотрудник - ему выдали карту.
Уволился сотрудник - карту удалили.
Очевидно, что таблица прав постоянно меняется, и эти изменения необходимо вносить в контроллеры.
Задача очевидна, но как её реализовать на практике?
Вариантов несколько. В программном обеспечении Артонит 10 это решено исходя из следующих предпосылок:
Идея прямого подключения драйвера к базе данных вполне работоспособна, но тут впору вспомнить о ряде дополнительных требований:
Дополнительные требования к СКУД:
В этом разделе показано, как на основе теоретических предпосылок создана и работает система контроля доступа Артонит 10.
Система успешно и стабильно работает с 2010 г.
За это время в состав системы были добавлены контроллеры серии Артонит, ZKTeco, организована работа со сканерами штрих-кода, системы распознавания государственных регистрационных знаков.
Все это было сделано путем развития драйверов, с минимальными изменениями базы данных, без остановки работы СКУД (или замены её на новый вариант).
В ходе эволюции драйвер взял на себя обязанности валидатора (и имеет прямое подключение к базе данных СКУД) и обеспечивает обработку кодов карт в режиме он-лайн.
По мере роста размеров объектов актуальным стал контроль за работой самой СКУД: а правильно ли работает СКУД? Может, где-то люди ходят там, где не должны, или их не пускает где дОлжно? Для контроля за работой СКУД в него внедрена аналитика и самодиагностика, что позволяет сразу дать ответ на вопрос: правильно ли работает СКУД?