Архитектура интеграции ODNFC-LAN с 1С

Статус материала. Проектная схема. Готового модуля 1С нет: для внедрения нужны разработка и испытания.

Если нужно только ввести номер карты в открытое поле 1С, начните с ODRFID в режиме USB-клавиатуры. Описанная ниже схема решает другую задачу — обмен правами и событиями — и требует разработки прикладной программы и модуля на стороне 1С.

ODNFC-LAN можно связать с 1С:ЗУП, 1С:ERP или собственной конфигурацией по HTTPS с данными в JSON. Но 1С не должна отвечать на каждый запрос карты в реальном времени. Считыватель проверяет право по локальной копии правил, сразу управляет замком и сохраняет событие. Синхронизация с 1С происходит отдельно и не задерживает проход.

Так система продолжит открывать дверь по последней принятой политике, если сеть или 1С временно недоступны. После восстановления связи накопленные события можно передать повторно без потери и двойного учёта.

Что предполагается интегрировать

Ниже рассматривается ODNFC как часть системы контроля и управления доступом (СКУД). В 1С хранятся сотрудники, назначенные им карты и правила доступа, а от считывателей приходят события разрешения и отказа в доступе.

Чтение карты и команда открытия замка не подтверждают, что человек прошёл. Если учёту нужен именно факт прохода, предусмотрите отдельное подтверждение от оборудования точки доступа.

Обмен состоит из двух независимых потоков:

• 1С → ODNFC: привязки карт, группы доступа, расписания, зоны и сроки действия прав;
• ODNFC → 1С: разрешённые и запрещённые проходы, направление, состояние контроллера и версия политики, по которой принято решение.

Конкретный набор данных зависит от конфигурации 1С и правил объекта. Например, в небольшой системе может быть достаточно UID, сотрудника и срока действия пропуска. Для нескольких зон понадобятся группы, расписания и правила переходов между зонами.

1С не участвует в открытии двери

Синхронная схема выглядит просто: считыватель получает UID, отправляет его в 1С, ждёт ответа и только затем открывает замок. На практике она связывает доступность двери с сетью, публикацией базы 1С, регламентными работами и временем ответа сервера.

В предлагаемой схеме цикл короче:

1. ODNFC считывает UID или данные из памяти поддерживаемой метки.
2. Локальная программа находит идентификатор в кэше прав.
3. Программа проверяет срок действия, расписание и правила этой точки.
4. При разрешении ODNFC включает выход замка на заданное время.
5. Результат записывается в постоянную очередь событий.
6. Отдельная задача передаёт очередь в 1С или интеграционный шлюз.

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

Компоненты системы

          1С:ЗУП / 1С:ERP / собственная конфигурация
                   расширение ODNFCIntegration
                            ⇅ HTTPS/JSON
                 интеграционный шлюз и журнал
                    ⇙                       ⇘
          ODNFC-LAN по HTTPS       ODNFC-RS485 по Modbus RTU
                    \                       /
             локальные права и управление замком

Для пилота с несколькими ODNFC-LAN отдельный шлюз можно не устанавливать: считыватели сами отправляют события в HTTP-сервис 1С и забирают обновления. Шлюз становится особенно полезен, когда:

• используются ODNFC-RS485;
• устройств много и нужен единый журнал их состояния;
• 1С нельзя публиковать непосредственно в сети контроллеров;
• нужны единые повторы, очередь, сертификаты и ротация ключей;
• 1С должна опрашивать один узел, а не каждый считыватель.

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

Почему для обмена подходит HTTPS и JSON

Платформа 1С позволяет создать собственный ресурсный HTTP-сервис: выбрать методы, прочитать тело и заголовки запроса и сформировать произвольный ответ. Это даёт возможность зафиксировать небольшой контракт, который не зависит от внутренних имён справочников и регистров конкретной конфигурации.

Логику интеграции целесообразно вынести в расширение ODNFCIntegration. Расширения 1С предназначены для доработки прикладного решения без изменения основной конфигурации. Возможность использовать расширение и порядок его обновления всё равно нужно проверить на конкретной версии ЗУП, ERP или отраслевого решения.

Возможны два направления обмена:

1. ODNFC-LAN или шлюз отправляет события в опубликованный адрес 1С, например /base/hs/odnfc/v1/events/batch, и периодически запрашивает новую политику.
2. Если входящий сервис 1С публиковать нельзя, регламентное задание 1С опрашивает шлюз как HTTPS-клиент. Платформа поддерживает исходящие HTTP- и HTTPS-запросы.

Стандартный интерфейс OData тоже может передавать JSON и изменять объекты 1С. Для контроллера доступа он менее удобен: устройство будет связано со структурой конкретной конфигурации, а техническому пользователю придётся открыть доступ к прикладным объектам. Собственный HTTP-сервис позволяет выдать более узкие права и сохранить один контракт при изменении внутренней модели 1С.

Внешняя компонента 1С нужна в другом сценарии: когда настольный считыватель работает как периферия открытого рабочего места 1С. Для автономной двери, которая должна работать без запущенной формы, такой способ не решает задачу локального доступа.

Минимальный HTTP-контракт

Контракт лучше версионировать с первого дня. Пример пакета событий:

{
  "schema": 1,
  "device_id": "ODNFC-AABBCCDDEEFF",
  "events": [
    {
      "event_id": "ODNFC-AABBCCDDEEFF:f91c32:1842",
      "occurred_at": "2026-08-23T09:21:44Z",
      "clock_valid": true,
      "reader": "hf",
      "uid": "04A1B2C3D4",
      "direction": "in",
      "decision": "allow",
      "reason": "policy",
      "policy_version": 42
    }
  ]
}

Ответ сервера:

{
  "accepted": ["ODNFC-AABBCCDDEEFF:f91c32:1842"],
  "policy_version": 43,
  "server_time": "2026-08-23T09:21:45Z"
}

Для первой версии достаточно четырёх операций:

• POST /v1/events/batch — передать пакет событий и состояние устройства;
• GET /v1/policy/{deviceId}?version=42 — получить новый атомарный снимок прав, если версия изменилась;
• POST /v1/policy/{deviceId}/ack — подтвердить успешное применение снимка;
• GET /v1/status/{deviceId} — прочитать диагностику через шлюз, если она нужна службе эксплуатации.

Названия методов — проектный пример. До разработки нужно зафиксировать JSON Schema, допустимые размеры пакетов, коды HTTP-ответов, максимальные тайм-ауты и правила совместимости версий.

Повтор события не должен создавать второй проход

Устройство не может достоверно узнать, обработал ли сервер запрос, если ответ потерялся после записи события в 1С. Поэтому доставка строится по принципу «не менее одного раза»:

1. ODNFC сохраняет событие с уникальным event_id до отправки.
2. Сервер записывает новый идентификатор либо распознаёт дубликат.
3. И новый, и уже принятый идентификатор попадают в массив accepted.
4. Устройство удаляет запись из очереди только после подтверждения.

Повтор одного event_id обязан давать тот же результат и не создавать вторую строку прохода. Размер очереди ограничивают заранее, а при её заполнении поднимают диагностическое событие. Не подтверждённые записи не стирайте молча.

Политика обновляется целиком

Права лучше передавать не последовательностью отдельных команд «добавить/удалить», а версионированным снимком для конкретной точки. ODNFC или шлюз сначала сохраняет новый набор отдельно, проверяет формат, размер и контрольную сумму, затем одним действием делает его активным. Если питание пропало во время загрузки, рабочей остаётся предыдущая подтверждённая версия.

В событии указывается policy_version. Тогда в 1С можно увидеть, по каким правилам был разрешён или запрещён конкретный проход.

Сырые проходы — ещё не табель

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

Поэтому 1С сначала сохраняет неизменённые события интеграции. Отдельное регламентное задание группирует их в интервалы присутствия, отмечает спорные случаи и только затем передаёт результат в механизм учёта времени выбранной конфигурации.

Так кадровый учёт не зависит от формата прошивки, а сырые данные остаются для повторного расчёта и разбора ошибок. Похожее разделение кадровых событий, прав доступа и проходов описано в опубликованном примере интеграции 1С:ЗУП и СКУД.

Что хранить в расширении 1С

Минимальная модель расширения может включать:

• справочник контроллеров и точек прохода;
• регистр привязок UID ↔ сотрудник или физическое лицо;
• регистр прав, расписаний и версий политик;
• регистр сырых событий с контролем уникальности event_id;
• журнал обмена и диагностических ошибок;
• HTTP-сервис и отдельную роль технического пользователя;
• регламентное задание формирования интервалов присутствия.

Сырые события лучше не записывать сразу в типовые документы ЗУП или ERP. Отдельный интеграционный слой изолирует контракт ODNFC от изменений объектов конкретной конфигурации и позволяет повторить обработку после исправления правил.

Что есть в ODNFC и что нужно разработать

В прошивке ODNFC на Lua есть обработчик считанного UID, потоки, JSON и HTTP-клиент с POST, тайм-аутами, постоянным соединением и проверкой сертификата. Их API описан в разделах сеть на Lua и программирование ODNFC.

Готового модуля обмена с 1С нет. Для пилота нужно разработать и проверить как минимум следующие части:

• вынести сетевой обмен в отдельную задачу, чтобы HTTP-тайм-аут не задерживал чтение карты и управление замком;
• добавить ограниченный постоянный журнал, пакетную отправку и увеличивающиеся интервалы между повторами;
• хранить локальные права в формате, который можно заменить целиком;
• открывать замок локальным импульсом с обязательным автоматическим закрытием;
• сохранять счётчик перезапусков и последовательный номер события, чтобы event_id не повторялся;
• проверить работу часов, NTP и поле clock_valid после полного отключения питания;
• отделить секреты интеграции от файлов и настроек, доступных через общий веб-интерфейс.

Для постоянной очереди на ODNFC-LAN Pro можно рассматривать FlashDB или SQLite. В обычном ODNFC-LAN эти модули могут быть недоступны, поэтому формат журнала и допустимый объём нужно подбирать отдельно с проверкой памяти и ресурса flash.

У ODNFC-RS485 требуется дополнительная защита от пропуска событий. Простого регистра с текущим UID недостаточно: карта может исчезнуть между двумя опросами. Для интеграции нужен счётчик новых событий или небольшой FIFO, а опрос и подтверждение чтения выполняет шлюз.

Поведение при отказах нужно задать до пилота

Для каждой двери отдельно определяют, что означает безопасное состояние. Оно зависит от типа замка, назначения помещения, кнопки выхода и требований пожарной безопасности. Его невозможно выбрать только на уровне API.

Защита обмена и карт

Для рабочего контура недостаточно скрыть адрес сервиса. Нужны:

• HTTPS с проверкой сертификата сервера;
• отдельный ключ или клиентский сертификат для каждого устройства или шлюза;
• возможность отозвать один ключ, не меняя настройки всех точек;
• минимальная роль технического пользователя 1С без интерактивного входа;
• ограничение сети: контроллеры обращаются только к шлюзу или опубликованному сервису;
• защита от повторного запроса на уровне event_id, времени и номера пакета;
• журнал изменения прав и версий политики;
• пароль на административный интерфейс и отдельный контур управления.

В ODNFC проверка TLS-сертификата включена по умолчанию. В рабочей системе не отключайте её через net.skip_ssl_verify(true): соединение останется зашифрованным, но устройство не сможет подтвердить, что отвечает нужный сервер. Для корпоративного центра сертификации нужно загрузить доверенный CA и заранее предусмотреть его замену.

UID карты также нельзя считать криптографическим доказательством личности. Его можно скопировать или эмулировать на части носителей. Если риск клонирования существенен, используйте защищённую память, индивидуальные ключи, счётчики или другую схему аутентификации. Варианты и их ограничения разобраны в статье «Защита от клонов меток».

Как провести пилот

Пилот лучше ограничить одной дверью и отдельной тестовой базой 1С:

1. Зафиксировать конфигурацию и версию 1С, формат UID, направление прохода и правила автономной работы.
2. Согласовать JSON-контракт, авторизацию, версии политики и лимиты очереди.
3. Реализовать в расширении 1С справочники, регистры и HTTP-сервис без записи в типовой табель.
4. Реализовать на ODNFC-LAN локальный кэш, импульс замка и постоянную очередь.
5. Проверить обычный проход, отказ, повтор карты, перезапуск и обновление прав.
6. Поочерёдно отключить сеть, 1С и питание, затем проверить доставку всех накопленных событий и отсутствие дублей.
7. Отдельно испытать заполнение очереди, неправильное время, повреждённую политику и замену сертификата.
8. Только после стенда подключать расчёт присутствия и добавлять следующие двери.

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

• Выбрать исполнение ODNFC
• Разобрать автономное управление дверью
• Изучить локальное хранение пользователей
• Обсудить архитектуру с инженером