I termini “Internet delle cose” e “Industria 4.0” descrivono una visione di mondo connesso, ma non spiegano come realizzarla tecnicamente. Il vero pilastro è l’esistenza di protocolli di comunicazione affidabili, efficienti e sicuri come MQTT.
Architettura Pub/Sub — il modello centrale di MQTT, con publishers (sensori, PLC, telecamere) che inviano dati a un broker centrale, e subscribers (SCADA, cloud, dashboard) che li ricevono in modo totalmente disaccoppiato.
Il diagramma mostra la struttura a tre colonne dell’architettura MQTT:
A sinistra i publisher — dispositivi fisici (sensori, PLC, gateway, telecamere) che inviano messaggi ciascuno su un proprio topic. Al centro il broker, che riceve tutti i messaggi, li smista per topic e applica QoS, retain e autenticazione. A destra i subscriber — applicazioni come SCADA, cloud analytics e dashboard — che si abbonano a topic specifici. In MQTT, un topic è come il “nome del canale” su cui viaggiano i messaggi. Esempio di topic: sede/magazzino/temperatura. Esempio di pubblicazione MQTT: Topic: sede/magazzino/temperatura Messaggio: 18.7
Vuol dire che un sensore, come il termometro web , sta inviando la temperatura del magazzino della sede operativa. Una applicazione che appartiene ai subscriber (colonna a destra) può usare questo dato per regolare la temperatura, storicizzare i dati, allarmare la manutenzione. Publisher e subscriber non sono legati direttamente. Puoi aggiungere un nuovo subscriber senza toccare nessun publisher, MQTT è leggero per progetto ma con una architettura flessibile e scalabile.
MQTT semplifica lo scambio di dati tra dispositivi industriali, software e piattaforme IoT: i Web-IO pubblicano stati e misure su topic dedicati, mentre i sistemi interessati ricevono solo le informazioni a cui sono sottoscritti.
Single Pair Ethernet (SPE) è il nuovo standard Ethernet per l’Industria 4.0 e l’Internet delle Cose industriale (IIoT). Grazie ai molteplici vantaggi è considerata particolarmente efficiente e innovativa ed è adatta per una serie di applicazioni industriali, di processo e di automazione degli edifici.
Dal sensore fino al cloud
Il nuovo standard SPE consente una comunicazione continua mediante protocollo TCP/IP su tutti i livelli, dal sensore fino al cloud (da OT ad IT). La trasmissione dati unificata sotto un unico insieme di protocolli implica semplificazione, ad esempio non sono più necessary gateway di protocollo, ed una riduzione dei colli di bottiglia nello scambio dei dati.
Copertura di lunghe distanze
Lo standard SPE consente lunghezze di cavo fino a 1000m senza ripetitori, per IEEE 802.3cg 10BASE-T1L. Ciò amplia notevolmente la potenziale estensione delle reti industriali basate su TCP/IP. Si veda qui un utile Estensore di rete che utilizza 10BASE-T1L. La massima distanza permessa, accanto ad una connessione dati affidabile e ad alte prestazioni, riduce la complessità delle applicazioni esistenti, consentendo nuove dimensioni della comunicazione dati industriale in settori che necessitano di coprire grandi distanze. Gli impianti con lunghezze di cavi di oltre 100 metri dipendevano finora dall’impiego di ripetitori, che grazie alla lunghezza possibile dei cavi SPE non sono più necessari. Grazie all’uso di un semplice doppino è anche possibile riusare cablaggi esistenti per bus di campo (4..20mA, CAN, Profibus PA) o in alcuni casi impianti citofonici.
Single Pair Ethernet 10BASE-T1L
Ethernet 100BASE-TX
Bus di Campo
Doppino
1
2 (in cavo UTP o STP)
1 o 2
Lunghezza ammessa
1000m
100m
da 400 a 1000m
Bandwidth
10Mb/s
100Mb/s
da 0,015 a 10MB/s
Protocollo
TCP/IP
TCP/IP
Proprietari
Gateway?
Non necessari
Necessari
Necessari
Ripetitori?
Non necessari
Necessari
Non necessari
Alimentazione mediante doppino SPE: PoDL o SPoE
Oltre alla comunicazione continua, un ulteriore vantaggio dello standard SPE è la possibilità di alimentare periferiche grazie alla tecnologia Power over Data Line e SPoE: Single-Pair Power over Ethernet. Attraverso la linea dati avviene al contempo l’alimentazione di corrente dei dispositivi (I)IoT, dei sensori e di altri componenti collegati senza ulteriori prestazioni. Ciò significa una notevole riduzione della complessità nell’architettura dell’applicazione come anche del mero cablaggio necessario.
Perché OPC UA è stato adottato come lo standard IoT per l’Industria 4.0?
Internet è ormai onnipresente, ma sebbene Ethernet consenta agli oggetti (Things) di “raggiungersi” a vicenda, per essere utili hanno bisogno di un linguaggio comune per comunicare in modo significativo. L’acronimo OPC sta per Open Platform Communications. OPC è uno standard di interoperabilità che consente uno scambio dati sicuro e affidabile nell’ambito dell’automazione industriale ed altri settori. OPC è una piattaforma completamente indipendente che permette lo scambio dati senza ostacoli, tra più dispositivi di diversi fornitori. OPC UA è uno standard aperto che non dipende né si lega a tecnologie proprietarie o a singoli costruttori. Pertanto, tutte le comunicazioni OPC UA sono indipendenti al 100 % dai fornitori che le implementano, dai linguaggi di programmazione utilizzati sui dispositivi e dalle piattaforme su cui girano i prodotti. È scalabile dal sensore al cloud.
OPC UA lavora secondo il principio client/server e non solo.
Per lo scambio dati tra client e server è stato scelto TCP/IP, il protocollo di rete più diffuso al mondo ed Ethernet come standard per il livello fisico. A differenza da alti bus di campo un Server può accettare richiesta da uno o più Client.
OPC UA distingue tra tre varianti di trasmissione:
HTTP Attraverso richieste HTTP sono inviati e richiesti dati. Le informazioni vengono trasmesse con formattazione SOAP e XML. La porta server TCP è la 80.
HTTPS Per HTTPS vale lo stesso come per HTTP, però funziona con crittografia HTTPS SSL/TLS. La porta server TCP è la 443.
TCP Binary La variante binary rinuncia all’overhead che sorge attraverso i tag XML supplementari. Al suo posto c’è un protocollo molto snello che regola lo scambio di dati. In questo modo lo scambio di dati è notevolmente più rapido. La porta server TCP è la 4840.
Quali tipo di dati sono scambiati mediante OPC?
Dati in tempo reale
Dati storici (log)
Eventi ed allarmi
Retrofit per macchine che non supportano OPC UA
Industria 4.0 e IoT acquisiscono sempre più importanza nel contesto produttivo, per riunire dati di processo di componenti di diversi produttori in modo uniforme nel contesto industriale a livello di controllo. Ma molti controlli, CNC e macchine non dispongono della connettività di rete necessaria. Per le macchine più vecchie vengono in genere segnalati stati operativi semplicemente mediante contatti. Con i Web-IO è possibile monitorare e rilevare tali contatti attraverso il server OPC UA integrato del livello di controllo e qui ulteriormente elaborati.
I segnali elettrici a 24V cc sono da decenni lo standard per i circuiti di controllo industriali comprendenti PLC, sensori, contatti ed attuatori. Lo specifico valore di 24Vdc è emerso come standard de facto a partire dagli anni 50, a scapito di altri livelli di tensione come 115Vac e 24Vac, per una somma di diverse motivazioni tecniche che andiamo ad elencare, ed anche per l’uso di tale tensione su apparecchiature e mezzi aero-navali militari.
Motivazioni Tecniche
Immunità ai disturbi: i segnali a 24 V dc sono relativamente immuni ai disturbi elettrici e alle interferenze che si verificano comunemente negli ambienti industriali dove sono presenti motori elettrici e commutazione di carichi elettrici che generano interferenze elettriche . Ciò rende i segnali più stabili e affidabili, ad esempio rispetto ai segnali 5V, migliorando l’affidabilità del sistema di controllo.
Sicurezza: 24 VDC è un livello di tensione sicuro. Fornisce una tensione sufficiente per alimentare sensori, attuatori e altri dispositivi senza comportare rischi elettrici per l’uomo. Tensioni più elevate potrebbero essere pericolose in caso di contatto accidentale.
Economicità: I componenti (BJT all’inizio) necessari per ingressi ed uscite digitali a 24V dc erano più convenienti rispetto a quelli necessari per altri livelli di tensione.
Bassa “impronta” energetica: Il funzionamento a 24V c.c. permette di eccitare un relè di potenza con bobina a 24V con pochi mA. Ciò permette di usare cavi di segnale di diametro ridotto e di poter piazzare il relè a distanza dal controllore, Risparmiando così sul costo del cavo ed avendo poche perdite di tensione e potenza sui circuiti di comando.
In sintesi l’uso della tensione 24V CC per i circuiti di controllo industriali offriva ed offre il miglior compromesso tra sicurezza elettrica, immunità ai disturbi, costo, compatibilità ed è diventata lo standard de facto per i circuiti di controllo industriali comprendenti PLC, sensori, contatti ed attuatori.
Da standard di fatto (market-driven standard) a norma
Per avere dei riferimenti più stabili e precisi la maggiore organizzazione mondiale nel campo elettrotecnico/elettronico ha normato molti ambiti delle applicazioni PLC e controllori industriali con la norma IEC 61131 del 1993. In particolare la seconda parte di questa norma, la IEC 61131-2, specifica requisiti fisici sugli ingressi ed uscite dei controllori programmabili; vengono definiti i livelli e le soglie per gli ingressi e le uscite digitali, si veda ad esempio le uscite del controllore OEM BB536.
HCE, attiva nella progettazione e produzione di sistemi elettronici integrati, è lieta di annunciare l’estensione della disponibilità in produzione per la famiglia A71/A72 di System-on-Module (Som) basati sulla cpu NXP(R) i.MX 7. La disponibilità della cpu i.MX 7 è stata inserita da NXP(R) nel programma di longevità estesa fino al 2035, garantendo un eccellente tempo di vita per microprocessori basati su Cortex-A7. La serie di Som A71/A72 è usata in sistemi di edge computing, gateway, automazione industriale. Per maggiori informazioni sul SoM tipo A71 si veda la relativa pagina prodotto
In data 19/07/2023 HCE Engineering Srl è lieta di informare sul rilascio di una nuova versione del BSP Yocto per A73 Enigma, System on Module basato su STM32MP157. Il kernel adottato è la versione 5.15 per fornire un maggiore supporto di driver e di aggiornamenti di sicurezza per risolvere le eventuali vulnerabilità. Filesystem: Yocto Kirkstone (basato su OpenSTLinux) U-Boot: versione 2021.10 personalizzato per SoM A73
One of the most important things we should take into account when we decide to develop a new embedded system are all possible functioning conditions where our device will be used by customers. For an user of a desktop PC is quite normal asking to execute a shutdown procedure before powering off his/her system, but for an user of an embedded system this is not true at all! In fact embedded system such as ADSL modems, wifi access points or repeaters, printers (even if some printers require to execute proper shutdown) ecc. are simply disconnected from power supply by their users without any shutdown procedure.
However these devices are all GNU/Linux based as far as our Desktop PC (I know, Windows rules on PCs! But this is true at least for my PC) so how we can assure that the file system of our embedded device and its applications will continue functioning at next boot? What can prevent a system failure in case of power failure?
Well to do so we have to consider several techniques to help the embedded system we’re currently developing in tolerate a catastrophic event as a power failure. We can use four major different solution levels.
Hardware solutions
Hardware solutions are quite expensive respect to a fully software solution but is some circumstances we cannot do without them at all! We must consider them in case our application is so important that it must continue running even in case of power failure.
A first solution is to use a battery (or a super capacitor). With a battery our system will work even without main power supply but, in order to have everything under control, we should have a special signal that informs the CPU about the power failure so the system will have the time to do a safe and controlled power off. The advantage of this solution is that we can implement it even if our system haven’t a dedicated low power modes of functioning (as reducing its main CPU clock for instance which is required in case the system should continue functioning on battery power) but it simply needs to manage an interrupt line which can be used to signal an userland process to start the shutdwon procedure when power gets low. A drawback of this approach is that batteries will require periodic testing and replacement with age in order to assure enough time to do the shutdown procedure safely.
Another important thing to do is knowing the characteristics of the storage devices we’re going to use on the system. For instance if we decide to use hard disks we should consider that some of them ignore cache flush commands from the OS, while we had cases where some models of SD cards or USB mass storage devices would corrupt themselves during a power failure, but industrial models (such as eMMC) did not have this problem (unluckily this information was not always published in the datasheet, and had to be gathered by experimental testing). That’s why some developers decide to not use devices as SD or eMMC (or similar) but to use directly flash chips instead. This because, even if all these devices are (NAND) flash based, SD cards and eMMC chips have a dedicated and not open source controller while if we use bare NAND flash chips we can put over them a well know and open source controller. The final result is the same, a Linux block device where we can mount a file system but the way we get it is completely different!
From the developer point of view both devices are seen as block devices bused on NAND flash but the former is closed source while the latter is open source!
Bootloader solutions
To help us in system recovering can came in action the bootloader too. It usually is a piece of software complex enough to understand when the system is not able to do a correct boot procedure. In this case we can use the bootloader to do some automatic or manual activated steps that can restore a working settings.
As first thing to do is setting up our bootloader in such a way it can detect presence of a USB mass storage disk or a microSD and, if so, to boot from those devices. In this manner we can easily start an alternate system which in turn can reset our system to a well defined factory configuration (note that this procedure can also be executed by pressing a key or other techniques).
Another thing we can do is to program a watchdog system that can reset our board if not continuously refreshed due a failure condition (e.g. an unmountable root file system or a main application crash), then the bootloader, during the new reboot, can detect this condition and then starting a recovery procedure as above to resolve the problem.
Kernel solutions
When we must keep system cost low but we cannot effort expenses for a battery we still can have a good fail-save system simply by using some precautions into the kernel.
First of all we have to use a journaling file system, that is a file system that can tolerate incomplete writes due to power failure, OS crash, etc. Most modern filesystems are journaled, but we have to choose the right one. In fact we have to select the right filesystem according to the block device we have on our system. For block devices like hard disks, SD cards, eMMC chips and USB mass storage devices we can use Linux’s Ext4 file system, while for NAND flash chips we should use something like JFFS2 or (better) UBIFS.
In any case, unless our application needs the write performance, we should disable all write caching (check isk drivers for caching options) so consider mounting the filesystem in sync mode.
Another step that can increase system fault tolerance is trying to keep as far as possible application executables and operating system files on their own read-only partition(s) while read/write data should be on its own writable partition. Doing like this even if our application data gets corrupted, the system should still be able to boot (albeit with a fail safe default configuration).
However in some circumstances keeping the root file system read-only is not easy (for instance whhen we decide to use a standard distribution) that’s way we can decide to use some tricks to keep the root file system writable but protecting anyway our important files:
We can opening individual files as read-only (e.g. by using something like fp = fopen("configuration.ini", "r")).
We can use file mode bits and then setting important files as read-only (e.g. with chmod command used as chmod a=r configuration.ini).
We can initially mount a partition as read-only and then remounting it as read-write when we need to write data (e.g. by using mount -o remount,rw /).
We can use file system overlay to mount as read-only whole filesystem and then turning it read/write again but putting on it a transparent layer where we can put our modifications.
This last solution is very tricky since allow us to have a read-only file system with on top a read/write transparent layer which in turn allows us to see every file on lower read-only layer as it was read/writeable!
In the above figure we have a physical disk splitted into two partition: the first one holds all files needed to our system to work while the second one can be completely void. Once we mount partition 2 in read/write mode over partition 1 as read-only as overlay what we get is a logical disk mounted in read/write mode where when we write a file we put it into partition 2 while when we read it we get its contents from partition 2 if it exists there, otherwise we go in deep e we get the contents from partition 1.
The advantage of this solution is that we can wipe out all modification and return to factory settings at once just deleting partition 2!
Another solution can use, as second partition of the above example, a RAM disk so that temporary files are store into RAM. If we keep those writes off-disk we eliminate them as a potential source of corruption and we also reduce flash wear and tear. The disadvantage is that each time we reboot the system all modifications (if not saved elsewhere) will vanish.
Application solution
Even if we’re going to use whatever we saw before we still take into account that also our custom application should avoid bad operations may vanish any hardware or kernel effort.
Let’s suppose we are using a journaling filesystem on a system which has no batteries, in this situation we should think that we’re safe since, even without the battery support, our file system is safe. Well, this is certainly sure but having a journaling file system do NOT mean that we cannot loose our data! In fact if we have an important file (for example a configuration file or a database file) we periodically update and, during one of these updates, the power fails we can be sure that the file system will not be corrupted but our file will be truncated for sure!
To avoid this possibility the first thick we can do is considering to do write operations in a well defined order in such way that our data will not be lost. An example of bad code is the following:
fp = fopen("configuration.ini", "w+"));
ret = fread(buf, rsize, 1, fp);
/* modify data in buf */
ret = fwrite(buf, wsize, 1, fp);
While a good code is the following:
fpr = fopen("configuration.ini", "r"));
ret = fread(buf, rsize, 1, fpr);
fclose(fpr);
/* modify data in buf */
fpw = fopen("configuration.ini.new", "w"));
ret = fwrite(buf, wsize, 1, fpw);
if (ret != wsize) { /* error! */
} else {
fclose(fpw);
ret = fmove("configuration.ini", "configuration.ini.old");
if (ret > 0)
ret = fmove("configuration.ini.new", "configuration.ini");
}
In this manner we are sure that in any case we have a copy of our data (that is the new modified version or the the old not-yet modified one) we can recover in case of power failure.
In order to be able to recover as gracefully as possible our system we should also maintain at least two copies of its configuration settings, a primary and a backup. If the primary fails for some reason, switch to the backup. Also we should consider mechanisms for making backups whenever whenever the configuration is changed or after a configuration has been declared good by the user. Do you have a Boot Loader or other method to restore the OS and application after a failure? 7e. Make sure your system will beep, flash an LED, or something to indicate to the user what happened.
Conclusions
There are several things we can do to resolve or (better) to avoid a system failure due a power loss and they can be used in different manners so the best thing to do is using our experience to know when enhancing the hardware is mandatory or when we can solve all our problems by using a software solution only.
Replicare segnali di IO digitale attraverso la rete
La modalità Box-to-Box collega due Web-IO attraverso la rete. In questa modalità di funzionamento le uscite di un Web-IO seguono lo stato degli ingressi di un altro Web-IO. Ad esempio lo stato alto su un ingresso di un Web-IO commuta l’uscita del corrispettivo Web-IO posto in una diversa locazione. In questa modalità si possono sostituire dei cablaggi discreti mediante comunicazione Ethernet industriale, realizzando una automazione decentralizzata I/O ed una economia nel caso di lunghe distanze.
La soluzione Box-to-Box funziona anche su reti diverse passando attraverso i router.
I collegamenti box-to-box sono garantiti dal protocollo TCP. In caso di perdita temporanea di connessione, per esempio a causa di un guasto alla rete, i Web-IO si ritrovano fra loro senza interventi dei manutentori IT.
In caso di perdita di connessione le uscite assumono lo stato di sicurezza (livello alto o basso) che è possibile configurare.
La trasmissione dei segnali analogici per il controllo di processo ha uno standard de-facto nel 4..20mA Current Loop. Questo tipo di segnale risale agli anni 50 ed è ancora molto usato nonostante la moltitudine di fieldbus digitali alternativi per i suoi vantaggi intrinseci ed il basso costo:
1) La lunghezza del cablaggio non conta
L’opportunità di avere un segnale trasmesso in corrente invece che in tensione in tutti i casi in cui non sia nota a priori la lunghezza del cablaggio è nota. La corrente in una maglia unica è la stessa in tutti i punti del circuito qualunque sia la lunghezza del cablaggio, ciò non è più vero per le tensioni.Ogni conduttore reale presenta una resistenza per unità di lunghezza. Più lungo è il cavo, maggiore è la resistenza. Corrente*Resistenza=caduta di tensione (perdita) sul cablaggio.Così, se una sorgente di segnale può essere 10V o 20mA ad esempio, le perdite sul cablaggio comporteranno una tensione inferiore misurata all’ingresso del ricevitore mentre la corrente rimarrà invariata al 100%, quindi 20mA.Una configurazione molto comune è quella di avere la sorgente di controllo della corrente (0-100% segnale diventa 4-20mA), che si chiude su una resistenza da 250ohm al ricevitore, il risultato interno all’elettronica del ricevitore è un comodo ed affidabile segnale da 1-5V su cui operare.
2) Con un cablaggio a due fili posso trasmettere sia l’alimentazione che i dati del sensore.
3) Una linea di segnale analogica in corrente è maggiormente immune di un segnale in tensione.
Un sensore ha anche una bassa potenza, il suo segnale analogico 0..10V di uscita “port” poca corrente, quindi richiede una resistenza di ingresso del ricevitore piuttosto elevata (ordine anche dei Mega Ohm). Rumori e disturbi EMI inducono correnti non volute. Se queste correnti indotte, per quanto basse, finiscono su una resistenza elevata il disturbo risultante sarà molto più elevato dell’effetto in un circuito con segnale in corrente dove le tensioni sono tipicamente delle centinaia di Ohm.
4) Il segnale fuori norma può essere interpretato come allarme.
Se il ricevitore rileva 0mA significa che il cablaggio con il sensore è interrotto.È anche possibile programmare il sensore in modo da regolare la corrente d’anello su livelli fuori intervallo in caso di guasto. Ad esempio 3,5 e 23 mA. In questo modo, il current loop può notificare al sistema l’errore del sensore.
Ci sono diverse possibili configurazioni circuitali per il current loop, quella che riunisce tutti i vantaggi descritti e che è la più usata è illustrata nella figura seguente:
Il blocco a destra nelle figura è tradizionalmente incluso nel modulo di ingresso analogico di un PLC. Con i moderni sistemi di automazione lo stesso blocco può essere accessibile da remoto via Internet. Si veda ad esempio il Web-IO Analogico 57761.
Costruisci, installa e sviluppa i tuoi circuiti tramite tutorial passo-passo ed utilizza questa guida piena di esempi pratici per accedere a diversi tipi di periferiche per monitorare e controllare il tuo ambiente domestico. Il libro è stato scritto dal nostro Co-Chief e Senior Software Engineer Rodolfo Giometti – Feb 2016 – 378 pagine
Caratteristiche principali
Costruire, installare e sviluppare circuiti tramite tutorial passo-passo ed esempi pratici, dalla configurazione iniziale alla gestione driver di periferica
Accedi a diversi tipi di periferiche per computer per monitorare e controllare il proprio ambiente domestico utilizzando questa guida
Questo libro si sviluppa attraverso 10 capitoli tutti concentrati su di un unico progetto pratico di automazione domestica
Descrizione libro
La BeagleBone è un mini PC dove gira Linux. Può connettersi a Internet e può eseguire diversi sistemi operativi come Android e Ubuntu. La BeagleBone viene utilizzata per una varietà di scopi diversi, da progetti semplici come la costruzione di un termostato a quelli più avanzati come sistemi di sicurezza della casa. Ricco di esempi reali, questo libro vi fornirà esempi di come collegare diversi sensori e ed attuatori alla BeagleBone Black. Imparerete come accedere ad essi al fine di realizzare sistemi di monitoraggio e controllo dai più semplici a quelli più complessi che vi permetteranno di prendere il controllo della casa. Troverete anche esempi software per implementare interfacce web utilizzando PHP/HTML e JavaScript, e come utilizzare le API per interagire con un account Google Docs, WhatsApp o Facebook. Questa guida è un tutorial prezioso se si prevede di utilizzare un BeagleBone Black in un progetto di automazione domestica.
Cosa si può imparare
Costruire un rilevatore di CO (e di altri gas) con un allarme acustico e LED per segnalare alte concentrazioni
Registrare dati ambientali e tracciarli graficamente
Sviluppare una semplice interfaccia web con una piattaforma LAMP
Preparare interfacce web complesse in JavaScript e come fare un flusso di dati video da una webcam
Utilizzare delle API per ottenere l’accesso a un account Google Docs o un account WhatsApp/Facebook per gestire un sistema di automazione domestica
Aggiungere un driver personalizzato per gestire un LED con diverse frequenze di lampeggiamento
Scoprire come lavorare con vari componenti elettronici per costruire piccoli circuiti
Utilizzare un NFS, sensori di temperatura, relè e altre periferiche per monitorare e controllare l’ambiente circostante
Now we can enlarge time’s characters by using figlet utility. This tool reads from stdin (or on the command line) a string and reproduces it on stdout using ASCII-art as below:
