Поиск активов по 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 недели.

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