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

Введение.

В ходе разработки ПО Артонит были сформулированы постулаты, которые и легли в основу и программного, и аппаратного обеспечения:

  • Основная задача СКУД. Если задача не сформулирована, то и решать нечего. От того, как задача сформулирована, зависит и результат. Формализация основной задачи СКУД привело к необходимости создания Абстрактной модели контроллера СКУД.
  • Абстрактная модель контроллера СКУД.

Логика работы программного обеспечения Артонит построена на этих постулатах. Результат - простое, надежное и достаточно универсальное решение, мало зависящие от физического оборудования, от размера системы, от сложности решаемых задача (в рамках СКУД).

Очевидно, что другие формулировки задачи СКУД также позволят получить результат, но про решения в других базисах пусть напишет тот, кто это сделал.


Основная задача СКУД.

Для решения любой задачи необходимо эту задачу формализовать.

Для  СКУД задача ставится следующим образом:

  1. есть точки прохода. Их отличительное свойство - точка прохода может пропустить или не пропустить пользователя.
  2. есть пользователи.
  3. есть некий набор правил прохода, в соответствии с которым пользователь имеет или не имеет право ходить через точки прохода.
  4. необходимо техническими средствами обеспечить реализацию набора правил прохода.

Анализ задачи выявляет несколько любопытных вопросов:

  1. что подразумевается под терминами "пропустить" или "не пропустить"? Совсем не очевидно, что речь идет именно о физическом ограничении прохода.
  2. что есть пользователь? Некое очевидное понимание, что это "человек", вызывает, в свою очередь, ряд других вопросов (а если это не человек, а автомобиль?).

Можно ли попытаться формализовать задачу СКУД, не зная ответов на поставленные вопросы?

Успех решения задачи зависит от правильности выбранных переменных.

Автор предлагает следующие ответы на поставленные вопросы:

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

Т.о., в задаче СКУД появились термины:

Точка прохода - абстрактное устройство, которое может выполнять 2 действия: пускать или не пускать.

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

В рамках выбранных терминов задачу СКУД можно выразить в форме таблицы:

Табличное представление задачи СКУД. Правила прохода.

Door0 Door1 ... DoorN
Key1 + + +
Key2 + - -
Key3 + + -
...
KeyN + - +

Здесь:

Door0, Door1 и т.д. - названия точек прохода.

Key1, Key2 и т.д. - коды карт.

+ означает разрешение на проход через точку прохода.

- означает запрет на проход через точку прохода.

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

В табличной форме отражена вся задача СКУД, и практическая её реализация является задачей разработчиков СКУД.

Обеспечить проход карт пользователей в соответствии с таблицей правил прохода есть основная задача СКУД!

Второстепенные задачи СКУД. Журнал событий.

Обеспечив решение основной задачи СКУД разработчик столкнется с очевидными требованиями:

  1. должна быть система контроля за работой СКУД.
  2. должен быть журнал событий СКУД.
  3. должны быть какие-либо сервисы, связанные с работой СКУД.

Тут необходимо сделать однозначное ограничение: второстепенные задачи СКУД могут входить в общее решение СКУД, но не обязательно.

Резюме:

  1. Основная задача СКУД - пускать или не пускать - однозначно описывается таблице прав прохода.
  2. Есть большое количество второстепенных задач СКУД, которые не входя в основную задачу. Решение этих задач может, но не обязано входить в основной пакет программного обеспечения.

 

Логические сущности основной задачи СКУД.

Выделим логические сущности, наличие которых позволит решать основную задачу СКУД.

Ограничим предметную область:

  1. под точками прохода будем подразумевать устройства типа турникетов, шлагбаумов, дверей с замками и т.п. Их общая характеристика одна: им можно дать сигнал на прохода, т.е. реализовать действие Пропускать. Действие НЕ пропускать реализуется автоматически, по логике устройства точки прохода, которая в исходном состоянии закрыта. Для определенности назовем точки прохода Дверями.
  2. для работы с кодом карты сначала необходимо получить этот код карты. Код карты мы получает от электронных устройств. Для определенности назовем эти устройства "считывателями".
  3. для организации общего взаимодействия используется среда, основанная на передаче, обработке и хранении электрических сигналов.

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

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

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

Сразу же возникают очевидные проблемы:

  1. считыватель и дверь должны быть логически связаны. Очевидно, что код карты, полученный от от считывателя Сч1, должен анализироваться применительно к конкретной двери.
  2. кто-то должен сделать этот анализ: можно ходить или нельзя, и выдать команду на нужную дверь.

Т.о., реальная картина принимает несколько иной вид, и ее отличия таковы:

  1. Считыватели Сч имеют логическую связь с точками прохода Door. При получении кода карты от считывателя Сч система уже должна знать какую именно ячейку таблицы обрабатывать.
  2. появляется система обработки данных и генерации решений, которую назовем валидатор.

Картинка приобретает вид:

Тут:

Контроллер - логическое устройство, в рамках которого определяется связь считывателя и двери. На картинке считывателю Сч1 соответствует дверь Door1. Контроллер обеспечивает взаимодействие с физическими устройствами (считывателямя, замками, другими датчиками).

Валидатор - логическое устройство, которое выполняется проверку валидности кода карты для двери.

Данные от считывателя Сч1 попадают в контроллер. Контроллер по каким-либо настройкам знает, что он привязан к двери Door1. Контроллер передает код карты валидатору, указав, что проверку делать надо для двери Door1.

Валидатор выполняет проверку таблицы прав, и выдает результат валидации в контроллер. В зависимости от результата контроллер выдает (или не выдает) команду управления дверью Door1.

 

Варианты организации контроллера.

В приведенной выше картинке одному считывателю соответствует одна дверь. Могут ли быть более сложные варианты контроллера?

Недолгое размышление дает очевидный ответ на этот вопрос: могут. Приведу некоторые примеры:

Одна дверь на 2 считывателя.

В приведенном примере видно, что для прохода в одну сторону необходимо поднести карту к считывателю Сч1, а для прохода в другую сторону - к считывателю Сч2.

Если ли для таблицы прав прохода разница в количестве подключенных считывателей?

С точки зрения задачи СКУД разницы нет, ибо основная задача решается однозначно (пускать или не пускать).

А вот с точки зрения контроля за работой системы разница есть, ибо контроль потребует дать ответ на вопрос: в какую сторону был проход?

Тут мы наблюдаем интересную взаимосвязь: второстепенные задачи оказывают влияние на основную задачу. Ведь для основной задачи нет разницы к какому считывателю была поднесена карта. Проверка осуществляется по набору данных дверь - код карты, и позволяет однозначно выдать решение. А второстепенная задача - определение направления прохода - требует внести изменения в таблицу прав т.о., чтобы можно было определить направление прохода. Что, задача СКУД сформулирована неправильно?

Нет, задача СКУД сформулирована правильно. Просто предлагаемая конфигурация в задаче СКУД рассматривается как две независимые двери.

По совокупности требований задача оборудования 1 двери двумя считывателями требует следующей организации:

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

Более того, ничто не мешает построить систему с любым количеством входов и выходов, и рассматривать это все как одну дверь.

Шлюз или турникет.

Другая типовая задача - это реализация шлюза.

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

Между дверями Door1 и  Door2 как правило находится замкнутое пространство, и механизм шлюза позволяет более строго контролировать проход пользователей.

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

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

Для основной задачи СКУД шлюз рассматривается как 2 независимые точки прохода. Это позволит на каждую дверь иметь свой список валидных карт.

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

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

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

Резюме:

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

      Способы решения задачи СКУД. Валидатор.

      Табличное представление задачи СКУД определяет и пути решения этой задачи:

    4. выборка кодов карт для каждой двери и загрузка этих кодов в контроллер СКУД.
    5. выборка списка точек прохода и загрузка их в свойства карты.

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

    Проверка по двери. "Классический СКУД".

    Валидатор выполняет проверку для фиксированного значения названия двери. При этом код карты выполняет роль переменной.


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

    Проверка по коду карты. "Метро"

    Валидатор выполняет проверку для фиксированного номера карты. При этом название двери выполняет роль переменной.

    Получив код карты Key2 от считывателя (например, от Сч1), валидатор выполняет проверку по строке Key2. Если точка прохода Doo1 отмечена как разрешенная для прохода, то валидатор выдаст на Door1 команду на открытие двери.

  3. Подобная система реализована в метрополитене.

    Приведенные примеры (один считыватель - одна дверь - один валидатор) следует рассматривать как минимально необходимую конфигурацию.

    Ничто не мешает рассматривать более сложные структуры, когда один валидатор обслуживает несколько считывателей и несколько дверей. Отсюда следует неочевидный вывод, что всю систему СКУД можно рассматривать как один контролер с одним валидатором и многими считывателями и дверями.

    Резюме:

  4. их формулировки основной задачи СКУД видны 2 базовых пути ее решения.
    1. "Сканирование" таблицы по вертикали и загрузка в контроллеры список карт для обслуживаемой точки прохода.
    2. "Сканирование" таблицы по горизонтали, запись в карту список разрешенных точек прохода.

Основные и дополнительные условия валидации. Место валидатора в СКУД.

Глагол "валидация" следует рассматривать как производное от английского глагола to validate, что переводится как "делать действительным", "признавать имеющим силу".
Код карты считается валидным, если выполнены все условия проверки.

 

Главное условие валидации.

В рамках модели СКУД карта считается валидной, если выполнены основное и дополнительное условие валидации.
Основное условие валидации – наличие карты в списке прохода через дверь.

Очевидно, что если не выполнено основное условие валидации, то остальные условия проверять не имеет смысла.

Дополнительное условие валидации.

Дополнительные условия валидации выполняются после успешного выполнения главного условия и подразумевают под собой разного рода дополнительные проверки.

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

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

Рассмотрим способы взаимодействия контроллеров, валидаторов и основной задачи СКУД.

Место валидатора в СКУД. Один валидатор, много контроллеров.

Оборудование (считыватели, двери,турникеты) подключены к контроллерам.

Поток данных от контроллеров поступает в валидатор, единый на всю систему.

Валидатор имеет доступ к таблице СКУД.

Получив событие или запрос от контроллера, на основании данных код карты - дверь валидатор выполняет проверку (валидацию) по таблице СКУД.

Вариант валидации (по двери или по карте) выбирается исходя из наибольшего быстродействия.

Место валидатора в СКУД. Валидатор на каждый контроллер.

Оборудование (считыватели, двери,турникеты) подключены к контроллерам.

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

Каждый валидатор имеет доступ к таблице СКУД.

Получив событие или запрос от контроллера, на основании данных код карты - дверь валидатор выполняет проверку (валидацию) по таблице СКУД.

Вариант валидации (по двери или по карте) выбирается исходя из наибольшего быстродействия.

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

Необходимо отметить, что возможен и такой вариант реализации системы:

Оборудование (считыватели, двери,турникеты) подключены к одному контроллеру.

Поток данных от контроллера поступает в валидатор.

Валидатор имеет доступ к таблице СКУД.

Получив событие или запрос от контроллера, на основании данных код карты - дверь валидатор выполняет проверку (валидацию) по таблице СКУД.

Вариант валидации (по двери или по карте) выбирается исходя из наибольшего быстродействия.

 

Резюме:

  1. Процесс валидации является одним из базовых процессов при работе СКУД.
  2. Процесс валидации может быть сколько угодно сложным.


От анализа к синтезу. Тупик? Взлетаем!

Анализ задачи СКУД выделил нам ряд очевидных сущностей:

  1. основная задача СКУД как таблица,
  2. валидатор как механизм принятия решения,
  3. контроллер как устройство работы с внешним оборудованием.

Как же на основании этих сущностей сделать шаг к практической реализации задачи СКУД?

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

Задачу СКУД (в силу очевидности) можно реализовать в любой СУБД или даже в файле.

А как же быть с валидаторами и контроллерами?

Имеющиеся реальные модели контроллеров СКУД в целом похожи на то, что описано выше, но у каждого свои нюансы, свои проблемы.

ТУПИК!

Для выхода из тупика нам следует рассматривать не конкретные модели контроллеров СКУД, а обратиться к Абстрактной моделе контроллера СКУД.

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

А задача реализация СКУД приобрела вид:

Рассматривая ранее варианты валидации, я отметил вариант Проверка по двери.

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

Как обеспечить валидатору доступ к данным, необходимым для его работы? Очевидны два варианта:

  1. Вариант 1. Передать валидатору данные, необходимые для его работы (т.е. загрузить список карт в контроллер).
  2. Вариант 2. Предоставить валидатору доступ к данным таблицы СКУД (и тут тоже есть свои варианты).

Вариант 1. Загрузка карт в контроллер.

Методика его реализации становится очевидной:

  1. выбрать из таблицы основной задачи СКУД список карт для каждой двери.
  2. передать каждую карту в контроллер СКУД.
  3. выполнить пп. 1-2 для каждого контроллера.

Все!

Изучив свойства Абстрактной модели контроллера СКУД этот процесс можно расписать буквально по шагам:

Надо отметить, что:

  1. выборку данных, подготовку команд и их передачу контроллеру можно реализовать в одном шаге,
  2. т.к. контроллер дает ответы на команды (OK/Err), то процесс процесс загрузки данных в контроллер становится 100% контролируемым.
  3. в приведенном примере описан вариант передачи основного условия валидации (код карты); необходимо осуществить еще и передачу дополнительных данных.
  4. описанный процесс не зависит ни от способа реализации таблицы СКУД, ни от канала связи с контроллером, ни от длины кода карты (он рассматривается как константа).

Вариант 2. Доступ валидатора к внешним данным.

В этом варианте валидатор имеет доступ к данным основной задаче СКУД (либо к ее производным).

Резюме:

Использование абстрактной модели СКУД позволяет:

  1. найти решение общей задачи СКУД.
  2. формализовать процесс управления.
  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.    Использование оборудование различных производителей в рамках одной системы, что позволит включать в систему уже установленное оборудование.

 


 

Абстрактная модель программного обеспечения СКУД.

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

В результате абстрактная модель программного обеспечения СКУД имеет такой вид:




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


От теории - к практике! 2020 год!

Пояснение автора.

Этот раздел написан 3 апреля 2020 г, через 7 лет после публикации первых разделов.

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

Per aspera ad astra

Пришла пора рассмотреть вопрос: а как же теория реализуется на практике?

Ниже я даю ответ на этот вопрос.

Шаг 1. Связь базы данных, абстрактного драйвера и физического драйвера.

База СКУД - основное хранилище всей информации.

Набор прав хранится в таблице cardidx. Cardidx - это реальное название таблицы в базе данных СКУД ShieldPro.gdb.

Карты для Door1 должны ходить через точку прохода Door1А, работающей под управлением Контролера А.

Карты для Doorr2 должны ходить через точку прохода Door1Б, работающей под управлением Контролера Б.

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

и т.д. для все точек прохода.

Тут же, в БД СКУД, хранится журнал событий, в котором фиксируются все события (таблица Events).

Двери Door1А, Door1Б, Door1В и соответствующие им считыватели подключены к Контроллерам А, Б и В.

Как же решить задачу СКУД?

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

Задача СКУД решена: в каждой точке прохода пройдут только те карты, которым там можно ходить.

Шаг 2. Удаление и добавление карт, изменение прав карт. Таблица изменений.

Таблица прав постоянно меняется.

Пришел новый сотрудник - ему выдали карту.

Уволился сотрудник - карту удалили.

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

Задача очевидна, но как её реализовать на практике?

Вариантов несколько. В программном обеспечении Артонит 10 это решено исходя из следующих предпосылок:

  1. Декларируется, что в таблице прав хранятся только актуальные данные. Если карта удалена, то её кода не должно быть в таблице cardidx. Если точка прохода удалена или неактивна - её не должно быть в таблице cardidx.
  2. Связь с контроллером не гарантирована. Удалить карту из таблицы прав cardidx мало, надо обеспечить удаление карты и из контроллера. Причем в момент удаления карты из таблицы прав cardidx связи с контроллером может и не быть. Из этого следует, что нельзя просто так удалить номер карты из базы данных. Надо удостовериться, что карта удалена и из контроллера, и только после этого удалять карту из базы данных СКУД.
  3. Связь с контроллером рано или поздно может восстановиться, и надо внести изменения за период, пока не было связи.
  4. СКУД может быть сконфигурирован вообще без физического оборудования. Такая ситуация характерна при первичной настройке: оборудование еще не установлено, но оператор СКУД уже может регистрировать карты, создавать категории доступа.
В Артонит 10 это реализовано следующим образом:
  1. все изменения в таблице прав cardidx фиксируются  в таблице изменений cardindev. ВНИМАНИЕ! Это важный момент: таблица cardindev фиксирует все изменения таблицы прав. В очереди последовательно, по мере изменения прав, формируется набор команд на запись и удаление карт в каждый контроллер.
  2. драйвера устройств опрашивают не таблицу прав cardidx, а очередь команд cardindev. Если карту надо записать в контроллера, то формируется команда writekey, если надо удалить карту, то формируеутся команда deletekey.
Теперь архитектура выглядит таким образом:


Каждый драйвер обращается не к таблице прав cardidx, а обрабатываетм очередь команд cardindev, поочередно выполняя команды на запись или удаление карт в контроллеры.
Если команда выпонена успешно, то драйвер удаляет строку с командой из очереди.
Если команда выполнена неуспешно, то драйвер делает отметку о неудачной попытке выполнить команду. Через некоторое время драйвер опять попробует выполнить команду: вдруг связь с контроллером восстановилась.
Т.о., при штатной работе СКУД мы получаем последовательную цепочку событий:
  1. оператор СКУД выдает или удаляет карты,
  2. база данных отслеживает все изменения и формирует очередь команд на удаление и запись карт в контроллеры,
  3. драйверы контроллеров периодически опрашивают очередь команд. Если находят команду - тут же её выполняют.
  4. если все команды выполнены успешно, то очередь команда пуста. Пустая очередь - хороший признак штатной работы.
  5. если очередь команд не пуста - необходимо проверять аппаратную часть, выяснить почему команда не выполнена.

Шаг 3. Должен ли драйвер "ходить" к базе данных? Требования к драйверу.

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

  1. есть необходимость обеспечить работу контроллеров серии Артонит не только в рамках программного обеспечения СКУД Артонит 10, но и других программ. Чтобы реализовать основную задачу СКУД достаточно записывать/удалять карты из контроллера. Если этим захочет заниматься кто-то другой (какая-то другая программа), то хорошо бы тем разработчикам не тратить время на изучение протоколов обмена, а сразу писать/удалять карты (используя команды writekey и deleyekey). А это значит, что драйвер (а правильнее сказать "программная компонента") должна вызываться внешней программой. Внешняя программа сама решит что именно надо записывать и удалять, вызовет программную компоненту Artonit2.dll, передаст туда команду, получит ответ и будет сама решать что делать дальше. Для выполнения команды надо знать только саму команду, и адрес контроллера (строку подключения).
  2. программное обеспечение Артонит 10 задумывалось как универсальное, допускающее изменение в ходе своего развития. Если драйвера будут напрямую обращаться к базе данных, то при измении базы данных придется менять все драйвера.
  3. в программном обеспечении Артонит 10 будут работать не только контролеры Артонит, но и контроллеры других производителей. Очевидно, что под контроллеры других производителей надо будет писать свой драйвер. "Притягивать" эти новые драйвера к существующей базе данных - очень опасный путь (см. п.2).
  4. СУБД базы данных Артонит 10 может измениться. Сегодня мы используем FireBird, завтра может быть другая база. Не переделывать же драйвер под каждую СУБД.
В результате драйвер приобрел следующие свойства:
  1. драйвер выполнен как COM-объект.
  2. драйвер реализует всю систему команд контроллера Артонит, команды передаются в формате ASCII.
  3. Драйвер реализует команды абстрактного драйвера СКУД, преобразуя их в команды контроллера.
  4. для связи с контроллером драйверу необходимо передать строку подключения к контроллеру. Драйвер обязан сам контролировать состояние соединения с контроллером.
  5. драйвер сам выбирает события из контроллера и передает их как свойство драйвера. Это позволяет программному обеспечению более высокого уровня не заботиться о сборе событий. При возникновении события драйвер передаст его без дополнительных запросов.

Шаг 4. Транспортный сервер. АСервер.

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

  1. необходимо сразу реализовать возможность создавать территориально распределенные системы: база данных в Москве, а филиалы в разных городах России.
  2. контроль за работой системы. Надо понимать, как система работает, что в ней происходит, видеть сбои и ошибки. Для этого необходимы лог-файлы, а еще лучше один лог-файл.
  3. контроллеры могут меняться, но система должна работать с любыми контроллерами.
В результате указанных требований архитектура СКУД приобрела вид:
В архитектура появились две новые сущности:ТСервер, от сокращения Транспортный сервер, и АСервер. Акроним АСервер не имеет расшифровки, буква А взята как первая буква алфавита. Первая буква - Первая, главная программа.
ТСевер выполнен как служба. При старте ТСервер запускает все зарегистрированные в нем драйвера. Каждый драйвер получает строку подключения к своему контроллеру, устанавливает с ним связь.
ТСервер ничего не знает о СКУД. Он обеспечивает:
  1. запуск драйверов,
  2. передачу в драйвер команд от внешних клиентов.
АСервер выполнен как служба. При старте он берет настройки за реестра и подключается к базе данных, получает список транспортных серверов и подключается к ним.
Именно АСервер обрабатывает очередь команд cardidx, формирует команды writekey и deletekey и передает их в Транспортный сервер. При формировании команды АСервер "видит" в какой транспортный сервер надо послать команду и какому именно контроллеру.
Реальная команда записи карты выглядит таким образом:
Command destination: "м5, м3/1, л29/3"; device: "л293 шлг ур1 к04"; Command: writekey cell=8, key="018424001A", TZ=1, status=0, door=1
Тут: "м5, м3/1, л29/3" -  название транспортного сервера, где находится контроллер.
device: "л293 шлг ур1 к04" - название контроллера, которому передается команда. Это очень важная особенность: в БД СКУД хранятся названия контроллеров!
Command: writekey cell=8, key="018424001A", TZ=1, status=0, door=1 - а это уже сама команда на запись карты к канал door=0

Транспортный сервер с именем м5, м3/1, л29/3" принимает команду и передает её контроллеру с именем, "л293 шлг ур1 к04".
Драйвер получает команду, выполняет её и передает ответ в ТСервер. ТСервер передает ответ АСерверу.
АСервер либо удаляется команду из очереди (при успешном выполнении), либо оставляет команду в очереди (при неуспешном выполнении).
полный обмен (команда - ответ) имеют вид:
03.04.2020 7:58:24 :     Command destination: "м5, м3/1, л29/3"; device: "л293 шлг ур1 к04"; Command: writekey cell=8, key="018424001A", TZ=1, status=0, door=1
03.04.2020 7:58:25 :     Answer destination: "м5, м3/1, л29/3"; device: "л293 шлг ур1 к04"; Command: writekey cell=8, key="018424001A", TZ=1, status=0, door=1; Answer: "OK "
А вот пример неудачного выполнения команды:
03.04.2020 8:15:41 :     Command destination: "м5, м3/1, л29/3"; device: "л293 шлг ур1 к04"; Command: writekey cell=1131, key="7E86B8001A", TZ=1, status=0, door=1
03.04.2020 8:15:42 :     Answer destination: "м5, м3/1, л29/3"; device: "л293 шлг ур1 к04"; Command: writekey cell=1131, key="7E86B8001A", TZ=1, status=0, door=1; Answer: "ERR ErrClass=DeviceError, ErrDesc=""UDP recv() error."", ErrSource=""л293 шлг ур1 к04"""
В ответ на команду записи карты приходит ответ ERR с пояснением, что имеет ошибка приема UDP. Ясно: контроллера нет на связи.
Приведенные примеры - это лог-файл АСервера. В лог-файле видна работы и проблемы всей системы, что и требуется при повседневной эксплуатации.

Резюме.

В этом разделе показано, как на основе теоретических предпосылок создана и работает система контроля доступа Артонит 10.

Система успешно и стабильно работает с 2010 г.

За это время в состав системы были добавлены контроллеры серии Артонит, ZKTeco, организована работа со сканерами штрих-кода, системы распознавания государственных регистрационных знаков.

Все это было сделано путем развития драйверов, с минимальными изменениями базы данных, без остановки работы СКУД (или замены её на новый вариант).

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

По мере роста размеров объектов актуальным стал контроль за работой самой СКУД: а правильно ли работает СКУД? Может, где-то люди ходят там, где не должны, или их не пускает где дОлжно? Для контроля за работой СКУД в него внедрена аналитика и самодиагностика, что позволяет сразу дать ответ на вопрос: правильно ли работает СКУД?