Пошук активів за RFID: мобільний додаток з історією переміщень

Пошук активів за RFID: мобільний додаток з історією переміщень

Уявіть: на складі 10 000 позицій, а потрібний прилад не можуть знайти вже півгодини. Оператори бігають з паперовими списками, інвентаризація забирає дні, а розбіжність обліку з реальністю сягає 30%. RFID-відстеження активів з мобільним додатком вирішує цю проблему: пошук за EPC займає секунди, історія переміщень видна в реальному часі, а інтеграція з ERP усуває ручне введення. Ми розробляємо такі системи з повним циклом — від проектування подійної моделі до введення в експлуатацію. Досвід: понад 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 тижні.

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