AO_409

OTTOBRE 2018 AUTOMAZIONE OGGI 409 92 AO CONTROLLO E GESTIONE ma molti progettisti la utilizzano ora in applicazioni industriali e di automazione degli edifici. Il grande vantaggio di richiedere solo due linee di dati, combinato a un protocollo con tolleranza ai guasti e alla possibilità di comunicare anche su grandi distanze, rende CAN particolarmente interessante per la comunicazione tra controllori di zona e sensori e attuatori. • Quad SPI: o Qspi, è un’estensione dell’interfaccia SPI, con quat- tro linee di dati e un protocollo maggiormente regolato. Questa interfaccia supporta throughput di dati molto elevati (diverse decine di megab- yte al secondo). I progettisti la utilizzano per interfacciare i sistemi a memorie esterne mediante una quantità ridotta di I/O allocati sull’MCU, in particolare rispetto alle interfacce parallele. Colle- gando il controllore di zona a memorie più grandi tramite questa interfaccia è possibile non solo archiviare i dati per pagine web e immagini sul controllore, ma anche registrare quantità di dati molto superiori ai limiti della memoria interna del dispositivo. • Interfaccia seriale periferica (SPI): è un’interfaccia veloce con soli tre segnali di linea, più un segnale di abilitazione per ogni slave. Per questa interfaccia si devono utilizzare percorsi di comunicazione brevi, in modo che tutti i dispositivi collegati a questo bus si trovino sullo stesso circuito stampato. • RS485: è identico a Uart, ma supporta distanze maggiori tra i dispositivi e diversi dispositivi sul bus RS485. • Ricevitore/trasmettitore asincrono universale (Uart): questa classica interfaccia è facile da implementare e viene spesso utilizzata per scopi di debug, sebbene sia utilizzabile anche per il collegamento di semplici sensori. Alcuni progettisti usano l’interfaccia Uart come canale di dati tra due controllori. Il punto di forza di Uart è l’ingom- bro ridotto in termini di software e hardware. Questa interfaccia supporta solo connessioni punto-punto ed è pertanto limitata alla comunicazione tra due dispositivi tramite istanza hardware (con qualche intervento sono possibili alcune eccezioni). I protocolli per l’automazione cablata degli edifici sono general- mente basati su interfacce seriali come RS485 o Ethernet per una comunicazione veloce. I protocolli più rilevanti sono Bacnet, Lon- Mark e Modbus. Nello specifico, Bacnet è uno standard di comunicazione aperto per l’automazione e il controllo degli edifici (BAC), definito e monitorato da Ashrae (società americana dei tecnici del riscal- damento, della refrigerazione e del condizionamento dell’aria). È ora accettato come standard internazionale, riconosciuto dall’ISO come 16484-5. LonMark è invece uno standard basato sul pro- tocollo di comunicazione proprietario LonTalk, che stabilisce una serie di regole per gestire le comunicazioni tra i dispositivi. LonWorks definisce il contenuto e la struttura delle informazioni scambiate. Come Bacnet, anche LonWorks è stato accettato e adottato dalle organizzazioni internazionali di normazione, in particolare come Ansi/CEA 709.1 (American National Standards Institute/Consumer Electronics Association) e Ieee 1473-L. Infine, lo standard aperto Modbus è uno dei protocolli più ampiamente utilizzati negli ambienti di produzione industriale. La sua struttura di messaggistica stabilisce comunicazioni master/slave e client/ server tra i dispositivi. Per consentire agli sviluppatori di integrare velocemente que- sta enorme varietà di interfacce di comunicazione è necessario uno stack di driver ben progettato, per astrarre il livello hardware da quello applicativo (si veda Figura 4). I progettisti di software possono così concentrarsi direttamente sul livello del protocollo, senza doversi occupare del livello di implementazione hardware. Altre aspetti importanti Nel caso siano richieste ulteriori opzioni di accesso a reti wi- reless, la gamma di interfacce di un controllore di zona dovrà includere anche standard di protocollo e comunicazione come Bluetooth Low Energy, Zigbee o wi-fi. Per integrare in modo rapido e completo queste interfacce di rete wireless nell’archi- tettura software di un controllore di zona è tuttavia necessario uno stack software progettato in modo adeguato e certificato. L’archiviazione e il trattamento dei dati su un’unità di elabora- zione centrale (CPU) remota in hosting, spesso definiti come cloud computing, stanno ricevendo sempre più attenzione e saranno una funzionalità chiave nella prossima generazione di queste applicazioni. Anche le librerie software hanno un ruolo importante per la realizzazione di una soluzione completa. L’integrazione nel cloud richiede non solo una connessione In- ternet, ma anche una libreria di funzioni con un’interfaccia di programmazione delle applicazioni (API) ben strutturata per accedere ai servizi web cloud, supportata dagli MCU integrati nel controllore di zona. Molte applicazioni complesse agiscono come interfacce di co- municazione e scambio dati. Un controllore di zona dimostra quanti componenti devono interagire tra loro. Oltre a un MCU adeguato, in grado di supportare protocolli multipli, è infatti necessaria una struttura di driver e librerie che consenta alle varie interfacce di interagire perfettamente senza interferenze reciproche. Il livello di astrazione hardware e gli stack di driver integrati in un sistema operativo in tempo reale (Rtos) sono parti essenziali, ma anche l’estensione ai protocolli wireless richiede supporto. I pro- gettisti che non tengono in considerazione questi aspetti potreb- bero trovarsi ad affrontare un enorme lavoro di sviluppo software e, nel peggiore dei casi, una completa riprogettazione. • Texas Instruments - www.ti.com Fig. 4 - Implementazione di livelli software per l’astrazione dell’hardware