In un sistema connesso, è necessario pianificare attentamente quale dispositivo dovrebbe fornire quali funzionalità e come dovrebbero interagire tra loro. Esempi:

• Quali operazioni vengono eseguite su un termostato ambiente o sul relativo regolatore di riscaldamento?
• Quali dati dovrebbero essere memorizzati direttamente nella memoria elettronica di un regolatore di caldaia, su una scheda SD o su un server cloud?
• Quale percorso prende i dati attraverso il sistema, per esempio dal dispositivo A attraverso il dispositivo B al dispositivo C, o direttamente da A a C?
• Quali dispositivi dovrebbero avere una propria interfaccia utente, e come saranno gestiti i dispositivi senza un’interfaccia propria? (vedi anche Smartphone come dispositivi operativi per sistemi HVAC)

Oltre agli effetti tecnici, la composizione è anche cruciale per la percezione dell’usabilità. In effetti, un importante determinante dell’usabilità è la corrispondenza tra la composizione e il modello mentale dell’utente – cioè la comprensione di quale dispositivo lui si aspetta che una certa funzionalità sia presente, e come si relaziona con gli altri dispositivi.

Più il comportamento del sistema corrisponde al modello mentale dell’utente, maggiore è l’usabilità. D’altra parte, più l’utente deve riqualificare il suo modello mentale a causa di un comportamento deviante del sistema, più paga una lezione.

I sistemi connessi spesso contengono diversi dispositivi con la propria interfaccia utente. Se questi devono lavorare insieme da un produttore all’altro, come nei sistemi di smart home o nel patchwork di un locale caldaia gradualmente aggiornato, questo di solito risulta in interfacce utente completamente diverse. Poiché ogni produttore di componenti persegue la propria filosofia, questo è difficile da risolvere.

All’interno di una gamma di prodotti complementari sviluppati dallo stesso produttore (o di una rete di cooperazione gestibile), le condizioni per un concetto operativo coerente sono molto migliori, ma sono anche tanto più attese dall’utente.

L’aspetto della consistenza si riferisce alla terminologia uniforme, al simbolismo e all’architettura dell’interazione su più dispositivi. Dovrebbe essere intuitivamente chiaro all’utente come diverse parole, situazioni o azioni si relazionano tra loro. Ciò che è chiamato “Automatico” nella centralina di riscaldamento, è abbreviato con un simbolo A sul termostato ambientale ed è chiamato “On” in un’app può tecnicamente significare la stessa funzione, ma richiede che l’utente abbia una comprensione più profonda di come funziona ogni parte del sistema per poterlo dedurre con certezza.

In pratica, spesso sorgono conflitti tra diverse forme di consistenza. Quando si progetta un’app, per esempio, ha senso adottare le convenzioni del sistema operativo per la progettazione di pulsanti e campi di input.

Per esempio, rappresentare un interruttore analogico su uno smartphone sembrerebbe estremamente goffo. Sostituirlo con un pulsante tipico di Android o iOS, tuttavia, sacrificherebbe la consistenza tra il dispositivo e l’app associata, cioè all’interno del portafoglio del nostro produttore di esempio.

Un buon compromesso potrebbe essere quello di prendere in considerazione le convenzioni della piattaforma di iOS o Android, ma di riflettere elementi caratteristici del nucleo, come un certo schema di colori o la forma circolare di una rotella analogica.

Quando si scambiano dati, ci sono sempre tempi di latenza, perdite occasionali di pacchetti di dati o inaccessibilità temporanea di singoli componenti (vedi anche Le 8 sfide per lo sviluppo di prodotti collegati per la climatizzazione). Ogni volta che questo si traduce in brevi interruzioni, è presente un problema di continuità.

Mentre la continuità è una delle maggiori sfide in molte parti dell’Internet of Things, la maggior parte delle applicazioni della tecnologia di riscaldamento sono fortunatamente abbastanza tolleranti in questo senso.

Questo è in parte perché la funzionalità del sistema di solito non è significativamente influenzata da brevi interruzioni di pochi secondi o addirittura minuti. D’altra parte, perché l’interazione umana con un sistema di riscaldamento è piuttosto sporadica. In confronto, con molti dispositivi elettronici di consumo connessi, come l’ascolto della musica via Bluetooth o lo streaming di Netflix via Smart TV, anche le più brevi interruzioni del sistema possono interrompere massicciamente l’esperienza dell’utente.

A causa dell’elevato sforzo tecnico, dei costi unitari più elevati e delle interazioni con altre caratteristiche del prodotto, non è possibile né desiderabile escludere ogni possibile anomalia. Questi sono parte inevitabile di un sistema connesso.

Ciononostante, è responsabilità dello sviluppo del prodotto prevenire i disturbi nel miglior modo possibile in prima istanza e progettare in modo intelligente l’esperienza dell’utente per i problemi di continuità rimanenti in seconda istanza. In dettaglio:

Prevenzione

Gli sviluppatori di prodotti devono rendere i loro sistemi e i loro componenti sufficientemente robusti per garantire la sicurezza operativa e la funzionalità fondamentale del sistema in ogni momento. Tra le innumerevoli decisioni di progettazione che hanno un’influenza su questo, ecco una selezione di possibili leve:

1. Includere tentativi per ripristinare automaticamente le connessioni perse
2. Rilevamento dei pacchetti di dati persi, reinvio automatico e/o trasmissione ridondante dei dati per compensare le perdite di singoli pacchetti.
3. In applicazioni con una tolleranza piuttosto bassa per la latenza, la composizione del sistema può essere influenzata a favore di percorsi di trasmissione brevi. Regola empirica: più la funzionalità è disponibile localmente, più breve è la latenza. È quindi più breve se la funzionalità richiesta si trova localmente sul dispositivo stesso. Leggermente più lunga se viene trasmessa all’interno di una rete locale. Più lunga se deve essere richiesta attraverso reti esterne come il cloud. Gli sviluppatori di prodotti dovrebbero quindi definire i tempi di latenza massimi tollerabili e incorporarli nella progettazione del sistema.
4. Scegliere le giuste tecnologie di comunicazione. Per esempio, poiché il bus LIN è ottimizzato per brevi distanze di trasmissione e piccole quantità di dati, il CAN bus o il Modbus sarebbero la scelta migliore per linee più lunghe o quantità di dati maggiori. La comunicazione cablata ha generalmente una maggiore sicurezza di trasmissione rispetto a quella wireless (vedi anche Cablato o wireless?), e così via. Poiché ogni tecnologia di comunicazione ha i suoi pro e contro, deve soprattutto adattarsi all’applicazione per fornire la migliore affidabilità operativa possibile.
5. Scelta appropriata della struttura della rete.
   Le topologie a stella possono compensare il guasto di alcuni dispositivi meglio delle topologie ad anello o ad albero, a condizione che il nodo centrale non sia colpito. Le reti mesh offrono la massima affidabilità funzionale.
6. Buona selezione dei componenti elettronici. I componenti di memoria i cui cicli di lettura e scrittura si esauriscono rapidamente nel contesto di una data applicazione possono portare a guasti prematuri, per esempio a causa di una vita utile molto ridotta. I condensatori progettati per il settore industriale piuttosto che per quello dei consumatori sono più costosi, ma soddisfano classi di temperatura più elevate e offrono quindi una migliore affidabilità funzionale e una maggiore longevità. E così via.
7. Layout elettronico per ridurre le interferenze esterne e le proprie emissioni di interferenze almeno secondo la direttiva europea EMC.
8. Software ad alte prestazioni. Il multithreading programmato in modo inadeguato, cioè l’elaborazione parallela di diversi thread di esecuzione, aumenta il rischio di sovraccaricare il processore o la memoria principale e di perdere pacchetti di dati.
9. Fornire scenari di fallback sicuri.

Modellare l’esperienza dell’utente

Ogni volta che si verificano problemi di continuità, gli utenti dovrebbero essere ampiamente protetti dagli effetti di brevi interruzioni non critiche. Possibili leve:

1. Permettere al sistema tempi di attesa più lunghi o un numero maggiore di tentativi di connessione prima di suggerire all’utente un fallimento con un messaggio di errore.
2. Includere scenari pragmatici di fallback
3. Gestione graduale del problema a seconda del tempo di risposta del sistema. Regola empirica: Un tempo di reazione di 0,1 secondi dovrebbe essere raggiunto per mantenere l’impressione di un effetto immediato. Tempi di reazione tra 0,1 e 1 secondo possono già sembrare imbarazzanti. Sopra 1 secondo, si dovrebbe pensare a un feedback intermedio, con il quale l’utente riconosce che la sua interazione è stata registrata. Per esempio, sotto forma di una schermata di caricamento, o adottando visivamente la pressione del suo pulsante, anche se il sistema è ancora occupato a eseguirlo in background.