Короткий ответ
API превращает чтение метки в учётную операцию
Считыватель выдаёт поток технических чтений. Промежуточный программный слой группирует их, исключает повторы, определяет зону и направление движения, сопоставляет EPC с объектом и передаёт в 1С, WMS или ERP уже понятное бизнес-событие.
Так настройки оборудования остаются на RFID-уровне, а учётная система работает с приёмкой, отгрузкой, инвентаризацией и перемещениями, а не с драйверами конкретной модели считывателя.
Путь данных
Пять уровней промышленной интеграции
Разделение уровней позволяет менять оборудование, масштабировать зоны и обслуживать обмен без прямой зависимости учётной системы от считывателя.
Считыватель
EPC, время, антенна и параметры чтения.
Edge-сервис
Управление устройствами и единый формат данных.
Событие
Дедупликация, зона, объект и правило процесса.
Обмен
REST API, вебхук, очередь или регламентный пакет.
1С / WMS / ERP
Документ, статус, расхождение и подтверждение обработки.
Главное различие
Техническое чтение и бизнес-событие — не одно и то же
Одна метка может быть считана много раз. В учётную систему должна попасть одна проверяемая операция с понятным контекстом.
Техническое чтение
EPC, считыватель, антенна, время, зона, сессия и диагностические параметры.
Бизнес-событие
Уникальный ID, тип операции, объект, документ-основание, время и результат проверки.
Удаление повторов
Повторные чтения объединяются в одно событие в рамках зоны и временного окна.
Сопоставление с процессом
EPC связывается с товаром, ТМЦ, паллетой или транспортом и ожидаемой операцией.
Устойчивость
Что предусмотреть в API-контракте
Стабильная интеграция определяется не только списком полей, но и поведением при повторах, сбоях и обновлении схемы.
- Идемпотентность. Повторная доставка одного события не создаёт вторую операцию.
- Очередь и повторы. События сохраняются локально, если 1С или WMS временно недоступна.
- Журнал ошибок. Видны исходное сообщение, ответ системы, число попыток и причина сбоя.
- Версионирование. Изменение схемы сообщения не требует одновременной остановки всех компонентов.
- Безопасность. Аутентификация, TLS, сетевые ограничения, разделение прав и журнал действий.
Транспорт сообщений
Варианты подключения к корпоративной системе
Способ обмена выбирают по требуемой скорости ответа, числу зон, автономности и правилам сопровождения инфраструктуры.
HTTP API
Подходит, когда отправителю нужен быстрый ответ: документ найден, событие принято или выявлено расхождение.
Вебхуки
RFID-платформа отправляет событие сразу после формирования. Нужны подтверждение, повторы и стабильный ID.
Очередь сообщений
Развязывает скорость чтения и обработки документов и помогает переживать временную недоступность систем.
Регламентный обмен
События передаются пакетами, если режим реального времени не требуется или доступ к системе ограничен.
Процесс внедрения
От модели событий до промышленного запуска
Формат API фиксируют после описания процесса, а не до него. Иначе интеграция передаёт данные, но не решает учётную задачу.
- Описать события
Определить операции, зоны, владельцев данных и ожидаемый результат.
- Согласовать справочники
Зафиксировать объекты, документы, статусы и правила сопоставления EPC.
- Утвердить контракт
Поля, ответы, повторы, ошибки, безопасность и версию сообщения.
- Проверить на пилоте
Тестовая копия базы, одна RFID-зона и реальные сценарии обмена.
- Масштабировать
Параллельная эксплуатация, сверка результатов и запуск остальных зон.
LLRP не заменяет прикладной API
GS1 LLRP описывает низкоуровневый интерфейс между программным клиентом и RFID-считывателем. Бизнес-правила, устранение повторов, документы 1С/WMS и обработка ошибок проектируются на прикладном уровне.
Частые вопросы
RFID API без путаницы в уровнях
Есть ли единый API для всех RFID-считывателей?
Полностью единого прикладного API нет. Часть оборудования поддерживает стандарт LLRP, часть — собственный SDK или протокол. Промежуточный слой позволяет привести данные разных устройств к единой модели событий.
LLRP и RFID API — одно и то же?
Нет. LLRP управляет считывателем и операциями радиоинтерфейса. Прикладной RFID API передаёт уже обработанные события в 1С, WMS, ERP или другую систему.
Можно ли подключить RFID напрямую к 1С?
Технически возможно, но для нескольких считывателей и зон надёжнее использовать промежуточный сервис. Он фильтрует повторы, хранит очередь при недоступности 1С и отделяет драйверы оборудования от конфигурации учётной системы.
Что происходит, если 1С или WMS недоступна?
При корректной архитектуре события сохраняются в локальной очереди, а после восстановления связи отправляются повторно. Повторная доставка не должна создавать дубли благодаря идентификатору события и идемпотентной обработке.
Нужен ли EPCIS для внутреннего RFID-проекта?
Не всегда. EPCIS полезен, когда требуется стандартизованный обмен событиями прослеживаемости между несколькими системами или компаниями. Для локального проекта может быть достаточно согласованного REST API или другого внутреннего контракта.
Редакционная проверка: 16 июля 2026 года.
Источники: GS1 LLRP 2.0, GS1 EPCIS, EPCIS 2.0.1 artefacts, официальная документация 1С:Enterprise.
Следующий шаг
Спроектируем модель событий до разработки API
Опишите учётную систему, оборудование и операции. BizData предложит схему обмена и проверит её на пилотной RFID-зоне.
