Routing di eventi IoT

Azure IoT
Hub IoT Azure

In una soluzione Internet delle cose (IoT) i dispositivi IoT inviano eventi (notifiche, acknowledgement, dati di telemetria) all'applicazione per ottenere dati analitici. Le applicazioni possono richiedere subset specifici di eventi per l'elaborazione o l'archiviazione in endpoint diversi. Questi eventi possono anche essere instradati ad altri servizi per essere ulteriormente elaborati. Quando la soluzione IoT è scalabile, il numero di dispositivi, il volume di eventi, la varietà di eventi e diversi servizi sono anch'essi variabili. Per soddisfare le esigenze di questo modello, è necessario un metodo flessibile, scalabile, coerente e affidabile per instradare gli eventi.

Potenziali casi d'uso

Un punto vendita sta monitorando i frigoriferi per la loro sezione di alimenti congelati:

  • Viene inviato un avviso quando la temperatura dei frigoriferi supera una soglia predeterminata. È possibile creare una regola di routing che includa la regola di soglia in base alla quale inviare questi eventi specifici a un sistema di avviso.
  • Il team di data science sta creando un modello di rilevamento anomalie per identificare i problemi relativi ai frigoriferi prima che si verifichi un guasto in uno di essi. Una regola di routing dei messaggi può inviare tutti i dati di telemetria non elaborati a un account di archiviazione specifico in modo che il team di data science possa usarli per il training e la modellazione.

Questo scenario si applica ai settori delle vendite al dettaglio, dell'energia e dell'ambiente.

Architettura

Architecture diagram illustrating use of rules to route events to different Azure services.

Scaricare un file di Visio di questa architettura.

In una piattaforma IoT è possibile creare regole per il routing degli eventi con granularità fine. È possibile configurare una o più regole nella piattaforma IoT. Le regole verranno applicate agli eventi in ingresso e instradate agli endpoint specifici.

Caratteristiche

Di seguito sono riportate alcune considerazioni relative al'uso di questo modello.

  • Velocità effettiva degli endpoint: gli endpoint che ricevono eventi devono essere in grado di gestire l'ingresso degli eventi inviati tramite routing. Assicurarsi che i servizi endpoint siano in grado di inserire e archiviare i dati fino a quando non vengono utilizzati.

  • Formato degli eventi: affinché il routing sia scalabile e flessibile, per gli eventi è necessario usare un formato comune che garantisca l'interoperabilità tra i protocolli.

  • Gestione degli eventi: se un evento corrisponde a più route che puntano allo stesso endpoint, il recapito deve essere effettuato una sola volta a tale endpoint. In tali situazioni è anche importante garantire l'ordinamento dei messaggi.

  • Duplicazione degli eventi: per gestire la duplicazione dei messaggi, è consigliabile specificare un identificatore univoco nelle proprietà dell'applicazione del messaggio nel punto di origine, che corrisponde in genere a un dispositivo o a un modulo. Il servizio che utilizza i messaggi può quindi gestire i messaggi duplicati usando questo identificatore.

  • Route di fallback: gli eventi che non corrispondono ad alcuna regola devono essere inviati a una route di fallback in modo che possano essere adeguatamente indirizzati senza alcuna perdita di eventi.

  • Eventi non di telemetria: le soluzioni IoT includono diversi tipi di eventi, ad esempio le modifiche dello stato del dispositivo e gli eventi del ciclo di vita del dispositivo. La route eventi deve essere in grado di acquisire e applicare regole a tali eventi non di telemetria per abilitare l'automazione e il monitoraggio.

Quando usare questo modello:

  • Invio di messaggi di telemetria del dispositivo, eventi del ciclo di vita del dispositivo oppure eventi di modifica del dispositivo gemello a endpoint specifici determinati dalle regole.

  • Filtro di eventi in seguito all'applicazione di regole specifiche.

Questo modello non è consigliato per:

  • Routing basato su un'analisi complessa in tempo reale dei dati di serie temporali, ad esempio quando si confrontano i dati di telemetria medi di 15 minuti. Se è necessaria l'analisi dei dati in tempo reale, usare un servizio di analisi in tempo reale per i dati del percorso critico.

Passaggi successivi