СКУД Артонит

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

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

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