Archivi categoria: Automazione Industriale

Automazione Industriale, Informatica

INDUSTRY 4.0

Revisione 0.05

L’ Automazione Industriale annovera la sua quarta rivoluzione e diventa il Sistema di Informazione Automatica che visualizza e controlla l’intera Linea di Produzione.

Le Industrie potenziano i macchinari, mediante sensori ed attuatori, per creare ed accentrare il flusso di informazioni dalle macchine.

La nuova tendenza supera la classica automazione per includere cyber-physical systems (CPS), internet of things (IoT), industrial internet of things (IIOT), cloud computing, cognitive computing e artificial intelligence.

L’ Industria 4.0 aggrega i concetti di:

Lo scenario attuale vede Industrie con macchinari isolati e dotati di tecnologicamente modesti, ma costosi e poco pratici processori e controllori locali. I dati restano legati alle singole macchine, non sono resi omogenei ed accentrati nel Sistema Centrale per l’Automazione Industriale 4.0.

Le Aziende che producono ed assistono le macchine usate nell’industria sono in pratica riluttanti nell’adottare uno standard per la comunicazione ed il tipo dati.

Nel contesto Operatori d’Eccellenza si muovono sul campo, superando le gravi difficoltà presenti, per dotare ogni singola macchina della capacità di creare ed inviare i dati nel Sistema Centrale per l’Automazione Industriale 4.0.

Questi operatori, rari e di grande talento, si muovono sul campo, installano sensori, attuatori, processori, e cablaggi per la creazione e la convergenza dell’informazione. E’ inevitabile la costruzione e sperimentazione di nuovi sistemi compatti, ed è ovvio siano ARM Board con Touch Panel, per comunicare con PLC locali oppure la nuova elettronica installata. Requisito dell’Industry 4.0, secondo la visione originaria tedesca del 2012, è il progressivo abbandono di protocolli seriali per l’adozione di protocolli di rete compatibili con Internet, e quindi, in breve, TCP. Emerge, in modo strategico, il nuovo ruolo del MODBUS TCP.

L’informazione così creata dal basso, costituita dalle rilevazioni, è la materia grezza per la filiera che definisce l’Industria 4.0.

Queste rilevazioni possono essere aggregate seguendo un approccio dal basso, ma dovranno essere, nel contesto pregiato, messe in relazione, come si usa dire dall’alto, per esempio, alle distinte base.

Così creando il contesto virtuoso di raccordo tra i dati della produzione, dal basso o dal campo, con i dati provenienti dall’area di gestione, che comprende anche amministrazione, progettazione e direzione.

Le rilevazioni affinché siano fruibili convergono in un Sistema Informatico Centrale per l’Automazione dell’Industria 4.0. Sistema dotato di molti servizi, ma il più strategico è il RDBMS.

E’ possibile costruire il Sistema per l’Automazione 4.0 parti di Sistemi Dipartimentali di eccellenza, quali UNIX Linux Ubuntu Server 64 LTS e RDBMS PostgreSQL.

Costruito e reso stabile il flusso dei dati dal basso, si sperimentano varie aggregazioni per meglio capire quali siano gli obiettivi da raggiungere e come procedere per il grande passo, ovvero il raccordo dei dati dall’alto. Passo che si realizza mediante la costruzione di specifiche gestioni.

Gestioni che permettono di definire i componenti accessori da adottare o costruire, per esempio servizi di notifica, report, cruscotti. Gestioni che possono essere realizzate in molteplici modi, ma si possono elencare alcuni ovvi vincoli:

  • lo sviluppo deve essere rapido, RAD e quindi visuale
  • la gestione dati massiva o bigdata con tabelle di appoggio locali
  • facilmente installabili, runtime minimi, meglio solo desktop e quindi serverless
  • create per essere utilizzate con il parco computer più usato
  • devono gestire molte centinaia di tabelle con widgets correlati
  • devono prevedere tre flussi di dati:
    • query da RDBMS con download di record
    • elaborazioni in locale, per esempio aggregazioni in tabelle di appoggio
    • upload di record, nel caso di gestione e non semplice monitoraggio.

Nel contesto odierno forse l’unica possibilità praticabile è creare App Microsoft Classiche.

Articoli correlati:

Arduino, Automazione Industriale, Domotica, Informatica

Arduino sketch: gestione automatica.

Il progetto LABijk ha alcuni aspetti molto ambiziosi. Uno di questi è archiviare nel database le caratteristiche di ogni dispositivo microcontrollere, sensore od attuatore per poter generare in automatico il firmware di ogni microcontrollore.

In ambito Debian ed Ubuntu cominciamo ad introdurre dalla compilazione all’upload a riga di comando del firmware nelle schede Arduino.

Si inizi aggiornando l’ambiente:

apt-get update

poi si proceda installando i primi programmi necessari allo scopo:

apt-get install arduino picom python-setuptools

in seguito si installi il gestore librerie di Python 2.7:

easy_install-2.7 pip

Infine si installi la libreria Python ino:

pip install ino

Controlliamo i moduli installati dal framework ino:

ino list-modules

Se la risposta è positiva allora possiamo cominciare con il primo esempio, che chiamiamo lab000.

Creiamo la cartella lab000 che svolge il compito di essere la cartella base:

mkdir lab000

ci posizioniamo nella cartella

cd lab000

Quindi creiamo il progetto per Arduino

ino init

Il precedente comando crea due cartelle: src che contiene gli sketch e lib che contiene le libreire.

Completiamo la sorgente sketch.ino ed infine compiliamo per l’Atmel

ino build

per caricare il nuovo firmware, collegare la scheda Arduino alla USB ed avviare

ino upload

In prossimi articoli cominceremo a creare la struttura dati e il programma che genera in automatico ogni sketch di una specifica applicazione LABijk.

 

Arduino, Automazione Industriale, Domotica, Elettronica, Informatica

Bus a confronto: RS 485, CAN, I2C e SPI

Ringrazio Marco M. che riapre il diabattito proponendo CAN bus come  alternativa al bus RS485.

CAN è il bus utilizzato nelle automobili moderne, negli apparecchi elettromedicali e nell’industria.

Sicuramente alza di molto il profilo e quindi va provato.

Ma il grande problema è nei costi alti, per esempio, la sicuramente ottima scheda della SparkFun CAN-BUS Shield DEV-10039 sarebbe un’eccellente scelta ma costa più del doppio della scheda microcontroller.

Un po’ di tempo fa volevo avviare dei test soprattutto verso il bus dell’automobile.

E’ interessante il post tratto dalla pagina del prodotto Sparkfun:

“If you are using this board to actually create a CAN bus system (as I am for a robotic drone vehicle) then the skpang (designer of this board) code is not that helpful and a bit of a mess. It is well and good to be able to read things from your vehicle and log them, but that’s not helpful when you are trying to create an actual bus.Also, I really find it difficult when sample code does every conceivable thing all at once, forcing you to piece out the parts/understanding you need.

To create a network of senders and receivers, I tried a few different libraries. I recommend using the CANDUINO one http://code.google.com/p/canduino). Although the boards are not exactly the same, it will work, and you can see a sender and receiver working. Other libraries I tried, such as the one from saeed studios, didn’t work for me, even though their boards are pin compatible. Might have something to do with their library using a CAN interrupt which, for me, was not reliable. Receiver would get only a single CAN message and then the interrupt would never fire again. Who knows why. Spent a number of hours on this.

So just want to save other folks some time if they are looking to build an actual bus system, and not just read data from their vehicles.”

Canduino

 

 

La scheda utilizza il componente elettronico MCP2515 che si collega verso Arduino mediante SPI.

La porta SPI, che è una seriale molto veloce adatta per esempio per collegare CAM SPI, ma apre alcune problematiche spinose con Arduino: non rientra nel contesto usuale gestire più di una SPI, che viene utilizzata in modo esclusivo da atre periferiche quali lettore SD oppure (aut) dalla scheda ethernet. E’ noto che chi ha utilizzato l’ethernet shield, il programma che inserisce non può aprire contemporaneamente la scheda rete e un file in SD.

 

La gestione SPI su Arduino è piuttosto complessa.

L’alternativa è usare I2C o wire, bus molto più lento, creato dalla Philips come seriale veloce per interconnettere componenti elettronici, per esempio la scheda madre con i suoi sensori. Ma si aprono molte problematiche: le tensioni in gioco sono i 3.3 o i 5V e sono piuttosto delicate, è delicato convertire il segnale tra tensioni, il cavo non può superare grossomodo il metro e mezzo, un componente instabile sul bus può compromettere la comunicazione, …

Molti invece sono i motivi a favore del I2C: è il più diffuso bus tra componenti elettronici, quindi ci si apre alla comunicazione con l’elettronica, la libreria I2C per Arduino è abbastanza stabile,   Grove ha un HUB per I2C per Arduino, ….

twigi2cs.jpg

Arduino gestisce in origine la seriale usata per comunicare verso USB, PIN 2 e 3,  con il secondo microcontroller a board (il vecchio chip FTDI è superato).

La libreria seriale poi è stata affiancata da una libreria migliore che permette di gestire più coppie di pin in contemporanea, quindi avere più seriali TTL. Il chip MAX485 incanala la coppia di PIN al bus RS485.

Il segnale è bilanciato, collaudatissimo, può arrivare a 1200 metri, richiede due resistenze di terminazione. Le velocità sono quelle della seriale. Il protocollo è da perfezionare.

Arduino, ARM, Automazione Industriale, Building Automation, Domotica, Elettronica, Hardware, Informatica, Open Source, Raspberry PI

Perchè Arduino SMD ai livelli “ij” nel progetto LABijk

Il progetto LABijk è ambizioso, ma fattibile. Le applicazioni nel mondo elettrico e non solo,  per esempio nel condizionamento di ambienti, sono molteplici.

Il livello i è costituito dai microcontroller direttamente connessi al microserver.

Le connessioni previste sono USB od ethernet.

Una ARM board sarebbe nettamente migliore, ma

  • scalda un po’ e se chiusa in una piccola scatola di policarbonato ci possono essere grandi problemi
  • i costi che, escluso il caso ethernet, vede Arduino vincente; Raspberry PI sarebbe vincente, ma il filesystem su micro SD lo rende fragile; quindi le board ARM candidabili andrebbero sopra i 60€ a pezzo contro i 20€ circa di Uno SMD
  • nel caso di collegamento USB è da preferirsi, per ora, Arduino UNO SMD per i costi e per la robustezza già testata in pooling su USB; in tecnologia SMD per lo stato dell’arte
  • nel caso di ethernet è meglio un ARM non solo per i costi che diventano equivalenti, ma per la gestione ethernet molto debole su Arduino: poche connessioni e senza threading/forking controllabile
  • in futuro è prevedibile, si veda Arduino Due, la convergenza ad ARM

Mel caso di livello j allora non vi è dubbio che l’Arduino SMD sia l’unica soluzione:

  • 12 MHz garantiscono che non scalda anche se inscatolato
  • è robustissimo, prodotto su tiratura mondiale in enormi quantità
  • è Elettronica Aperta
  • la comunità da sviluppatori ad adepti è enorme
  • la documentazione, raggiungibile via internet, è la più vasta in assoluto
  • si apre perfettamente ad ogni elettronica, si pensi che al tempo dell’esplosione di Fukushima entro pochi giorni erano già pronti shield Arduino per contatori Geiger anche reperibili dal mercato giapponese
  • è perfetto per un centro stella seriale RS485
  • permette l’utilizzo dei shield Groove creando uno standard imponente verso l’elettronica e l’elettricità, basti pensare che non serve più il saldatore, ci si muove con plug e senza crimpare
  • il costo, sui venti euro, lo rendono imbattibile
  • ultimo ma non ultimo il progetto è italiano e viene venduto in grandi numeri  anche in Germania, Stati Uniti, Cina e Giappone.

Arduino, ARM, Automazione Industriale, Building Automation, Domotica, Hardware, Informatica, Linux Embedded

Progetto automazione LABijk

Il progetto è ambizioso, fattibile e di qualità.

Estrapoliamo alcuni punti che rendano un certo profilo:

  • l’utilizzo di un microserver, a livello di root, con CPU tipo AMD E350 (a bassi consumi, da sostituire, nel 2014, con ARM A53 o 57), un vero disco fisso, meglio RAID 1,  e sistema operativo Linux fascia server, che permetta di realizzare comunicazioni professionali verso internet, dispositivi mobili …
  • microserver con un vero RDBMS relazionale di fascia alta che contenga ogni informazione coinvolta, anche storica; stiamo valutando gli ottimi MariaDB oppure PostgreSQL
  • microserver con infrastruttura software interamente sviluppata in C, compreso le applicazioni fastCGI per Apache e le app per i dispositivi mobili; quindi la pesante filiera HTML5 viene scalzata per intero, riducendo le richieste di potenze di processo anche di un ordine, aumentando enormemente l’affidabilità, acquistando velocità anche con CPU ridotte
  • le tratte microserver – microprocessori livello i, sono realizzate collegamenti USB od ethernet, con comandi a stringa e, nel caso ethernet, in stile telnet; quindi connessioni veloci, molto collaudate, tradizionali ed estremamente affidabili
  • i microcontroller a livello i sono Arduino, ma potranno diventare schede ARM quando il consumo sarà così ridotto da non surriscaldare uno spazio angusto sigillato; oppure se è richiesta una maggior potenza di calcolo con un Linux Embedded
  • la tratta i – j viene realizzata con la solidissima RS 485
  • i microprocessori di livello j sono Arduino quindi solidissimi, economi, a consumo minimo (alcuni watt) con lo shield Grove fantastico e, non trascurabile, frutto di menti capaci italiane
  • le connessioni j – k sono preferibilmente Grove ovvero fantastiche per la semplicità di cablaggio
  • la matrice (i,j,k) permette di individuare ogni elemento in relazione agli altri e quindi, se microcontroller Arduino, di fissare le caretteristiche in  modo automatico nel firmware
  • e molto altro
Arduino, ARM, Automazione Industriale, Building Automation, Domotica, Elettronica, Informatica, PostgreSQL

Progetto automazione LABijk. Revisione 1.

Il progetto intende promuovere tecnologie open source ed open electronics.

Si supponga di voler gestire sensori ed attuatori.

Poniamo al centro un microserver, con sistema operativo Linux Server, eventualmente connesso ad internet ed a reti locali.

Questa macchina archivia un resoconto di tutto quello che viene fatto e comunica con tablet, telefoni ed altri sistemi anche attraverso internet. Abbiamo già dato alcune indicazioni sulle possibili scelte in articoli precedenti.

Distinguiamo tre livelli, per l’appunto i, j e k di aggregazione dispositivi.

Alla radice poniamo il microserver.

I primi nodi, di livello i, siano microcontroller Arduino SMD Uno o Ethernet, connessi al microserver via USB o ethernet. Le schede Arduino siano dotate  dispositivi adattatori seriali RS485.

Il secondo livello, detto j,  è costituito da dispositivi Arduino SMD UNO con shield Grove e connessi al padre mediante seriale.

Al terzo livello, detto k, poniamo attuatori e sensori connessi ai padre mediante cavi Grove, oppure cavi multipolari a 4 capi, schermati o non, telefonici o di rete. Lo standard Grove può essere convertito da adattatori nel formato RJ13 per cavi telefonici o RJ45 per usuali cavi ethernet.

Ogni dispositivo è individuato da coordinate i.0.0 oppure i.j.0 oppure i.j.k

I comandi sono del tipo i.j.k:<comando:valore,…> 

Il microserver è dotato di servizio che interroga costantemente in pool i dispositivi di livello i, mediante USB. Un secondo servizio che è simile al precedente ma per i dispostivi connessi mediante rete.

I dispostivi Arduino di coordinate i sono in ascolto verso il microserver, quindi USB o socket, ed anche interrogano il pool dei figli connessi mediante seriale.

I dispositvi di livello j sono in ascolto verso i dispositivi padri ed eseguono l’interrogazione in pool dei sensori, o meglio le entrate,  oppure cambiano lo stato delle uscite.

Nel microserver esiste un database “automazione” con le tabelle

  • “comandi”, contenente record corrispondente a comandi da eseguire
  • “stati” che contiene lo stato attuale di ogni dispositivo
  • “cambio_stati” che contiene cambiamenti di stati eventualmente da elaborare
  • “pianificazioni” che contiene operazioni pianificate

Il microserver esegue un servizio che interroga  in pool i dispositivi di livello i e riporta comandi e cambiamenti di stato nelle tabelle corrispondenti.

Un secondo servizio legge i cambiamenti di stato, consulta le tabelle di correlazione e scrive i comandi da eseguire nella tabella comandi.

Un terzo legge la tabella comandi e instrada il comando nel ramo corretto.

Tutto è riportato in tabelle e viene a costituire in sistema three-tier architecture, con pilastri di appoggio quali PostgreSQL, Apache, OpenSSH, Postfix, …

Precisiamo che

  • i cambiamenti di stato sono riportati nella tabella “cambio_stati”
  • i comandi con destinazione di coordinate valide sono instradati verso i destinatari
  • le risposte ritornano al microserver che chiude il comando ed aggiunge eventuali cambio stati.

Consideriamo un semplice esempio.

Supponiamo di avere un sistema di dimensione 5.3.5 ovvero al microserver sono connessi 5 dispositivi con il ruolo di HUB RS485, ad ognuno di questi sono connessi al più 3 dispositivi di livello j con HUB Grove, ad ognuno di questi al più 5 sensori o attuatori.

I dispositivi di livello j sono dotati di firmware che permette di sapere e gestire perfettamente i sensori od attuatori ad essi connessi. Inoltre questi dispositivi sono in pool rispetto i sensori ed attuatori.

Consideriamo il dispositivo di livello j di coordinate 3.2.

Supponiamo che abbia 2 attuatori ed un sensore di coordinate 3.2.3.

Il sensore sia un interrutore bistabile (entrata a due stati).

Ora se l’interrutore viene azionato e cambia stato, il dispositvo 3.2.0 costruisce il cambio stato 3.2.3:on (ma meglio introdurre la notazione definitiva  3.2.1:1 ) ed instrada il cambio stato al padre, il quale lo riporta al microserver che lo scrive nella tabella cambio stato.

Il servizio predisposto, nel microserver, rielabora secondo tabelle di correlazione il cambio stato, che viene elaborato, ovvero chiuso e crea gli opportuni comandi.

Mel nostro esempio il comando è 3.2.1:on  ma meglio  3.2.1:1

Quindi il servizio legge il comando e lo instada al dispositivo 3.0.0 che lo gira a 3.2.0

A questo punto il dispositivo 3.2.0 elabora il comando alzando il livello all’uscita corrispondente.

 

Il progetto infine prevede la creazione di una GUI  che gestisce le tabelle nel RDBMS del microserver.

La GUI permette di descrivere l’intero impianto mediante griglie di correlazione.

Quindi il programma prevede l’opzione di creare al volo ed in modo completamente automatico il firmware per ogni Arduino ed aggiornarlo via USB.

Perciò ogni Arduino deve venire correttamente etichettato mediante le coordinate i.j.k e connesso mediante USB al computer con la GUI di gestione per il travaso del firmware. L’operazione precedente deve essere rifatta nel caso che cambino i figli.

 

Il progetto si conclude con la realizzazione di App per Ubuntu Phone e Tablet, Android e iPhone di gestione ordinaria. L’obiettivo più ambizioso vorrebbe creare piante dei sistemi SVG e sovrapporre dei widgets dinamici visuali che rendano visuale il comportamento del sistema.

L’applicazione più importante sarà il controllo del CED quindi di una stanza con molti server. L’obiettivo è di controllare la linea di rete, le temperature, i tasti di accensione, reset di ogni server strategico. Le App mostreranno visualmente lo stato di ogni server e permetteranno operazioni quali spegnimento ed accesione “fisica”. Verranno gestiti i tempi di sostegno degli UPS e lo stato dei gateway verso l’esterno.

Arduino, Automazione Industriale, Building Automation, Domotica, Elettronica, Hardware, Informatica

Arduino con Seeedstudio Grove

Stiamo valutando le possibili modalità di espansione della piattaforma Arduino.

In breve ci sono due versanti: a monte, ovvero un host di appoggio, ed a valle, ovvero sensori ed attuatori.

Il secondo aspetto, quello verso i sensori ed attuatori, porta alla grande questione di non poter sempre saldare ogni componente: serve uno shield che dia uno standard minimo verso l’elettronica finale.

Abbiamo deciso di valutare la proposta Grove della http://www.seeedstudio.com, dinamica azienda cinese, per integrarla nella progettualità futura. Forse la proposta più ampia.

I test sono orientati soprattutto alle esigenze di installatori ed integratori anche di piccole dimensioni. Imprese che non possono fare enormi investimenti in risorse economiche ed umane per attività di sviluppo su microcontroller ed altra elettronica, ma possono creare spazi virtuosi componendo tasselli di varie provenienze.