|
Страница 9 из 9
От теории - к практике! 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 это решено исходя из следующих предпосылок:
- Декларируется, что в таблице прав хранятся только актуальные данные. Если карта удалена, то её кода не должно быть в таблице cardidx. Если точка прохода удалена или неактивна - её не должно быть в таблице cardidx.
- Связь с контроллером не гарантирована. Удалить карту из таблицы прав cardidx мало, надо обеспечить удаление карты и из контроллера. Причем в момент удаления карты из таблицы прав cardidx связи с контроллером может и не быть. Из этого следует, что нельзя просто так удалить номер карты из базы данных. Надо удостовериться, что карта удалена и из контроллера, и только после этого удалять карту из базы данных СКУД.
- Связь с контроллером рано или поздно может восстановиться, и надо внести изменения за период, пока не было связи.
- СКУД может быть сконфигурирован вообще без физического оборудования. Такая ситуация характерна при первичной настройке: оборудование еще не установлено, но оператор СКУД уже может регистрировать карты, создавать категории доступа.
В Артонит 10 это реализовано следующим образом:
- все изменения в таблице прав cardidx фиксируются в таблице изменений cardindev. ВНИМАНИЕ! Это важный момент: таблица cardindev фиксирует все изменения таблицы прав. В очереди последовательно, по мере изменения прав, формируется набор команд на запись и удаление карт в каждый контроллер.
- драйвера устройств опрашивают не таблицу прав cardidx, а очередь команд cardindev. Если карту надо записать в контроллера, то формируется команда writekey, если надо удалить карту, то формируеутся команда deletekey.
Теперь архитектура выглядит таким образом:
 Каждый драйвер обращается не к таблице прав cardidx, а обрабатываетм очередь команд cardindev, поочередно выполняя команды на запись или удаление карт в контроллеры. Если команда выпонена успешно, то драйвер удаляет строку с командой из очереди.
Если команда выполнена неуспешно, то драйвер делает отметку о неудачной попытке выполнить команду. Через некоторое время драйвер опять попробует выполнить команду: вдруг связь с контроллером восстановилась.
Т.о., при штатной работе СКУД мы получаем последовательную цепочку событий:
- оператор СКУД выдает или удаляет карты,
- база данных отслеживает все изменения и формирует очередь команд на удаление и запись карт в контроллеры,
- драйверы контроллеров периодически опрашивают очередь команд. Если находят команду - тут же её выполняют.
- если все команды выполнены успешно, то очередь команда пуста. Пустая очередь - хороший признак штатной работы.
- если очередь команд не пуста - необходимо проверять аппаратную часть, выяснить почему команда не выполнена.
Шаг 3. Должен ли драйвер "ходить" к базе данных? Требования к драйверу.
Идея прямого подключения драйвера к базе данных вполне работоспособна, но тут впору вспомнить о ряде дополнительных требований:
- есть необходимость обеспечить работу контроллеров серии Артонит не только в рамках программного обеспечения СКУД Артонит 10, но и других программ. Чтобы реализовать основную задачу СКУД достаточно записывать/удалять карты из контроллера. Если этим захочет заниматься кто-то другой (какая-то другая программа), то хорошо бы тем разработчикам не тратить время на изучение протоколов обмена, а сразу писать/удалять карты (используя команды writekey и deleyekey). А это значит, что драйвер (а правильнее сказать "программная компонента") должна вызываться внешней программой. Внешняя программа сама решит что именно надо записывать и удалять, вызовет программную компоненту Artonit2.dll, передаст туда команду, получит ответ и будет сама решать что делать дальше. Для выполнения команды надо знать только саму команду, и адрес контроллера (строку подключения).
- программное обеспечение Артонит 10 задумывалось как универсальное, допускающее изменение в ходе своего развития. Если драйвера будут напрямую обращаться к базе данных, то при измении базы данных придется менять все драйвера.
- в программном обеспечении Артонит 10 будут работать не только контролеры Артонит, но и контроллеры других производителей. Очевидно, что под контроллеры других производителей надо будет писать свой драйвер. "Притягивать" эти новые драйвера к существующей базе данных - очень опасный путь (см. п.2).
- СУБД базы данных Артонит 10 может измениться. Сегодня мы используем FireBird, завтра может быть другая база. Не переделывать же драйвер под каждую СУБД.
В результате драйвер приобрел следующие свойства:
- драйвер выполнен как COM-объект.
- драйвер реализует всю систему команд контроллера Артонит, команды передаются в формате ASCII.
- Драйвер реализует команды абстрактного драйвера СКУД, преобразуя их в команды контроллера.
- для связи с контроллером драйверу необходимо передать строку подключения к контроллеру. Драйвер обязан сам контролировать состояние соединения с контроллером.
- драйвер сам выбирает события из контроллера и передает их как свойство драйвера. Это позволяет программному обеспечению более высокого уровня не заботиться о сборе событий. При возникновении события драйвер передаст его без дополнительных запросов.
Шаг 4. Транспортный сервер. АСервер.
Дополнительные требования к СКУД:
- необходимо сразу реализовать возможность создавать территориально распределенные системы: база данных в Москве, а филиалы в разных городах России.
- контроль за работой системы. Надо понимать, как система работает, что в ней происходит, видеть сбои и ошибки. Для этого необходимы лог-файлы, а еще лучше один лог-файл.
- контроллеры могут меняться, но система должна работать с любыми контроллерами.
В результате указанных требований архитектура СКУД приобрела вид:
В архитектура появились две новые сущности:ТСервер, от сокращения Транспортный сервер, и АСервер. Акроним АСервер не имеет расшифровки, буква А взята как первая буква алфавита. Первая буква - Первая, главная программа.
ТСевер выполнен как служба. При старте ТСервер запускает все зарегистрированные в нем драйвера. Каждый драйвер получает строку подключения к своему контроллеру, устанавливает с ним связь.
ТСервер ничего не знает о СКУД. Он обеспечивает:
- запуск драйверов,
- передачу в драйвер команд от внешних клиентов.
АСервер выполнен как служба. При старте он берет настройки за реестра и подключается к базе данных, получает список транспортных серверов и подключается к ним.
Именно АСервер обрабатывает очередь команд 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, организована работа со сканерами штрих-кода, системы распознавания государственных регистрационных знаков.
Все это было сделано путем развития драйверов, с минимальными изменениями базы данных, без остановки работы СКУД (или замены её на новый вариант).
В ходе эволюции драйвер взял на себя обязанности валидатора (и имеет прямое подключение к базе данных СКУД) и обеспечивает обработку кодов карт в режиме он-лайн.
По мере роста размеров объектов актуальным стал контроль за работой самой СКУД: а правильно ли работает СКУД? Может, где-то люди ходят там, где не должны, или их не пускает где дОлжно? Для контроля за работой СКУД в него внедрена аналитика и самодиагностика, что позволяет сразу дать ответ на вопрос: правильно ли работает СКУД?
|
Библиотека 
