Scopo

Alcuni clienti desiderano utilizzare un'app mobile su iOS o Android per ricevere trasmissioni di beacon Bluetooth in background, invece di implementare un gateway Bluetooth dedicato. In questo documento valutiamo se tale approccio sia tecnicamente fattibile per il monitoraggio basato su beacon Lansitec, in particolare per dispositivi come il Etichetta Bluetooth B002 E B005 Faro Bluetooth. La questione non è se un telefono sia in grado di rilevare un beacon. Può farlo. La vera questione è se un'app per smartphone possa farlo in modo affidabile in background, nel tempo e con sufficiente costanza da sostituire un gateway.

La nostra posizione è semplice: è fattibile in alcuni casi, ma solo alle giuste condizioni. Per i normali telefoni di consumo e le app utilizzate occasionalmente, questo approccio di solito non è sufficientemente affidabile da poter essere considerato un sostituto completo di un gateway dedicato.

Il caso d'uso di destinazione

Sulla carta, l'architettura richiesta è semplice. B002 O B005 Il beacon trasmette dati BLE a intervalli configurabili. Un telefono su cui è installata l'app del cliente cerca questi dati, legge l'ID del beacon e l'intensità del segnale e carica l'evento di rilevamento sul server.

Ciò si adatta alle capacità di Lansitec fari. IL B002 è un'etichetta BLE ultrasottile basata su iBeacon, con intervalli di pubblicità configurabili da 100 ms a 10 s e una distanza di trasmissione in linea d'aria indicata come 150 m. B005 è un faro IP68 più robusto con intervalli configurabili, opzionale Supporto AoA, e la stessa portata di 150 m in linea d'aria.

Il problema, quindi, non risiede nel dispositivo beacon, bensì nel telefono.

Perché questo è diverso dal normale modello Lansitec?

In Lansitec B-Mobile soluzione, Gateway Bluetooth vengono dispiegati in postazioni fisse. Fari pubblicizzare periodicamente, portali ricevono i dati e il server calcola o interpreta la posizione in base alle posizioni note di quelli portali. Gli stessi documenti notano anche che porta d'accesso La ricezione è effettivamente sempre attiva nel modello di implementazione previsto, e questo RSSI può variare a causa di muri, interferenze ed effetti di multipath.

Avere l'app in questo punto cambia completamente la progettazione della soluzione.

Un fisso porta d'accesso Ti offre tre cose che un telefono normale non ha:

• una posizione fisica nota
• comportamento stabile della potenza
• disponibilità di ricezione prevedibile

Questa è la prima avvertenza che porremmo a qualsiasi cliente. Anche se l'app rileva il segnale del beacon, un telefono in movimento non è funzionalmente equivalente a un dispositivo montato. porta d'accesso.

fattibilità iOS

Su iOS, il funzionamento del Bluetooth in background è possibile, ma limitato. Apple afferma che le app che funzionano solo in primo piano non possono eseguire la scansione e rilevare periferiche pubblicitarie mentre sono in background o in sospensione. Le app che dichiarano la modalità di background "Bluetooth-central" possono comunque rilevare e connettersi alle periferiche in background, ma la scansione in background si comporta in modo diverso: i rilevamenti duplicati vengono uniti e gli intervalli di scansione potrebbero aumentare, il che significa che il rilevamento potrebbe richiedere più tempo. Apple afferma inoltre che le app riattivate da eventi Bluetooth dovrebbero terminare rapidamente e indica circa 10 secondi di funzionamento in background prima che la pressione della sospensione diventi un problema. ⁽¹⁾

Esiste una soluzione alternativa utile per iOS: il monitoraggio delle aree beacon. Il framework Core Location di Apple può monitorare le aree iBeacon e riattivare l'app in caso di ingresso o uscita. Tuttavia, ci sono dei compromessi. Apple limita il monitoraggio delle aree a 20 aree per app e raccomanda esplicitamente di utilizzare il rilevamento della distanza tramite beacon solo quando l'app è in primo piano. ⁽²⁾

Cosa significa questo in pratica?

Su iOS, un'app può supportare comportamenti in background correlati ai beacon, in particolare flussi di lavoro generici come "ingresso in una determinata area / uscita da un'altra". Tuttavia, non è una piattaforma adatta per la scansione passiva continua, simile a quella di un gateway, su larga scala. Se il cliente desidera un telefono sempre in ascolto che agisca silenziosamente come un'infrastruttura, iOS rappresenta la soluzione meno indicata.

fattibilità Android

Android è più flessibile, ma non fa miracoli. Le attuali linee guida per gli sviluppatori di Google affermano che la comunicazione BLE in background è possibile, ma il processo dell'app deve rimanere attivo. Se il processo viene terminato, le connessioni vengono chiuse. Google precisa inoltre che le scansioni non filtrate vengono interrotte quando lo schermo si spegne e riprendono quando si riaccende, a meno che non venga utilizzata la scansione filtrata.

Per l'utilizzo in background, Android documenta diverse soluzioni: eseguire la scansione con un PendingIntent, utilizzare CompanionDeviceService, utilizzare WorkManager o eseguire un servizio in primo piano con il tipo connectedDevice. Google sconsiglia inoltre le scansioni periodiche come soluzione generale perché sono inefficienti e potrebbero comunque essere interrotte. A partire da Android 14, i servizi in primo piano devono dichiarare esplicitamente il tipo di servizio appropriato. ⁽³⁾

Ecco il punto cruciale: Android può farlo meglio di iOS, ma l'affidabilità dipende in larga misura dalla disciplina di implementazione.

Un normale telefono Android per utenti consumer potrebbe comunque interrompere l'app a causa dell'ottimizzazione della batteria da parte del produttore, delle impostazioni utente, delle restrizioni in background o della pressione sulla memoria. Potrebbe essere necessario un dispositivo Android personalizzato di livello industriale per garantire che il processo non venga terminato in background. Un dispositivo gestito con whitelisting, gestione delle app ad alta priorità, impostazioni di alimentazione controllate e un flusso di lavoro specifico per ruolo ha molte più probabilità di successo.

Quando l'approccio basato sulle app può funzionare

Abbiamo individuato tre situazioni in cui l'idea di un'app è ragionevole.

Innanzitutto, quando l'app è effettivamente in uso operativo continuo

Questo potrebbe funzionare nei casi in cui l'utente tiene l'app aperta durante un turno, o il telefono è montato e utilizzato come parte di un processo lavorativo; in questi casi la ricezione del beacon diventa molto più realistica. Un esempio potrebbe essere il caso in cui il telefono sia montato su un veicolo o su una macchina da costruzione, come nel caso di un'app per autisti di Uber.

In secondo luogo, quando l'hardware è controllato

Uno smartphone Android robusto o personalizzato, soprattutto se gestito dall'azienda, è di gran lunga preferibile a un qualsiasi telefono personale. In questo caso, il telefono non è una semplice piattaforma per app mobili, ma un terminale semi-dedicato. Pertanto, è prevedibile un maggiore grado di personalizzazione ed è ragionevole che il software venga adattato in modo da rendere il processo fattibile.

In terzo luogo, quando il requisito è il rilevamento di eventi, non la localizzazione a livello di infrastruttura.

Se al cliente basta una semplice notifica come "beacon rilevato", "beacon vicino al telefono" o "operatore entrato in una zona con un dispositivo gestito", l'app potrebbe essere sufficiente. Se hanno bisogno di un monitoraggio stabile a livello di stanza o di sito indipendente dal comportamento dell'utente, allora no, cioè porta d'accesso territorio.

Principali limitazioni che devono essere indicate chiaramente

L'approccio basato sulle app presenta le seguenti limitazioni principali:

• L'esecuzione in background è controllata dal sistema operativo. Sia iOS che Android ottimizzano in modo aggressivo la durata della batteria. 
• Un telefono non è un'infrastruttura fissa. In B-Mobile, fisso porta d'accesso La posizione fa parte della logica di tracciamento.
• RSSI è instabile. I documenti stessi di Lansitec notano una debole ricezione tra le stanze, RSSI oscillazioni ed effetti multipath.
• Il comportamento dell'utente è importante. Se l'utente chiude l'app, disabilita le autorizzazioni, disattiva il Bluetooth o lascia che il telefono entri in modalità di risparmio energetico aggressiva, le prestazioni diminuiscono.
• Le differenze tra le piattaforme sono reali. Soprattutto su Android, il comportamento varia a seconda del produttore, poiché non è raro riscontrare una forte personalizzazione legata al marchio, a differenza di iOS dove Apple ha un controllo centralizzato.

Consigli pratici

Per un cliente che insiste sull'utilizzo dell'app, consigliamo quanto segue.

Utilizzo Android, non iOS, Per la prima dimostrazione di fattibilità, basare l'applicazione su scansioni BLE filtrate, comportamento del servizio in primo piano laddove consentito e gestione dei dispositivi aziendali. Utilizzare dispositivi robusti/personalizzati, se possibile. Mantenere l'app integrata in un flusso di lavoro operativo, non utilizzarla solo occasionalmente. Trattare l'app come un terminale gestito, non come una semplice installazione da un app store.

Per iOS, la soluzione va posizionata in modo più specifico. Può supportare avvisi, suggerimenti di presenza o flussi di lavoro controllati in aree beacon, ma non la sostituzione completa del gateway in implementazioni complesse.

Per i clienti che necessitano di una copertura costante del sito, una dipendenza minima dal comportamento dell'utente e un punto di riferimento stabile per il tracciamento, è consigliabile mantenere l'architettura del gateway Bluetooth dedicato. Questa rimane la soluzione migliore dal punto di vista ingegneristico e della stabilità funzionale.

Conclusione

Sì, un'app mobile può ricevere trasmissioni beacon in background. Ma questo non la rende automaticamente un buon sostituto di un Gateway Bluetooth.

Su iOS, l'approccio è limitato e dovrebbe essere considerato, nella migliore delle ipotesi, condizionato. Su Android standard è possibile, ma fragile. Su dispositivi Android personalizzati o industriali, soprattutto in un ambiente operativo gestito, diventa molto più realistico.

La conclusione finale è quindi questa:

Una soluzione di monitoraggio in background basata esclusivamente su app è fattibile per implementazioni Android selezionate con dispositivi controllati e utilizzo continuo dell'app. Non è un sostituto generale affidabile per il monitoraggio fisso. Gateway Bluetooth, soprattutto su iOS o su telefoni consumer non gestiti.

Riferimenti e ulteriori letture:

1. Apple: Guida di base alla programmazione Bluetooth
2. Apple: Guida alla programmazione di Location e Maps
3. Android: comunicazione BLE in background