СКУД для турникета

Проект начинаем с:

• пикового потока;
• числа полос;
• направлений;
• идентификаторов;
• гостевого процесса;
• anti-passback;
• аварийного поведения.

СКУД может разрешить доступ и открыть створку или планку.

Но пользователь может:

• не пройти;
• передумать;
• пройти в другом направлении;
• попытаться пройти вдвоём.

Поэтому где это важно, используем данные:

• контроллера турникета;
• датчиков прохода;
• направления.

До выбора турникета считаем:

• сколько людей приходит за 5–15 минут;
• сколько входит одновременно;
• есть ли встречный поток;
• сколько времени занимает идентификация;
• сколько гостей.

Система может быть технически исправна и создавать очередь из-за неверно рассчитанной пропускной способности.

Учитываем:

• обычные проходы;
• широкую или доступную полосу;
• гостей;
• доставку;
• крупные предметы;
• служебный проход.

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

Нужно однозначно фиксировать:

• вход;
• выход;
• двустороннюю полосу.

Это влияет на:

• anti-passback;
• число находящихся внутри людей;
• учёт рабочего времени;
• журнал.

Функция запрещает определённые последовательности повторного прохода.

Но включать её без анализа нельзя.

Учитываем:

• несколько входов;
• несколько выходов;
• гостей;
• аварийную разблокировку;
• ручное открытие;
• потерю связи.

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

Для гостей или билетов можно использовать QR при совместимом сканере.

Отдельная страница:

• QR-доступ для гостей в СКУД

На турникете проверяем:

• скорость считывания;
• яркость экрана;
• очередь;
• одноразовую политику;
• направление.

При Face ID или другой биометрии особенно важна скорость идентификации в потоке.

Отдельно:

• Биометрия в системе контроля доступа

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

Гость может:

• заранее получить QR;
• получить временную карту;
• обратиться на стойку;
• быть зарегистрирован сотрудником.

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

Камера может помогать:

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

Но камера не заменяет собственные датчики турникета.

Если нужна интеграция CCTV + СКУД:

• Интеграция СКУД и видеонаблюдения

События вход/выход могут быть источником данных.

Но табель требует:

• графиков;
• смен;
• перерывов;
• командировок;
• исключений.

Турникет не превращает журнал автоматически в корректный табель.

На пути эвакуации турникет должен вести себя согласно проекту и применимым требованиям.

СКУД:

• не должна мешать аварийному выходу;
• не должна переопределять штатный пожарный сценарий.

Тест проводится по согласованной программе.

1. Поток

Пиковые значения.

2. Направления

Вход и выход.

3. Идентификаторы

Карта, QR, биометрия.

4. Гости

Отдельный процесс.

5. Anti-passback

Если нужен.

6. Аварийный режим

Согласованный.

7. Журнал и видео

При необходимости.

8. Нагрузочный тест

Реальный поток.

Проверяем:

• сотрудника;
• запрещённый идентификатор;
• вход;
• выход;
• повторный проход;
• гостя;
• отзыв карты или QR;
• несколько последовательных пользователей;
• журнал;
• аварийный режим по программе испытаний.

• число сотрудников;
• пиковый поток;
• тип турникета;
• число полос;
• существующую СКУД;
• гостевой сценарий;
• QR или биометрию;
• требования к учёту рабочего времени;
• требования по видео.

Anti-passback нужен всегда?

Нет. Только если процесс требует контроля последовательности вход/выход.

Турникет считает людей?

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

Можно QR и карты одновременно?

Да, если контроллер и считыватели поддерживают нужную архитектуру.

Нужна камера?

Если требуется визуальное подтверждение или расследование, но сама СКУД может работать без неё.

Как понять, хватает одной полосы?

По пиковому потоку и времени идентификации, а не по среднему числу сотрудников за день.