Интеграция СКУД с лифтом

До оборудования определяем:

• что именно ограничиваем;
• какие пользователи;
• какие этажи;
• кто обслуживает лифт;
• какой интерфейс предусмотрен производителем;
• что происходит в аварийном режиме.

Ограничение вызова лифта

Пользователь не может вызвать лифт без идентификации.

Ограничение выбора этажа

После входа в кабину пользователь получает доступ только к разрешённым этажам.

Эти схемы могут использоваться:

• отдельно;
• вместе.

Пример:

Это рабочий принцип, а не готовая политика любого здания.

Ключевой этап — определить, как производитель лифтовой системы разрешает внешнее управление доступом.

Возможны:

• релейный модуль;
• специализированный I/O;
• интерфейс контроллера;
• API;
• интеграция с системой назначения лифта по выбранному этажу.

Не подключаем случайные реле в цепи лифта без участия ответственной лифтовой стороны.

В отдельных архитектурах доступ к этажу реализуется через:

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

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

Но это не означает, что такой способ применим к любому современному лифту.

Современные лифты могут назначать кабину ещё до посадки.

Тогда доступ пользователя связан с:

• выбранным этажом;
• системой назначения лифта;
• экраном/терминалом;
• программной интеграцией.

Схема «разорвать кнопку этажа» может быть вообще неприменима.

Место зависит от сценария:

• лифтовой холл;
• турникет;
• кабина;
• этаж;
• терминал назначения лифта по выбранному этажу.

Считыватель — лишь способ идентификации. Основная логика живёт в матрице прав и интерфейсе лифта.

Для гостевого доступа заранее определяем:

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

QR-страница:

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

Что происходит при:

• отсутствии сервера;
• потере сети;
• отказе контроллера;
• потере питания?

Это проектное решение.

СКУД не должна случайно блокировать штатные аварийные/служебные режимы лифта.

Штатная пожарная и аварийная автоматика лифта имеет приоритет.

Интеграция СКУД:

• не отменяет её;
• не переписывает;
• не тестируется без участия ответственных специалистов.

До внедрения нужно вовлечь:

• владельца лифта;
• обслуживающую организацию;
• производителя/авторизованный сервис — где требуется;
• проектировщика.

Без этого можно построить технически работающую, но эксплуатационно неприемлемую схему.

1. Тип лифтовой системы

Обычная схема или назначение лифта по выбранному этажу.

2. Матрица доступа

Пользователь → этаж.

3. Штатный интерфейс

Что разрешено производителем.

4. СКУД

Контроллер/считыватель.

5. Гости

Временные права.

6. Отказные режимы

Сеть/сервер/питание.

7. Совместная приёмка

С лифтовой стороной.

Проверяем:

• пользователь A может на разрешённый этаж;
• запрещённый этаж недоступен;
• пользователь B получает другую матрицу;
• гость — только свой сценарий;
• отозванное право больше не работает;
• аварийный/служебный режим не нарушен;
• журнал СКУД понятен.

• производитель и модель лифтов;
• обслуживающая организация;
• этажность;
• число лифтов;
• существующая СКУД;
• группы пользователей;
• нужные этажи;
• гостевой сценарий.

Можно ограничить только отдельные этажи?

Да, если лифтовая система поддерживает нужный интерфейс.

Можно поставить считыватель в кабине?

В отдельных архитектурах — да, но схема согласуется с лифтовой системой.

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

Для части старых решений — возможно. Для современных систем назначения лифта по выбранному этажу обычно нужен другой подход.

Кто отвечает за пожарный режим?

Он относится к штатной системе здания/лифта и не должен произвольно меняться СКУД-подрядчиком.

Можно дать гостю доступ на один этаж?

Да, если это поддерживается общей архитектурой и гостевой системой.