Поиск активов по RFID: мобильное приложение с историей перемещений

Представьте: на складе 10 000 позиций, а нужный прибор не могут найти уже полчаса. Операторы бегают с бумажными списками, инвентаризация отнимает дни, а расхождение учёта с реальностью достигает 30%. RFID-отслеживание активов с мобильным приложением решает эту проблему: поиск по EPC занимает секунды, история перемещений видна в реальном времени, а интеграция с ERP устраняет ручной ввод. Мы разрабатываем такие системы с полным циклом — от проектирования событийной модели до ввода в эксплуатацию. Опыт: 7+ лет и 15+ проектов для складов, логистики и производства. Экономия времени на инвентаризацию составляет до 80%, а снижение затрат на поиск активов — в 3 раза.

Архитектура событийной модели

Каждое считывание тега — событие с метаданными:

data class AssetReadEvent( val epc: String, val readerLocation: String, // ID антенны/ридера val timestamp: Long, val rssi: Int, // сигнал: приблизительная дистанция val direction: ReadDirection?, // ENTRY / EXIT для воротных ридеров val operatorId: String? // кто сделал ручное считывание ) enum class ReadDirection { ENTRY, EXIT, UNKNOWN } 

Мобильное приложение генерирует события с operatorId и GPS/indoor-координатами. Воротные ридеры (Impinj Speedway, Zebra FX9600) генерируют свои события через LLRP или REST API. Всё сходится в одну очередь событий на бэкенде.

Как снизить затраты на поиск в 3 раза?

Ручная инвентаризация занимает часы, а поиск конкретного предмета — десятки минут. С нашим решением оператор с мобильным ридером находит актив за секунды благодаря фильтрации по EPC и отображению RSSI. Сравните:

Поиск конкретного актива

Самая частая операция в мобильном приложении — «найди актив XYZ на этом складе». RFID-ридер переходит в режим «proximity search»: показывает RSSI конкретного тега, помогая сократить зону поиска:

class AssetSearchSession( private val rfidReader: RfidReader, private val targetEpc: String ) { private val _proximity = MutableStateFlow(ProximityLevel.UNKNOWN) val proximity: StateFlow<ProximityLevel> = _proximity.asStateFlow() fun start() { rfidReader.setInventoryFilter(epcFilter = targetEpc) // читать только целевой тег rfidReader.startContinuousInventory(onTag = { tag -> if (tag.epc == targetEpc) { _proximity.value = rssiToProximity(tag.peakRSSI) } }) } private fun rssiToProximity(rssi: Int): ProximityLevel = when { rssi > -55 -> ProximityLevel.VERY_CLOSE // < 0.5м rssi > -65 -> ProximityLevel.CLOSE // 0.5–1.5м rssi > -75 -> ProximityLevel.MEDIUM // 1.5–3м else -> ProximityLevel.FAR // > 3м } } 

Фильтр по EPC (setInventoryFilter) критичен — без него ридер читает все теги в зоне и засоряет поток данными. Конкретные API фильтрации зависят от SDK ридера: Zebra RFID SDK — SLFlag, TagFilter; Chainway SDK — FilterParam.

История перемещений

// Room entities для истории активов @Entity(tableName = "asset_events", indices = [Index("epc"), Index("timestamp")]) data class AssetEventEntity( @PrimaryKey(autoGenerate = true) val id: Long = 0, val epc: String, val eventType: String, // "scan", "checkpoint", "entry", "exit" val locationId: String, val locationName: String, val operatorId: String?, val rssi: Int?, val timestamp: Long, val synced: Boolean = false ) @Dao interface AssetEventDao { @Query("SELECT * FROM asset_events WHERE epc = :epc ORDER BY timestamp DESC LIMIT 50") fun getAssetHistory(epc: String): Flow<List<AssetEventEntity>> @Query("SELECT * FROM asset_events WHERE synced = 0 ORDER BY timestamp ASC") suspend fun getUnsynced(): List<AssetEventEntity> } 

История на устройстве — только последние N событий. Полная история — на сервере. WorkManager синхронизирует несинхронизированные события при появлении сети.

Почему мы гарантируем точность до 99%?

Используем проверенные SDK, стабильные протоколы и тестируем на реальном оборудовании. Без анализа RSSI и направления движения невозможно отличить пронос актива мимо ворот от его временного нахождения в зоне. Наши алгоритмы учитывают оба параметра. Дополнительно применяем стандарт EPC Gen2 для совместимости тегов. Снижение ошибок учёта приводит к прямой экономии средств.

Сравнение популярных RFID-ридеров

Интеграция с ERP/WMS

Asset Tracking без интеграции с учётной системой — половина решения. REST API для синхронизации:

interface AssetTrackingApi { @POST("events/batch") suspend fun pushEvents(@Body events: List<AssetEventDto>): Response<BatchResult> @GET("assets/{epc}") suspend fun getAssetInfo(@Path("epc") epc: String): Response<AssetInfoDto> @GET("assets/{epc}/location") suspend fun getLastKnownLocation(@Path("epc") epc: String): Response<LocationDto> } 

getLastKnownLocation — для верификации: оператор сканирует тег, приложение сразу показывает где система его видела последний раз. Расхождение реального и системного местоположения — красный флаг для логиста.

Как проходит интеграция с WMS?

Шаг 1: аудит текущих процессов и определение критических точек контроля. Шаг 2: настройка стационарных ридеров и LLRP-шлюза для сбора событий. Шаг 3: разработка REST API для синхронизации — мы адаптируем под вашу ERP (1С, SAP, Oracle). Шаг 4: развёртывание мобильного приложения с модулями поиска и истории. Завершающий этап — тестирование на реальных активах и обучение операторов. Весь цикл занимает от 2 до 4 недель. Получите консультацию по вашему сценарию — мы поможем выбрать оптимальное решение.

Что входит в работу

• Анализ процессов и подбор RFID-оборудования.
• Разработка мобильного приложения (iOS/Android) с модулями поиска и истории.
• Настройка стационарных ридеров и LLRP-шлюза.
• Серверная событийная шина и REST API.
• Интеграция с вашей ERP/WMS (1С, SAP, Oracle и др.).
• Тестирование на реальных активах.
• Документация и обучение операторов.
• Гарантийная поддержка 3 месяца.

Типичная ошибка на старте — попытка сэкономить на ридерах и использовать дешёвые антенны без настройки поля. Это приводит к «мёртвым зонам» и пропускам считываний. Мы проводим предпроектное обследование и гарантируем покрытие.

Сроки

Мобильное приложение поиска активов + история событий + REST-синхронизация с WMS: 5 дней. Полное решение включая настройку стационарных ридеров Impinj/Zebra, LLRP-интеграцию и серверную событийную шину: 2–4 недели.

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