D AWS IOT LENS THIS PAPER HAS BEEN ARCHIVED. THE LATEST VERSION IS NOW AVAILABLE AT: AWSSTATIC
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
AWS IoT Lens
d
Canone di architettura AWS
v e
Dicembre 2019
h i
This paper has been archived.
rc
The latest version is now available at:
A
https://docs.aws.amazon.com/it_it/wellarchitected/latest/iot-lens/welcome.html
Avvisi
I clienti sono responsabili della propria valutazione autonoma delle informazioni contenute in
questo documento. Questo documento: (a) è solo a scopo informativo, (b) mostra le offerte e
le pratiche attuali dei prodotti AWS soggette a modifiche senza preavviso, e (c) non crea alcun
impegno o garanzia da parte di AWS e dai suoi affiliati, fornitori o licenziatari. I prodotti o
servizi AWS sono forniti "così come sono" senza garanzie, dichiarazioni o condizioni di alcun
tipo, sia esplicite che implicite. Le responsabilità di AWS nei confronti dei propri clienti sono
definite dai contratti AWS e il presente documento non costituisce parte né modifica
qualsivoglia contratto tra AWS e i suoi clienti.
e d
©2019, Amazon Web Services, Inc. o sue affiliate. Tutti i diritti riservati.
h i v
rc
A
Sommario
Introduzione ............................................................................................................................................... 1
Definizioni ................................................................................................................................................... 1
Livello di progettazione e produzione ............................................................................................... 2
Layer Edge............................................................................................................................................... 2
Layer di provisioning ............................................................................................................................. 3
d
Layer di comunicazione ........................................................................................................................ 3
Layer di acquisizione ............................................................................................................................. 4
e
Layer di analisi ........................................................................................................................................ 4
Layer dell'applicazione.......................................................................................................................... 5
i v
Principi generali di progettazione .......................................................................................................... 7
Scenari ......................................................................................................................................................... 8
h
Provisioning dei dispositivi................................................................................................................... 8
c
Telemetria dei dispositivi ...................................................................................................................10
Comandi dei dispositivi .......................................................................................................................11
r
Aggiornamenti firmware ....................................................................................................................14
I pilastri del Canone di architettura ......................................................................................................15
A
Pilastro di eccellenza operativa .........................................................................................................15
Pilastro della sicurezza........................................................................................................................21
Pilastro dell'affidabilità ..........................................................................................................................35
Pilastro di efficienza delle prestazioni .................................................................................................41
Il pilastro dell'ottimizzazione dei costi ................................................................................................50
Conclusioni ................................................................................................................................................55
Collaboratori .............................................................................................................................................55
Revisioni del documento ........................................................................................................................56Riassunto
Questo whitepaper descrive AWS IoT Lens per il canone di architettura AWS, che consente
ai clienti di revisionare e migliorare le architetture basate sul cloud e comprendere meglio
l'impatto aziendale delle decisioni di progettazione. Il documento descrive i principi generali
di progettazione, best practice e linee guida specifiche per i cinque pilastri del canone
di architettura.
e d
h i v
rc
AAmazon Web Services Canone di architettura AWS - IoT Lens
Introduzione
Il Canone di architettura AWS aiuta a comprendere gli aspetti positivi e negativi delle
decisioni prese durante la progettazione di sistemi in AWS. Utilizzando il framework scoprirai
le best practice architetturali per progettare e gestire sistemi affidabili, sicuri, efficienti e
convenienti nel cloud. Permette di misurare in modo coerente le architetture secondo le best
practice e identificare le aree da migliorare. Disporre di sistemi ben architettati aumenta
notevolmente la probabilità di successo aziendale.
In questo "Lens" (approfondimento) ci concentriamo su come progettare, distribuire e creare
d
i carichi di lavori IoT (Internet of Things) in AWS Cloud. Per implementare un'applicazione IoT
ben progettata, è necessario seguire i pilastri del canone, a partire dall'a fornitura di asset
e
fisici connessi (oggetti) alla disattivazione finale degli stessi asset in modo sicuro, affidabile
e automatizzato. Oltre alle best practice di AWS Cloud, questo documento illustra anche
v
l'impatto, le considerazioni e le raccomandazioni per la connessione di asset fisici a Internet.
i
Questo documento riguarda solo i dettagli relativi al carico di lavoro specifico IoT del Canone
di architettura. Ti consigliamo di leggere il whitepaper sul Canone di architettura AWS e di
h
considerare le best practice e le domande per altri approfondimenti.
Questo documento è rivolto a chi svolge ruoli tecnologici, per esempio Chief Technology Officer
c
(CTO), progettisti, sviluppatori e membri del team operativo. Grazie a questo documento otterrai
r
una conoscenza approfondita delle best practice e delle strategie di AWS per le applicazioni IoT.
Definizioni
A
Il Canone di architettura AWS si basa su cinque pilastri: eccellenza operativa, sicurezza,
affidabilità, efficienza delle prestazioni e ottimizzazione dei costi. Quando si progettano soluzioni
tecnologiche è consigliabile cercare l'equilibrio fra il contesto aziendale e i pilastri. Per i carichi di
lavoro IoT, AWS fornisce diversi servizi che consentono di progettare architetture solide per le
applicazioni. Le applicazioni IoT (Internet of Things) sono costituite da molti dispositivi (o oggetti)
che si connettono in modo sicuro e interagiscono con componenti basati su edge e cloud
complementari per offrire valore aggiunto. Le applicazioni IoT raccolgono, elaborano, analizzano
e agiscono sui dati generati dai dispositivi connessi. Questa sezione presenta una panoramica dei
componenti AWS utilizzati in questo documento per progettare carichi di lavoro IoT. Ci sono sette
livelli logici distinti da considerare durante la creazione di un carico di lavoro IoT:
Livello di progettazione e produzione
Layer Edge
Layer di provisioning
Layer di comunicazione
1Amazon Web Services Canone di architettura AWS - IoT Lens
Layer di acquisizione
Layer di analisi
Layer dell'applicazione
Livello di progettazione e produzione
Il layer di progettazione e produzione consiste nell'ideazione del prodotto, la raccolta di
requisiti aziendali e tecnici, la prototipazione, il layout e la progettazione di moduli e prodotti,
la fornitura di componenti e la produzione. Le decisioni prese in ciascuna fase influiscono sui
d
livelli logici successivi del carico di lavoro IoT descritti in seguito. Per esempio, alcuni creatori
di dispositivi IoT preferiscono avere un'immagine firmware comune masterizzata e testata dal
produttore del contratto. Questa decisione determinerà in parte quali fasi sono necessarie
e
durante il layer di provisioning.
v
Puoi fare un passo avanti e masterizzare un certificato univoco e una chiave di privacy per
ciascun dispositivo durante la produzione. Questa decisione può influire sul layer di
i
comunicazione, poiché il tipo di credenziale può influire sulla selezione successiva dei
protocolli di rete. Se la credenziale non scade mai, può semplificare i layer di comunicazione
h
e provisioning con un possibile aumento del rischio di perdita di dati a causa della
compromissione dell'autorità di certificazione emittente.
c
Layer Edge
r
Il layer edge del carico di lavoro IoT è costituito dall'hardware fisico dei dispositivi, dal sistema
operativo incorporato che gestisce i processi sul dispositivo e dal firmware del dispositivo, ovvero
A
il software e le istruzioni programmate sui dispositivi IoT. L'edge è responsabile del rilevamento
e dell'azione su altri dispositivi periferici. I casi d'uso più comuni sono la lettura di sensori collegati
a un dispositivo edge o la modifica dello stato di una periferica in base all'azione dell'utente, per
esempio l'accensione di una luce quando viene attivato un sensore di movimento.
Gli SDK per dispositivi AWS IoT semplificano l'utilizzo di AWS IoT Core con dispositivi e
applicazioni grazie a un'API progettata su misura per il linguaggio di programmazione o la
piattaforma in uso.
Amazon FreeRTOS è un sistema operativo in tempo reale per microcontroller che consente
di programmare dispositivi edge di piccole dimensioni, a basso consumo, sfruttando librerie
integrate sicure ed efficienti in termini di memoria.
AWS IoT Greengrass è un componente software che estende il sistema operativo Linux dei
dispositivi IoT. AWS IoT Greengrass consente di eseguire il routing locale MQTT tra dispositivi,
caching dei dati, sincronizzazione shadow di AWS IoT, funzioni AWS Lambda locali e algoritmi
di machine learning.
2Amazon Web Services Canone di architettura AWS - IoT Lens
Layer di provisioning
Il layer di provisioning dei carichi di lavoro IoT è costituito dall'infrastruttura a chiave pubblica
(PKI) utilizzata per creare identità univoche dei dispositivi e dal flusso di lavoro
dell'applicazione che fornisce i dati di configurazione al dispositivo. Il layer di provisioning
è anche coinvolto nella manutenzione continua e nella disattivazione finale dei dispositivi
nel corso del tempo. Le applicazioni IoT necessitano di un livello di provisioning robusto e
automatizzato, in modo che i dispositivi possano essere aggiunti e gestiti dall'applicazione IoT
in modo semplice. Quando effettui il provisioning di dispositivi IoT, devi installare una
credenziale crittografica univoca.
d
Utilizzando i certificati X.509, è possibile implementare un livello di provisioning che crea
in modo sicuro un'identità attendibile per il dispositivo che può essere utilizzata per eseguire
e
l'autenticazione e l'autorizzazione rispetto al layer di comunicazione. I certificati X.509
vengono emessi da un'entità attendibile denominata autorità di certificazione (CA). Mentre
v
i certificati X.509 consumano risorse su dispositivi vincolati a causa dei requisiti di memoria
i
ed elaborazione, sono un meccanismo di identità ideale grazie alla scalabilità operativa
e al supporto diffuso da parte dei protocolli di rete standard.
h
AWS Certificate Manager Private CA aiuta ad automatizzare il processo di gestione del ciclo
di vita dei certificati privati per dispositivi IoT utilizzando le API. I certificati privati, come i
c
certificati X.509, offrono un modo sicuro per fornire a un dispositivo un'identità a lungo
termine che può essere creata durante il provisioning e utilizzata per identificare e autorizzare
r
i dispositivi sull'applicazione IoT.
AWS IoT Just In Time Registration (JITR) consente di registrare in modo programmatico
A
i dispositivi da utilizzare con piattaforme IoT gestite come AWS IoT Core. Con la registrazione
Just-In-Time, quando i dispositivi vengono innanzitutto connessi all'endpoint AWS IoT Core,
è possibile attivare automaticamente un flusso di lavoro in grado di determinare la validità
dell'identità del certificato e determinare quali autorizzazioni devono essere concesse.
Layer di comunicazione
Il layer di comunicazione gestisce la connettività, l'instradamento dei messaggi tra i dispositivi
in remoto e tra i dispositivi e il cloud. Il layer di comunicazione consente di stabilire il modo in
cui i messaggi IoT vengono inviati e ricevuti dai dispositivi e come i dispositivi rappresentano
e memorizzano il loro stato fisico nel cloud.
AWS IoT Core aiuta a creare applicazioni IoT fornendo un broker di messaggistica gestito che
supporta l'utilizzo del protocollo MQTT per pubblicare e sottoscrivere messaggi IoT tra dispositivi.
AWS IoT Device Registry ti aiuta a gestire e lavorare gli oggetti. Un oggetto è una
rappresentazione di un dispositivo specifico o di un'entità logica nel cloud. Gli oggetti
3Amazon Web Services Canone di architettura AWS - IoT Lens
possono anche avere attributi statici personalizzati che aiutano a identificare, categorizzare
e cercare gli asset una volta distribuiti.
Con AWS IoT Device Shadow Service, puoi creare un datastore che contiene lo stato corrente
di un determinato dispositivo. Il servizio Device Shadow mantiene una rappresentazione
virtuale di ogni dispositivo connesso ad AWS IoT come dispositivo shadow distinto. Ogni copia
shadow del dispositivo è identificata in modo univoco dal nome dell'oggetto corrispondente.
Con Amazon API Gateway, le applicazioni IoT possono effettuare richieste HTTP per
controllare i dispositivi IoT. Le applicazioni IoT richiedono interfacce API per sistemi interni,
ad esempio pannelli di controllo per tecnici da remoto e sistemi esterni, come per esempio
d
un'applicazione per dispositivi mobili per uso domestico. Con Amazon API Gateway è possibile
creare interfacce API comuni senza la necessità di effettuare il provisioning e gestire
e
l'infrastruttura sottostante.
Layer di acquisizione
i v
Un fattore chiave per l'IoT è la possibilità di aggregare i diversi flussi di dati creati dai
dispositivi e trasmettere i dati all'applicazione IoT in modo sicuro e affidabile. Il livello
h
di acquisizione gioca un ruolo chiave nella raccolta dei dati del dispositivo, disaccoppiando
il flusso di dati con la comunicazione tra i dispositivi.
c
Con il motore di regole di AWS IoT, puoi creare applicazioni IoT in modo che i dispositivi
possano interagire con i servizi AWS. Le regole di AWS IoT vengono analizzate e le operazioni
r
vengono eseguite in base al flusso di argomenti MQTT su cui viene ricevuto un messaggio.
A
Amazon Kinesis è un servizio gestito per lo streaming di dati che consente di ottenere
informazioni tempestive e reagire rapidamente alle nuove informazioni dai dispositivi IoT.
Amazon Kinesis si integra direttamente con il motore di regole di AWS IoT, creando un
collegamento ottimizzato da un protocollo di dispositivo MQTT con le applicazioni IoT interne
che utilizzano altri protocolli.
Analogamente a Kinesis, Amazon Simple Queue Service (Amazon SQS) deve essere
utilizzato nell'applicazione IoT per separare il livello di comunicazione dal livello
dell'applicazione. Amazon SQS consente una coda di acquisizione scalabile basata su eventi
se l'applicazione deve elaborare applicazioni IoT in cui l'ordine dei messaggi non è richiesto.
Layer di analisi
Uno dei vantaggi dell'implementazione di soluzioni IoT è la capacità di ottenere informazioni
approfondite e dati su ciò che accade nell'ambiente locale/edge. Il modo principale per
ottenere informazioni contestuali è implementare soluzioni in grado di elaborare ed eseguire
analisi sui dati IoT.
4Amazon Web Services Canone di architettura AWS - IoT Lens
Servizi di storage
I carichi di lavoro IoT sono spesso progettati per generare grandi quantità di dati. Assicurati che
questi dati vengano trasmessi, elaborati, utilizzati in modo sicuro e archiviati in modo duraturo.
Amazon S3 è uno storage basato su oggetti progettato per archiviare e recuperare qualsiasi
quantità di dati da qualunque luogo su Internet. Con Amazon S3 puoi creare applicazioni IoT
che memorizzano grandi quantità di dati per un'ampia gamma di scopi: normative, evoluzione
aziendale, parametri, studi longitudinali, machine learning di analisi e abilitazione
organizzativa. Amazon S3 offre un'ampia gamma di flessibilità nella gestione dei dati non solo
per l'ottimizzazione dei costi e la latenza, ma anche per il controllo degli accessi e la conformità.
d
Servizi di analisi e machine learning
e
Quando i dati IoT raggiungono una posizione di storage centrale, puoi iniziare a sbloccare il
valore completo dell'IoT implementando analisi e machine learning sul comportamento dei
v
dispositivi. Con i sistemi di analisi, è possibile iniziare a rendere operativi i miglioramenti del
i
firmware del dispositivo, nonché la logica edge e cloud, prendendo decisioni basate sui dati
in base all'analisi. Con l'analisi e il machine learning i sistemi IoT possono implementare
h
strategie proattive come manutenzione predittiva o rilevamento di anomalie per migliorare
l'efficienza del sistema.
c
AWS IoT Analytics semplifica l'esecuzione di analisi sofisticate su volumi in IoT. AWS IoT Analytics
gestisce il datastore IoT sottostante mentre crei diverse visualizzazioni materializzate dei dati
r
utilizzando query analitiche o notebook Jupyter.
Amazon Athena è un servizio di query interattivo che semplifica l'analisi dei dati in Amazon S3
A
con SQL standard. Athena è un servizio serverless che si paga solo in base al tempo di query
e non comporta la gestione di un'infrastruttura.
Amazon SageMaker è una piattaforma completamente gestita che consente di creare,
formare e distribuire rapidamente modelli di machine learning nel cloud e nel layer edge.
Con Amazon SageMaker, le architetture IoT possono sviluppare un modello di telemetria
cronologica dei dispositivi per dedurre il comportamento futuro.
Layer dell'applicazione
AWS IoT offre diverse modalità per semplificare il consumo dei dati generati dai dispositivi IoT
da parte delle applicazioni native del cloud. Queste funzionalità connesse includono
caratteristiche di elaborazione serverless, database relazionali per creare visualizzazioni
materializzate dei dati IoT e applicazioni per ispezionare, proteggere e gestire le operazioni IoT.
5Amazon Web Services Canone di architettura AWS - IoT Lens
Applicazioni di gestione
Lo scopo delle applicazioni di gestione è creare modi scalabili per gestire i dispositivi una
volta distribuiti sul campo. Attività operative comuni come l'ispezione dello stato di
connettività di un dispositivo, la verifica della corretta configurazione delle sue credenziali
e l'esecuzione di query sui dispositivi in base al loro stato corrente devono essere presenti
prima dell'avvio, in modo che il sistema abbia la visibilità necessaria per la risoluzione dei
problemi delle applicazioni.
AWS IoT Device Defender è un servizio completamente gestito che esegue l'audit del parco
dei dispositivi, rileva comportamenti anomali, avvisa in caso di problemi di sicurezza e aiuta
d
a investigare e mitigare i problemi di sicurezza IoT più comuni.
AWS IoT Device Management facilita l'organizzazione, il monitoraggio e la gestione di
e
dispositivi IoT su vasta scala. I clienti, su vasta scala, gestiscono parchi di dispositivi su più
ubicazioni fisiche. AWS IoT Device Management consente di raggruppare i dispositivi per
v
facilitare la gestione. È anche possibile abilitare l'indicizzazione di ricerca in tempo reale
i
rispetto allo stato corrente dei dispositivi tramite Device Management Fleet Indexing. Sia i
gruppi di dispositivi che l'indicizzazione del parco istanze possono essere utilizzati con gli
aggiornamenti OTA (Over the Air Updates) per determinare quali dispositivi di destinazione
h
devono essere aggiornati.
c
Applicazioni dell'utente
r
Oltre alle applicazioni gestite, altri sistemi interni ed esterni necessitano di segmenti diversi
dei dati IoT per la creazione di applicazioni. Per supportare le visualizzazioni dei consumatori
A
finali, dei pannelli di controllo operativi aziendali e delle altre applicazioni di rete create nel
corso del tempo, servono altre tecnologie in grado di ricevere le informazioni necessarie dal
livello di connettività e acquisizione e formattarle per essere utilizzate da altri sistemi.
Servizi di database - NoSQL e SQL
Mentre un data lake può funzionare come punto di arrivo per tutti i dati non formattati
generati da IoT, per supportare tutte le visualizzazioni formattate sui dati IoT è necessario
integrare il data lake con datastore strutturati e semi strutturati. Per questo è consigliabile
utilizzare entrambi i database NoSQL e SQL. Questi tipi di database consentono di creare
visualizzazioni dei dati IoT per i diversi utenti finali della tua applicazione.
Amazon DynamoDB è un servizio di database NoSQL rapido e flessibile per dati IoT. Con
le applicazioni IoT, i clienti spesso necessitano di modelli di dati flessibili con prestazioni
affidabili e scalabilità automatica della capacità di throughput.
Con Amazon Aurora la tua architettura IoT può archiviare dati strutturati in un database open
source performante e conveniente. Quando i dati devono essere accessibili ad altre
6Amazon Web Services Canone di architettura AWS - IoT Lens
applicazioni IoT per query SQL predefinite, i database relazionali offrono un altro
meccanismo per disaccoppiare il flusso del dispositivo del livello di acquisizione dalle
applicazioni aziendali finali, che devono agire su segmenti discreti dei dati.
Servizi di elaborazione
Spesso, i carichi di lavoro IoT richiedono l'esecuzione del codice dell'applicazione quando
i dati vengono generati, acquisiti o utilizzati/realizzati. Indipendentemente dal momento
in cui è necessario eseguire il codice, il calcolo serverless è una scelta estremamente
conveniente. L'elaborazione serverless può essere sfruttata dall'edge al core, dal core alle
d
applicazioni e alle analisi.
AWS Lambda consente di eseguire codice senza dover effettuare il provisioning né gestire
e
server. Grazie alle dimensioni dell'acquisizione per carichi di lavoro IoT, AWS Lambda è la
soluzione ideale per l'esecuzione di applicazioni IoT stateless basate su eventi su una
v
piattaforma gestita.
i
Principi generali di progettazione
h
Il Canone di architettura identifica il seguente set di principi di progettazione per facilitarla
c
nel cloud con IoT:
Disaccoppiamento dell'acquisizione dall'elaborazione: nelle applicazioni IoT, il layer
r
di acquisizione deve essere una piattaforma altamente scalabile in grado di gestire un
elevato tasso di dati dei dispositivi di streaming. Disaccoppiando la velocità di
A
acquisizione rapida dalla porzione di elaborazione dell'applicazione attraverso l'uso
di code, buffer e servizi di messaggistica, l'applicazione IoT può prendere diverse
decisioni senza alcun impatto sui dispositivi, ad esempio la frequenza in cui elabora
i dati o il tipo di dati a cui è interessato.
Progettazione per il comportamento offline: a causa di problemi di connettività o
impostazioni non configurate, i dispositivi possono andare offline per periodi di tempo
molto più lunghi del previsto. Progetta il tuo software incorporato per gestire lunghi
periodi di connettività offline e crea parametri nel cloud per monitorare i dispositivi
che non comunicano a intervalli regolari.
Progettare dati snelli a livello di edge location e arricchire il cloud: data la natura
vincolata dei dispositivi IoT, lo schema iniziale dei dispositivi sarà ottimizzato per lo
storage sul dispositivo fisico e per le trasmissioni efficienti dal dispositivo alla tua
applicazione IoT. Per questo motivo, i dati dei dispositivi non formattati spesso non
vengono arricchiti da informazioni statiche sulle applicazioni che possono essere
dedotti dal cloud. Per questi motivi, poiché i dati vengono acquisiti nell'applicazione,
è preferibile arricchire i dati con attributi leggibili da essere umano, deserializzare
7Amazon Web Services Canone di architettura AWS - IoT Lens
o espandere qualsiasi campo serializzato dal dispositivo e quindi formattare i dati in
un datastore ottimizzato per supportare i requisiti di lettura delle applicazioni.
Gestione della personalizzazione: i dispositivi che si connettono all'edge o al cloud
tramite Wi-Fi devono ricevere il nome del punto di accesso e la password di rete come
uno dei primi passaggi eseguiti durante la configurazione del dispositivo. Questi dati
in genere non possono essere scritti sul dispositivo durante la produzione poiché sono
sensibili e specifici del sito o provenienti dal cloud poiché il dispositivo non è ancora
connesso. Questi fattori rendono spesso i dati di personalizzazione distinti dal
certificato client del dispositivo e dalla chiave privata, concettualmente upstream,
e dagli aggiornamenti di configurazione e firmware forniti dal cloud, che sono
d
concettualmente a valle. Il supporto della personalizzazione può influire sulla
progettazione e sulla produzione, poiché può significare che il dispositivo stesso
e
richieda un'interfaccia utente per l'input diretto dei dati o la necessità di fornire
un'applicazione per smartphone per collegare il dispositivo alla rete locale.
v
Assicurati che i dispositivi inviino regolarmente controlli dello stato: anche se
i
i dispositivi sono regolarmente offline per lunghi periodi di tempo, assicurati che il
firmware del dispositivo contenga la logica dell'applicazione che imposta un intervallo
h
regolare per inviare le informazioni sullo stato del dispositivo all'applicazione IoT.
I dispositivi devono essere partecipanti attivi per garantire che la tua applicazione
c
abbia il giusto livello di visibilità. L'invio di questo messaggio IoT che si verifica
regolarmente assicura che l'applicazione IoT ottenga una visualizzazione aggiornata
r
dello stato generale di un dispositivo e possa creare processi quando un dispositivo
non comunica entro il periodo di tempo previsto.
A
Scenari
Questa sezione affronta gli scenari comuni correlati alle applicazioni IoT, con particolare
attenzione al modo in cui ogni scenario influisce sull'architettura del carico di lavoro IoT.
Questi esempi non sono esaustivi, ma includono modelli comuni nell'IoT. Presentiamo uno
sfondo su ogni scenario, considerazioni generali sulla progettazione del sistema e
un'architettura di riferimento su come implementare gli scenari.
Provisioning dei dispositivi
In IoT, il provisioning dei dispositivi è composto da diverse fasi sequenziali. L'aspetto più
importante è che ogni dispositivo deve ricevere un'identità univoca e successivamente deve
essere autenticato dall'applicazione IoT mediante tale identità.
Pertanto, il primo passo per effettuare il provisioning di un dispositivo consiste nell'installare
un'identità. Le decisioni prese nella progettazione e nella produzione dei dispositivi
determinano se il dispositivo dispone di un'immagine firmware pronta per la produzione
8Amazon Web Services Canone di architettura AWS - IoT Lens
e/o di credenziali client univoche nel momento in cui raggiunge il cliente. Le tue decisioni
determinano se ci sono ulteriori fasi di provisioning da eseguire prima che un dispositivo
di produzione possa essere installato.
Utilizza i certificati client X.509 in IoT per le tue applicazioni poiché tendono a essere più
sicuri e facili da gestire su vasta scala rispetto alle password statiche. In AWS IoT Core, il
dispositivo viene registrato utilizzando il relativo certificato insieme a un identificatore
univoco dell'oggetto. Il dispositivo registrato viene quindi associato a una policy IoT. Una
policy IoT offre la possibilità di creare autorizzazioni granulari per dispositivo. Le
autorizzazioni granulari garantiscono che solo un dispositivo disponga delle autorizzazioni
per interagire con i propri argomenti e messaggi MQTT.
d
Questo processo di registrazione garantisce che un dispositivo sia riconosciuto come asset IoT
e
e che i dati generati possano essere consumati tramite AWS IoT fino al resto dell'ecosistema
AWS. Per effettuare il provisioning di un dispositivo, si deve abilitare la registrazione
automatica e associare un modello di provisioning o una funzione AWS Lambda all'evento
v
di provisioning iniziale del dispositivo.
i
Questo meccanismo di registrazione si basa sul dispositivo che riceve un certificato univoco
durante il provisioning (che può verificarsi durante o dopo la produzione), che viene utilizzato
h
per eseguire l'autenticazione nell'applicazione IoT, in questo caso AWS IoT. Uno dei vantaggi
di questo approccio è che il dispositivo può essere trasferito a un'altra entità ed essere
c
riassegnato, consentendo la ripetizione del processo di registrazione con i dettagli
dell'account AWS IoT del nuovo proprietario.
A r
Figura 1: flusso di registrazione
9Amazon Web Services Canone di architettura AWS - IoT Lens
1. Configura l'identificatore del dispositivo di produzione in un database.
2. Il dispositivo si connette ad API Gateway e richiede la registrazione dal CPM.
La richiesta viene convalidata.
3. Lambda richiede i certificati X.509 all'autorità di certificazione privata (CA).
4. Il sistema di provisioning ha registrato la CA con AWS IoT Core.
5. API Gateway trasferisce le credenziali del dispositivo al dispositivo.
6. Il dispositivo avvia il flusso di lavoro di registrazione con AWS IoT Core.
e d
Telemetria dei dispositivi
Esistono molti casi d'uso (per esempio l'IoT industriale) in cui il valore dell'IoT emerge dalla
v
raccolta della telemetria sulle prestazioni di una macchina. Per esempio, questi dati possono
i
essere utilizzati per consentire la manutenzione predittiva, evitando guasti imprevisti
e costosi alle apparecchiature. La telemetria deve essere raccolta dal computer e caricata
h
in un'applicazione IoT. Un altro vantaggio dell'invio di telemetria è la possibilità delle
applicazioni cloud di utilizzare questi dati per l'analisi e di interpretare le ottimizzazioni
c
che possono essere effettuate nel firmware nel corso del tempo.
r
I dati di telemetria sono di sola lettura e vengono raccolti e trasmessi all'applicazione IoT.
Poiché i dati telemetrici sono passivi, è necessario assicurarsi che l'argomento MQTT per
i messaggi telemetrici non si sovrapponga agli argomenti correlati ai comandi IoT. Per
A
esempio, un argomento di telemetria potrebbe essere data/device/sensortype in cui
qualsiasi argomento MQTT che inizia con "data" è considerato un argomento telemetrico.
Da un punto di vista logico, abbiamo definito diversi scenari per l'acquisizione e l'interazione
con la telemetria dei dati dei dispositivi.
10Amazon Web Services Canone di architettura AWS - IoT Lens
e d
i v
Figura 2: opzioni per l'acquisizione di dati telemetrici
h
1. Un argomento di pubblicazione e un sottoscrittore. Per esempio, una lampadina
c
intelligente che pubblica il proprio livello di luminosità in un singolo argomento
r
in cui solo una singola applicazione può effettuare la sottoscrizione.
2. Un argomento di pubblicazione con variabili e un sottoscrittore. Per esempio, un
gruppo di lampadine intelligenti che pubblicano la loro luminosità su argomenti simili
A
ma univoci. Ogni sottoscrittore può ascoltare un messaggio di pubblicazione univoco.
3. Argomento di pubblicazione singolo e più sottoscrittori. In questo caso, un sensore
di luce che pubblica i propri valori in un argomento cui sottendono tutte le lampadine
in una casa.
4. Più argomenti di pubblicazione e un singolo sottoscrittore. Ad esempio, un gruppo
di lampadine con sensori di movimento. Il sistema smart home sottoscrive tutti gli
argomenti relativi alle lampadine, inclusi i sensori di movimento e crea una
visualizzazione composita della luminosità e dei dati dei sensori di movimento.
Comandi dei dispositivi
Quando crei un'applicazione IoT, devi avere la possibilità di interagire con il dispositivo
tramite comandi in remoto. Un esempio nel settore industriale consiste nell'utilizzare
comandi remoti per richiedere dati specifici da un'apparecchiatura. Un esempio di utilizzo
nel settore della casa intelligente consiste nell'utilizzare comandi remoti per pianificare
un sistema di allarme in remoto.
11Amazon Web Services Canone di architettura AWS - IoT Lens
Con AWS IoT Core, puoi implementare comandi utilizzando argomenti MQTT o AWS IoT
Device Shadow per inviare comandi a un dispositivo e ricevere una conferma quando un
dispositivo ha eseguito il comando. Utilizza gli argomenti Device Shadow su MQTT per
implementare i comandi. Device Shadow offre diversi vantaggi rispetto all'utilizzo di
argomenti MQTT standard, per esempio un clientToken, per monitorare l'origine di una
richiesta, i numeri di versione per la gestione della risoluzione dei conflitti e la possibilità
di archiviare comandi nel cloud nel caso in cui un dispositivo sia offline e non sia in grado
di ricevere il comando quando viene emesso. La copia shadow del dispositivo viene
comunemente utilizzata nei casi in cui un comando deve essere mantenuto nel cloud anche
se il dispositivo non è attualmente online. Quando il dispositivo torna online, il dispositivo
d
richiede le informazioni shadow più recenti ed esegue il comando.
i v e
c h
Figura 3: utilizzo di un broker di messaggi per inviare comandi a un dispositivo.
r
Servizio Device Shadow AWS IoT
A
Le soluzioni IoT che utilizzano il servizio Device Shadow in AWS IoT Core gestiscono le
richieste dei comandi in modo affidabile, scalabile e semplice. Il servizio Device Shadow segue
un approccio prescrittivo alla gestione dello stato correlato al dispositivo e alla modalità di
comunicazione dello stato. Questo approccio descrive in che modo il servizio Device Shadow
utilizza un documento JSON per archiviare lo stato corrente di un dispositivo, lo stato futuro
desiderato e la differenza tra gli stati correnti e quelli desiderati.
12Amazon Web Services Canone di architettura AWS - IoT Lens
d
Figura 4: utilizzo di Device Shadow con i dispositivi.
e
1. Un dispositivo segnala lo stato iniziale pubblicandolo come messaggio
nell'argomento deviceID/shadow/update.
v
2. Device Shadow legge il messaggio dall'argomento e registra lo stato del dispositivo
i
in un datastore persistente.
3. Un dispositivo sottoscrive l'argomento di messaggistica
h
delta deviceId/shadow/update/delta a cui arrivano i messaggi di modifica dello
stato relativi al dispositivo.
c
4. Un componente della soluzione pubblica un messaggio di stato desiderato
r
nell'argomento deviceID/shadow/update e il Device Shadow che monitora
lo stato desiderato del dispositivo in un datastore persistente.
A
5. Device Shadow pubblica un messaggio delta
nell'argomento deviceId/shadow/update/delta e il broker di messaggi invia
il messaggio al dispositivo.
6. Un dispositivo riceve il messaggio delta ed esegue le modifiche di stato desiderate.
7. Un dispositivo pubblica un messaggio di conferma che riflette il nuovo stato
nell'argomento di aggiornamento deviceID/shadow/update e Device Shadow che
monitora il nuovo stato in un datastore persistente.
8. Device Shadow pubblica un messaggio
nell'argomento deviceId/shadow/update/accepted.
9. Un componente della soluzione ora può richiedere lo stato aggiornato da Device Shadow.
13Amazon Web Services Canone di architettura AWS - IoT Lens
Aggiornamenti firmware
Tutte le soluzioni IoT devono consentire gli aggiornamenti del firmware dei dispositivi.
Il supporto degli aggiornamenti del firmware senza intervento manuale è fondamentale
per la sicurezza, la scalabilità e l'offerta di nuove funzionalità.
AWS IoT Device Management offre un modo semplice e sicuro per gestire le distribuzioni IoT,
tra cui l'esecuzione e il monitoraggio dello stato degli aggiornamenti del firmware. AWS IoT
Device Management utilizza il protocollo MQTT con il broker di messaggi AWS IoT e AWS IoT
Jobs per inviare comandi di aggiornamento del firmware ai dispositivi e per ricevere lo stato
di tali aggiornamenti firmware nel corso del tempo.
d
Una soluzione IoT deve implementare gli aggiornamenti del firmware utilizzando AWS IoT Jobs
e
mostrato nel seguente diagramma per fornire questa funzionalità.
h i v
rc
A
Figura 5: Aggiornamento del firmware sui dispositivi.
1. Un dispositivo sottoscrive l'argomento di notifica del processo IoT
deviceId/jobs/notify-next al quale arrivano i messaggi di notifica del processo IoT.
2. Un dispositivo pubblica un messaggio in deviceId/jobs/start-accanto per
avviare il processo successivo e ottenere il processo successivo, il relativo documento
del processo e altri dettagli, tra cui qualsiasi stato salvato in statusDetails.
3. Il servizio AWS IoT Jobs recupera il documento di processo successivo per il dispositivo
specifico e invia questo documento all'argomento sottoscritto
deviceId/jobs/start-next/accepted.
4. Un dispositivo esegue le operazioni specificate dal documento del processo utilizzando
l'argomento MQTT deviceId/jobs/jobId/update per segnalare l'avanzamento
del processo.
14Amazon Web Services Canone di architettura AWS - IoT Lens
5. Durante il processo di aggiornamento, un dispositivo scarica il firmware utilizzando
un URL prefirmato per Amazon S3. Utilizza la firma del codice per convalidare il
firmware durante il caricamento ad Amazon S3. Utilizzando la firma del codice del
firmware, il dispositivo finale può verificare l'autenticità del firmware prima
dell'installazione. I dispositivi Amazon FreeRTOS possono scaricare l'immagine del
firmware direttamente tramite MQTT per evitare una connessione HTTPS separata.
6. Il dispositivo pubblica un messaggio di stato di aggiornamento nell'argomento del
processo deviceId/jobs/jobId/update che segnala l'esito positivo o negativo.
7. Poiché lo stato di esecuzione di questo processo è cambiato in stato finale, il processo
d
IoT successivo disponibile per l'esecuzione (se presente) cambierà.
e
I pilastri del Canone di architettura
v
Questa sezione descrive ciascuno dei pilastri e include definizioni, best practice, domande,
i
considerazioni e servizi AWS chiave rilevanti per la progettazione di soluzioni per IoT.
Pilastro di eccellenza operativa
h
Il pilastro dell'eccellenza operativa include le prassi operative e le procedure utilizzate
c
per gestire i carichi di lavoro di produzione. L'eccellenza operativa comprende il modo in cui
vengono eseguite le modifiche pianificate, nonché le risposte a eventi operativi imprevisti.
r
L'esecuzione delle modifiche e le risposte devono essere automatizzate. Tutti i processi
e le procedure relative all'eccellenza operativa devono essere documentati, testati
A
e revisionati regolarmente.
Principi di progettazione
Oltre ai principi generali di progettazione dell'eccellenza operativa del canone di architettura,
esistono cinque principi di progettazione per l'eccellenza operativa per l'IoT nel cloud:
Piano per il provisioning dei dispositivi: progetta il processo di provisioning dei
dispositivi per creare l'identità iniziale del dispositivo in un luogo sicuro. Implementa
un'infrastruttura a chiave pubblica (PKI) responsabile della distribuzione di certificati
univoci ai dispositivi IoT. Come descritto in precedenza, la selezione dell'hardware di
crittografia con una chiave privata e un certificato pregenerati elimina i costi operativi
dell'esecuzione di una PKI. In caso contrario, la PKI può essere eseguita offline con un
modulo di sicurezza hardware (HSM) durante il processo di produzione o durante il
processo di bootstrap del dispositivo. Utilizza tecnologie in grado di gestire l'autorità
di certificazione (CA) e l'HSM nel cloud.
15Amazon Web Services Canone di architettura AWS - IoT Lens
Implementazione del processo di bootstrap dei dispositivi: anche i dispositivi che
supportano la personalizzazione da parte di un tecnico (nel settore industriale) o di
un utente (nel settore consumatore) possono essere sottoposti a provisioning. Per
esempio, un'applicazione per smartphone che interagisce con il dispositivo tramite
Bluetooth LE e con il cloud tramite Wi-Fi. È necessario progettare la possibilità per
i dispositivi di aggiornare in modo programmatico le informazioni di configurazione
utilizzando un'API di bootstrap distribuita a livello globale. Una progettazione
di bootstrap garantisce che sia possibile inviare in modo programmatico le nuove
impostazioni di configurazione del dispositivo tramite il cloud. Queste modifiche
devono includere impostazioni quali l'endpoint IoT con cui comunicare, la frequenza
d
con cui inviare uno stato generale per il dispositivo e le impostazioni di sicurezza
aggiornate, per esempio i certificati del server. Il processo di bootstrap supera il
provisioning iniziale e svolge un ruolo fondamentale nelle operazioni dei dispositivi
e
fornendo un modo programmatico per aggiornarne la configurazione tramite il cloud.
v
Modelli di comunicazione dei dispositivi documenti: in un'applicazione IoT, il
i
comportamento dei dispositivi è documentato manualmente a livello di hardware.
Nel cloud, un team operativo deve formulare il modo in cui il comportamento di
un dispositivo verrà dimensionato una volta distribuito a una flotta di dispositivi.
h
Un cloud engineer deve esaminare i modelli di comunicazione dei dispositivi ed
estrapolare il traffico totale previsto in entrata e in uscita dei dati dei dispositivi e
c
determinare l'infrastruttura prevista necessaria nel cloud per supportare l'intera flotta.
Durante la pianificazione operativa, questi modelli devono essere misurati utilizzando
r
i parametri lato dispositivo e lato cloud per garantire che i modelli di utilizzo previsti
vengano soddisfatti nel sistema.
A
Implementazione di aggiornamenti OTA (Over the Air): per trarre vantaggio dagli
investimenti hardware a lungo termine, è necessario poter aggiornare continuamente
il firmware sui dispositivi con nuove funzionalità. Nel cloud, puoi applicare un processo
di aggiornamento del firmware che ti consente di indirizzare dispositivi specifici per
gli aggiornamenti del firmware, implementare le modifiche nel corso del tempo,
monitorare il funzionamento e gli errori degli aggiornamenti, avere la possibilità di
eseguire il rollback o interrompere le modifiche del firmware in base alle KPI.
Implementazione di test funzionali su asset fisici: hardware e firmware dei dispositivi
IoT devono essere sottoposti a test rigorosi prima di essere distribuiti sul campo.
L'accettazione e i test funzionali sono fondamentali per il percorso di produzione.
L'obiettivo dei test funzionali è eseguire componenti hardware, firmware incorporato
e software applicativi dei dispositivi attraverso scenari di test rigorosi, per esempio
connettività intermittente, ridotta o guasto dei sensori periferici, profilando al
contempo le prestazioni dell'hardware. I test garantiscono che il dispositivo IoT
funzioni come previsto durante la distribuzione.
16Amazon Web Services Canone di architettura AWS - IoT Lens
Definizione
Esistono tre aree di best practice per l'eccellenza operativa nel cloud:
1. Preparazione
2. Operatività
3. Evoluzione
Oltre a quanto incluso nel canone di architettura relativamente a processi, runbook e giorni
di gioco, esistono alcune aree specifiche da esaminare per ottenere l'eccellenza operativa
nelle applicazioni serverless.
d
Best practice
e
Preparazione
v
Per le applicazioni IoT, la necessità di acquistare, effettuare il provisioning, testare e
i
distribuire hardware in diversi ambienti significa che la preparazione all'eccellenza operativa
deve essere espansa per occuparsi di aspetti della distribuzione che saranno eseguiti
h
principalmente su dispositivi fisici e non sul cloud. I parametri operativi devono essere definiti
per misurare e migliorare i risultati aziendali e quindi determinare se i dispositivi devono
c
generare e inviare tali parametri all'applicazione IoT. È inoltre necessario pianificare
l'eccellenza operativa creando un processo ottimizzato di test funzionali che consenta
r
di simulare il comportamento dei dispositivi nei diversi ambienti.
È essenziale chiedersi come garantire che i carichi di lavoro IoT siano resilienti ai guasti,
A
come i dispositivi possano ripristinare automaticamente dai problemi senza l'intervento
umano e come l'applicazione IoT basata sul cloud si ridimensionerà per soddisfare le esigenze
di un carico sempre crescente di hardware connesso.
Con una piattaforma IoT, hai la possibilità di utilizzare componenti e strumenti aggiuntivi per
gestire le operazioni IoT. Questi strumenti includono servizi che consentono di monitorare e
ispezionare il comportamento dei dispositivi, acquisire parametri di connettività, effettuare il
provisioning di dispositivi utilizzando identità univoche ed eseguire analisi a lungo termine sui
dati dei dispositivi.
IOTOPS 1. Quali fattori determinano le priorità operative?
IOTOPS 2. In che modo è possibile garantire di essere pronti
a supportare le operazioni dei dispositivi del carico di lavoro IoT?
IOTOPS 3. In che modo si garantisce che i nuovi dispositivi con
provisioning abbiano i prerequisiti operativi richiesti?
17Amazon Web Services Canone di architettura AWS - IoT Lens
La sicurezza logica per IoT e data center è simile poiché per entrambi è coinvolta
prevalentemente l'autenticazione da macchina a macchina. Tuttavia, differiscono nel fatto
che i dispositivi IoT vengono spesso distribuiti in ambienti che non possono essere considerati
fisicamente sicuri. Le applicazioni IoT spesso richiedono anche dati sensibili per utilizzare
Internet. Per questo è fondamentale disporre di un'architettura che determini il modo in cui
i dispositivi acquisiscono un'identità in modo sicuro, possano dimostrare continuamente la
loro identità, essere acquisiti con il livello appropriato di metadati, siano organizzati e
categorizzati per il monitoraggio e abilitati con il giusto insieme di autorizzazioni.
Per applicazioni IoT scalabili e di successo, i processi di gestione devono essere automatizzati,
basati sui dati e sui comportamenti precedenti, attuali e previsti del dispositivo. Le
d
applicazioni IoT devono supportare strategie di rollout e rollback incrementali. Se il piano
di efficienza operativa comprende tutti questi aspetti, sarai in grado di avviare
e
un'applicazione IoT efficiente e tollerante ai guasti.
In AWS IoT, è possibile utilizzare più caratteristiche per effettuare il provisioning delle identità dei
v
singoli dispositivi firmate dalla CA nel cloud. Questo percorso prevede il provisioning di dispositivi
i
con identità e quindi l'utilizzo di just-in-time-provisioning (JITP), just-in-time-registration (JITR)
o Bring Your Own Certificate (BYOC) per registrare in modo sicuro i certificati dei dispositivi nel
h
cloud. Grazie a servizi AWS quali Route 53, Amazon API Gateway, Lambda e DynamoDB, verrà
creata una semplice interfaccia API per estendere il processo di provisioning con il processo di
c
bootstrap dei dispositivi.
r
Operatività
In IoT, lo stato operativo supera lo stato operativo dell'applicazione cloud e si estende alla
capacità di misurare, monitorare, rilevare problemi e aggiustare i dispositivi che fanno parte
A
dell'applicazione, ma distribuiti in remoto da posizioni che potrebbero essere difficili o
impossibili da gestire localmente. Questa necessità delle operazioni remote deve essere
considerato in fase di progettazione e implementazione per garantire la capacità di
ispezionare, analizzare e agire sui parametri inviati da questi dispositivi remoti.
In IoT, è necessario stabilire i parametri di comportamento di base corretti per i dispositivi,
essere in grado di aggregare e dedurre i problemi che si verificano su più dispositivi e disporre
di un piano di risoluzione solido che non venga eseguito solo nel cloud, ma anche su parte del
firmware del dispositivo. È necessario implementare un'ampia gamma di canary di
simulazione dei dispositivi che testino in modo continuo le interazioni dei dispositivi comuni
direttamente sul sistema di produzione. Le canary dei dispositivi aiutano a restringere le aree
potenziali per indagare quando i parametri operativi non vengono soddisfatti. Le canary dei
dispositivi possono essere utilizzate per generare allarmi preventivi quando i parametri
scendono al di sotto del contratto sul livello di servizio previsto.
In AWS, puoi creare un oggetto AWS IoT per ogni dispositivo fisico nel registro dei dispositivi
di AWS IoT Core. Creando un oggetto nel registro, è possibile associare metadati a dispositivi,
gruppi di dispositivi e configurare le autorizzazioni di sicurezza per i dispositivi. Un oggetto
18Amazon Web Services Canone di architettura AWS - IoT Lens
AWS IoT deve essere utilizzato per archiviare i dati statici nel registro degli oggetti mentre
memorizza i dati dei dispositivi dinamici nella copia shadow del dispositivo associata
all'oggetto. La copia shadow di un dispositivo è un documento JSON utilizzato per archiviare
e recuperare le informazioni sullo stato di un dispositivo.
Oltre a creare una rappresentazione virtuale del dispositivo nel registro dei dispositivi, come
parte del processo operativo, è necessario creare tipi di oggetto che incapsulano attributi
statici simili che definiscano i dispositivi IoT. Un tipo di oggetto è analogo alla classificazione
del prodotto per un dispositivo. La combinazione di oggetto, tipo di oggetto e device shadow
può fungere da primo punto di ingresso per l'archiviazione di metadati importanti da
utilizzare per le operazioni IoT.
d
In AWS IoT, i gruppi di oggetti consentono di gestire i dispositivi per categoria. I gruppi possono
e
anche contenere altri gruppi, consentendo di creare gerarchie. Con la struttura organizzativa
nell'applicazione IoT, puoi identificare rapidamente e agire sui dispositivi correlati per gruppo di
dispositivi. L'utilizzo del cloud consente di automatizzare l'aggiunta o la rimozione di dispositivi
v
dai gruppi in base alla logica di business e al ciclo di vita dei dispositivi.
i
In IoT, i dispositivi creano messaggi di telemetria o diagnostica che non vengono archiviati nel
registro o nella copia shadow del dispositivo. Questi messaggi vengono invece inviati ad
h
AWS IoT utilizzando una serie di argomenti MQTT. Per rendere questi dati fruibili, utilizza
il motore di regole AWS IoT per instradare i messaggi di errore al processo di remediation
c
automatizzato e aggiungere informazioni di diagnostica ai messaggi IoT. Di seguito
è riportato un esempio di come instradare un messaggio contenente un codice di stato
r
di errore a un flusso di lavoro personalizzato. Il motore di regole ispeziona lo stato di un
messaggio e, se si tratta di un errore, avvia il flusso di lavoro Step Function per correggere
A
il dispositivo in base al payload dei dettagli del messaggio di errore.
{
"sql": "SELECT * FROM 'command/iot/response WHERE code =
'eror'",
"ruleDisabled": false,
"description": "Error Handling Workflow",
"awsIotSqlVersion": "2016-03-23",
"actions": [{
"stepFunctions": {
"executionNamePrefix": "errorExecution",
"stateMachineName": "errorStateMachine",
"roleArn":
"arn:aws:iam::123456789012:role/aws_iot_step_functions"
}
}]
}
19Amazon Web Services Canone di architettura AWS - IoT Lens
Per supportare informazioni operative sulla tua applicazione cloud, genera pannelli di controllo
per tutti i parametri raccolti dal broker di dispositivi di AWS IoT Core. Questi parametri sono
disponibili tramite CloudWatch Metrics. Inoltre, CloudWatch Logs contiene informazioni quali il
totale dei messaggi in entrata, i messaggi in uscita, la connettività e gli errori.
Per potenziare le distribuzioni dei dispositivi di produzione, implementa simulazioni IoT
su Amazon Elastic Compute Cloud (Amazon EC2) come contenitori di dispositivi in diverse
regioni AWS. Questi canary del dispositivo sono responsabili del mirroring di diversi casi d'uso
aziendali, per esempio la simulazione di condizioni di errore come transazioni di lunga durata,
l'invio di telemetria e l'implementazione di operazioni di controllo. Il framework di
simulazione dei dispositivi deve generare parametri estesi, inclusi, a titolo esemplificativo,
d
operazioni riuscite, errori, latenza e ordinamento dei dispositivi e poi trasmettere tutti
i parametri al sistema operativo.
e
Oltre ai pannelli di controllo personalizzati, AWS IoT fornisce informazioni a livello di parco
istanze e di dispositivo basate sul registro oggetti e sul servizio Device Shadow tramite
v
funzionalità di ricerca come AWS IoT Fleet Indexing. La possibilità di eseguire ricerche
i
all'interno del parco istanze semplifica l'overhead operativo della diagnosi dei problemi IoT,
indipendentemente dal fatto che si verifichino a livello di dispositivo o a livello di parco istanze.
h
Evoluzione
c
IOTOPS 4. In che modo evolve la tua applicazione IoT con un impatto minimo
r
sui dispositivi IoT downstream?
A
Le soluzioni IoT spesso implicano una combinazione di dispositivi a basso consumo, ubicazioni
remote, larghezza di banda ridotta e connettività di rete intermittente. Ognuno di questi
fattori pone sfide di comunicazione, tra cui l'aggiornamento del firmware. Pertanto, è
importante per incorporare e implementare un processo di aggiornamento IoT che riduca
al minimo l'impatto sui dispositivi e sulle operazioni a valle. Oltre a ridurre l'impatto a valle,
i dispositivi devono essere resilienti alle problematiche comuni esistenti negli ambienti locali,
come la connettività di rete intermittente e la perdita di alimentazione. Utilizza una
combinazione di raggruppamenti di dispositivi IoT per la distribuzione e gli aggiornamenti del
firmware in un determinato periodo di tempo. Monitora il comportamento dei dispositivi man
mano che vengono aggiornati nel campo e procedi solo dopo che una percentuale di
dispositivi è stata aggiornata correttamente.
Utilizza AWS IoT Device Management per creare gruppi di distribuzione di dispositivi e
distribuire aggiornamenti OTA (Over the Air) a gruppi di dispositivi specifici. Durante gli
aggiornamenti, continua a raccogliere tutti i messaggi di attività di CloudWatch Logs,
telemetria e dispositivi IoT, combinare tali informazioni con i KPI utilizzati per misurare
l'integrità generale delle applicazioni e le prestazioni di qualsiasi canary di lunga durata.
20Puoi anche leggere
