Show content

СКУД. Знать, что хочет заказчик

Форум Системы безопасности / Форум Системы контроля доступа /

09.10.2016 22:17:14

4 мин 06 сек: "Скорость обновления".

10.10.2016 11:22:28

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

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

Все это еще зачастую происходит в условиях стесненных аппаратных ресурсов на контроллере.

Было бы интересно узнать кто как технически решает эту задачу.

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

10.10.2016 20:20:32

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

А что, вы тоже блоками карты грузите?

Загрузка (и удаление) карт по одной вообще исключает появление описанных вами проблем.

Так и решаем: сорок раз по разу.

10.10.2016 22:47:43

>; Загрузка (и удаление) карт по одной вообще исключает появление описанных вами проблем.

Интересно, поясните. Если можно, хочу прямо жесткого технического разговора.

Как вы храните данные в памяти контроллера, чтобы он быстро отрабатывал команду добавления одной карты? и при этом не протирать дырку во flash, поддерживать такую структуру данных чтобы в ней быстро искать и прочее описанное мной выше. Чем и в каком объеме пришлось пожертвовать?

>; Модельный ряд 10-ти летней давности в случае работы с базой в 100К ключей прямой путь на паперть

Если вы намекаете на нас, то вот и хрен вам :)

Наши пользователи с контроллерами 10-и летней давности сейчас могут установить бесплатно обновление, и в числе 1000 новых функций у них будут моментально добавляться ключи в базу 100К.

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

Кстати, плюс ко всему это еще и "блоками", т.е. не по одной карте пишется.

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

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

Мне это правда очень запомнилось все, я реализовался как инженер тогда по полной :)

>; ассиметричный дизайн

Что это такое?

11.10.2016 22:24:56

Интересно, поясните. Если можно, хочу прямо жесткого технического разговора

В чем вопрос то?

Структура данных - примерно как в БД. Ячейка с уникальным id, в которой хранится номер карты и ссылка на временные зоны для каждой из дверей.

Набор временных зон храниться отдельно.

ОСнова системы команд - набор команд вида writekey и deletekey.

Вот пример команды на запись карты:

writekey door=0, key="9D3569", TZ=1, status=0

вот ответ на эту команду:

Answer: "OK Cell=348"

Видно, что карта была записана в ячейку с номером 348.

Могу прочитать данные из ячейке

readkey door=0, cell=348

либо запросить данные по карте

readkey door=0, key="9D3569"

В обоих случаях в ответ получу такой ответ:

OK Cell=348, Key="9D3569", Access=Yes, TZ=0x0001

Что означает карта с номером 9D3569 лежит в ячейке с номером 348. В door=0 проход разрешен (Access=Yes), набор временных зон для этой двери TZ=0x0001.

Вот и вся премудрость.

Список команд контроллера лежит в свободном доступе. Так что СКУД можно сделать хоть в экселе: формируй команду да высылай в указанный IP (есть драйвер - COM-объект).

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

Вот как-то так... Я удовлетворил Ваше любопытство?

Насчет дырок во flash-памяти.

Во первых (и это самое главное) - в микросхеме памяти стоит свой контроллеры, выравнивающий нагрузку на ячейки.

Во-вторых, в масштабах работы контроллера количество записей, которые микросхема переживает за 10-15 лет службы контроллера, является просто ничтожным.

В-третьих, массовое применение SSD в последние годы показало, что проблема "износа" ячеек памяти стоит в конце длинного списка других причин отказов.

12.10.2016 15:10:01

Странные ограничения видны: до 240 групп... до 63 контроллеров... Зачем это? Может кто-нибудь объяснить? Просто любопытно.
Ограничение Elsys-MB-NET до 63 контроллеров на линии обусловлено нагрузочной способностью 485 интерфейса . 240 групп-всего лишь программное ограничение, можно сделать сколько угодно.

13.10.2016 09:32:03

Андрей, а как вы потом ищете по этой базе на контроллере? Просто перебором?

Можете сказать какая микросхема памяти у вас используется?

13.10.2016 13:33:55

Если покопаюсь в документации, то, скорее всего, найду маркировку.

Только надо ли?

13.10.2016 13:34:53

Заказчик желает знать, конкретно по СКУД Сфинкс:

- При занесении/исправлении нового сотрудника разве нельзя не перезаписывать инфу к не относящимся контроллерам?

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

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

- Когда появятся контроллеры в корпусе на DIN-рейку?

- Когда в модуле ПО «Реакция на события» появится функция “маячок” в виде отдельного всплывающего окна при проходе обозначенного человека/людей на любой/выбранной точке доступа?

13.10.2016 13:43:59

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

У нас минимальный набор данных - просто номер карты. Как следствие, и минимальный набор операций для этого набора данных - записать да удалить карту. Все остальные данные (временные зоны, праздники, статусы разные) - это уже расширения базовой модели.

У Вас же набор данных более сложный. Как следствие, и загрузить можно только весь набор. Скорее всего, у вашего контроллера нет операции вида Добавить карту/удалить карту...

У нас - сорок раз по разу. У Вас - один раз на сорок раз...