SCADA e HMI differenze?

[Walloelazri]

Che differenza c'è fra SCADA e HMI quando entrambi svolgono il lavoro di controllo di supervisione e acquisizione dati?

SCADA  è solo una tipologia di software o indica proprio l'intero sistema di controllo?

Con gli HMI ci sto iniziando a capire ma i sistemi SCADA non molto.

 

Grazie.

[Livio Orsini]

HMI ===> Human Machine Interface; è una semplice interfaccia uomo macchina tipo pannellini di controllo o, anche un semplice tastierino con visualizzatare.

 

SCADA ====> Supervisory Control And Data Acquisition; come dice il nome è una vera supervisione del sitema di controllo, completa di raccolta dati.

[Walloelazri]

Ma se entrambi leggono e controllano, la differenza sostanziale sta nella loro complessita? Cioè con un HMI posso comandare per esempio una determinata macchina mentre con un sistema SCADA un intero processo.

 

[Livio Orsini]

Semplificando i concetti è così.

 

[alefrasca]

Se non erro un hmi è comunque fisicamente collegata alla macchina mentre con lo scada nelle centrali fanno anche le app per iPad per la manutenzione da remoto per chi ha la reperibilità notturna. È giusto?

[Livio Orsini]

26 minuti fa, alefrasca scrisse:

È giusto?

 

Questa non è una proprietà intrinseca ad alcuni SCADA, ma dipende da come è stato fatto l'impianto/macchina.

[Lucky67]

5 ore fa, alefrasca scrisse:

Se non erro un hmi è comunque fisicamente collegata alla macchina mentre con lo scada nelle centrali fanno anche le app per iPad per la manutenzione da remoto per chi ha la reperibilità notturna. È giusto?

 

Quello puoi fare anche con un HMI e addirittura anche senza se vuoi...

[frussosw]

Direi che è una definizione che inizia ad essere obsoleta, oggi molti applicativi cosiddetti HMI sono dei veri e propri SCADA anhe perchè le moderne macchine sempre

più complesse hanno bisogno di una interfaccia UOMO-MACCHINA anch' essa sempre più complessa e quindi sempre più vicino alla complessità di uno SCADA...

 

non so se è chiaro..

 

 

[Livio Orsini]

Non c'è sovrapposizione, sono i dispositivi HMI che tendono ad occupare la fascia bassa degli SCADA, è la normale evoluzione tecnologica.

[ETR]

Tecnicamente ormai c'è pochissima diversità per il 70% dell'uso che ne fanno i più.

 

Questo perché alcuni anni fa, chi produceva SCADA ha cominciato ad allargare il proprio campo di lavoro anche sui PC Touch da panello con Windows CE (vd Progea). Ne qua ne è nata una sovrapposizione che vede ormai non solo il noto scada italiano ma anche molti altri brand. 

 

L'avvento di sistemi operativi meno "menosi" rispetto a CE, ha poi permesso maggiore espansione di queste soluzioni e ne puoi trovare quante ne vuoi.

 

Di contro, coloro che avevano HW con SW dedicato, vedendo la concorrenza che gli entrava nell'orticello, hanno provato a percorrere la strada inversa, con degli applicativi capaci di girare su PC come RUNTIME. 

 

Secondo me ovviamente ci sono pro e contro in tutto. Eseguire un downgrade prestazionale di un sistema che nasce per altro, non è stato per molto tempo facile ed infatti le prestazioni a volte erano un po' deludenti, rispetto a software creati per hardware dedicati ad un solo scopo. Però con il tempo, le cose in tutti i versi sono un po' migliorate (c'è da dire che sono sostanzialmente aumentate le risorse hardware) e quindi siamo arrivati ad una buona condizione di utilizzo.

 

Secondo me andremo sempre di più verso una "scalabilità" di alcuni prodotti software, svincolati dall'hardware, quindi andremo a perdere questa differenza netta tra HMI e SCADA. 

 

Certamente rimarranno, prodotti ENTRY LEVEL con software dedicato cosi come software "SCADA" che potranno solo girare su sistemi di alto livello.

 

Le cose si evolvono.

 

Buona giornata, Ennio

[Marco Mondin]

È un discorso piuttosto complesso. Un HMI può svolgere alcune funzioni di uno SCADA e viceversa.
HMI indica comunque la parte di iterazione umana, SCADA quella non supervisionata da umano.
Uno SCADA con supervisione umana è sia SCADA che HMI non uno o l'altro, chiamarlo solo SCADA è una abbreviazione commerciale.

Il discorso oggi si complica molto. Con l'ingresso dell'informatica vera e dura nell'automazione molti applicativi svolgono il compito di SCADA, HMI, calcolo, controllo diretto di processo in supporto ai PLC e runtime e fanno anche molte cose che nell'automazione non erano possibili. Tali applicativi sono dal punto di vista dell'automazione sia SCADA che HMI che parte di PLC quando non sono proprio anche il PLC. Dal punto di vista informatico i nomi cambiano, i concetti sono sovente raggruppati in insiemi come nell'automazione, ma i domini di questi insiemi non sono sovente perfettamente sovrapposti a quelli dell'automazione e sovente le intersezione di tali insiemi non sono ben definite come nell'automazione, ma molto più sfumate.

Fino a pochi anni fa gli "informatici puri" non affrontavano l'automazione in quanto non avevano la formazione adeguata elettromeccanica, oggi il discorso cambia e molti informatici sono preparati sulla meccanica di base e sull'elettrotecnica a sufficienza e sovente hanno ottime conoscenze di analisi matematica, geometria analitica ed algebra vettoriale. I produttori di PLC etc.. erano costretti a realizzare prodotti che ragionassero con una filosofia vicina ad un elettromeccanico che al contrario non aveva le competenze sull'informatica per sviluppare "vero software".
Un tempo appena le cose si complicavano i produttori bombardavano di FUB preconfezionati i loro ambienti, in quanto far capire concetti informatici duri, analisi matematica, geometria analitica ed algebra vettoriale ad un perito elettrotecnico poteva rivelarsi (fate salvo alcune eccezioni) una impresa titanica. Oggi non è più così e molti produttori iniziano a lasciare molta più strada libera a chi ha le dovute competenze, permettendo di infrangere tutta una serie di schemi e muri che si erano creati per semplificare la vita a chi le competenze non le aveva, ma che dal lato opposto ponevano non pochi limiti a chi invece le aveva. Le distinzioni rigide SCADA/HMI fanno parte dell'epoca "vecchia".

Piccolo inciso in modalità cattivella:
Oggi i produttori che cercano di restare ancorati alla vecchia filosofia sono quelli che hanno trovato la gallina dalle uova d'oro nell'ignoranza dello sviluppatore facendo pagare cifre stratosferiche cose che non avrebbe senso far pagare così care. Imponendo castrature qua e la per limitare intenzionalmente le apparecchiature e salassare chi vuole usare funzioni extra.

 

Altri produttori la fanno più furba! Hai necessità del PLCOpen per il motion in quanto non sei in grado di farti le cose da solo? Paga!!!
Non sai comunicare in WebSocket, REST, MQTT e non conosci i fondamenti di accesso e gestione dei database? Paga OPC/UA!!!

Sei in grado di gestirti il motion da solo con l'ambiente base? Allora perché dovresti comperare anche la licenza per il motion? Fattelo!
Sai interagire con i gestionali, MES, ERP parlando la loro lingua? OPC/UA non ti serve a nulla! Complichi solo la vita a chi lavora con gestionali, MES, ERP per """semplificare""" la tua.

Modificato: 17 febbraio 2020 da Marco Mondin

[batta]

57 minuti fa, Marco Mondin ha scritto:

Oggi i produttori che cercano di restare ancorati alla vecchia filosofia sono quelli che hanno trovato la gallina dalle uova d'oro nell'ignoranza dello sviluppatore

Marco, io sono convinto che tu sia un programmatore di alto livello, molto preparato.

Ma quanta presunzione, però!

Sembra che chiunque non affronti la programmazione "a modo tuo", sia una scamorza indegna di toccare una tastiera.
Per esperienza, ti posso dire che, molto spesso, i programmi PLC che presentano maggiori problemi sono proprio quelli sviluppati da informatici.

[Livio Orsini]

1 ora fa, Marco Mondin ha scritto:

Piccolo inciso in modalità cattivella:

 

 

Marco Mondin il tuo mi sembra un approccio molto manicheo; anche se sei un'informatico non puoi approcciare tutto e sempre in modalità booleana.

Nella realtà non esistono solo il bianco o il nero, anzi bianco e nero proprio non ci sono, ci sono solo differenti gradazioni di grigio.

[Marco Mondin]

1 ora fa, Livio Orsini ha scritto:

 

 

Marco Mondin il tuo mi sembra un approccio molto manicheo; anche se sei un'informatico non puoi approcciare tutto e sempre in modalità booleana.

Nella realtà non esistono solo il bianco o il nero, anzi bianco e nero proprio non ci sono, ci sono solo differenti gradazioni di grigio.

  Chiedo scusa... Effettivamente non ho un bel carattere... Comunque concordo che il mondo non sia tutto bianco o tutto nero. Anzi di frequente io ed il mio socio non seguiamo lavori dal principio alla fine, ma sviluppiamo sovente librerie, FUB, moduli etc per conto di altri sviluppatori permettendogli di prendere lavori che solitamente evitano.
Per esempio gli curiamo la parte di motion dando loro FUB molto più compatibili con lo sviluppo software in stile elettromeccanico, gli curiamo tutta la parte di tracciabiltà integrazione ai MES, gestione ricette, sviluppiamo librerie matematiche etc... Dipende un po' dai professionisti con cui ci troviamo a collaborare.
I discorsi di stile che sovente faccio li usiamo in modo un po' più purista solo nei grossi lavori che possiamo seguire a 360°, che tuttavia occupandoci per molte centinaia di ore cerchiamo di centellinare in favore di lavori più piccoli per non perdere contatto con il mercato isolandoci per troppo tempo su singoli progetti.

Dal mio modo di parlare, si evince che io probabilmente critichi lo stile elettromeccanico, in realtà, anche se non ci piace utilizzarlo per vari motivi, vedo molti lavori ben fatti anche in tale stile, come ahimé ne vedo anche molti fatti veramente male. Tuttavia la stessa cosa vale per i paradigmi puramente informatici.

Porgo comunque le mie più sentite scuse per il mio modo di atteggiarmi. Non è mia intenzione offendere nessuno. Anzi...

[lelos]

Il 8/9/2019 alle 09:20 , alefrasca ha scritto:

Se non erro un hmi è comunque fisicamente collegata alla macchina mentre con lo scada nelle centrali fanno anche le app per iPad per la manutenzione da remoto per chi ha la reperibilità notturna. È giusto?

le app ci sono anche per gli HMI

[leleviola]

28 minuti fa, lelos ha scritto:

le app ci sono anche per gli HMI

vedi Weintek esempio che ha App Client per gestire pannelli ciechi HMI su dispositivi Android PC e iPhone

[lelos]

1 ora fa, leleviola ha scritto:

vedi Weintek esempio che ha App Client per gestire pannelli ciechi HMI su dispositivi Android PC e iPhone

non volevo nomine Weintek  perché ho rilevato un po di ostilità tra molti programmatori ad usarlo.

Poiché non si chiama Siemens , Omrom , Proface o una qualsiasi altra marca conosciuta viene disprezzato senza neanche conoscerne le potenzialità che, a volte, per un certo utilizzo ,potrebbe  sostituire uno scada con un costo 10 volte inferiore.

[batta]

5 ore fa, Marco Mondin ha scritto:

Hai necessità del PLCOpen per il motion in quanto non sei in grado di farti le cose da solo? Paga!!!

 

2 ore fa, Marco Mondin ha scritto:

sviluppiamo sovente librerie, FUB, moduli etc per conto di altri sviluppatori permettendogli di prendere lavori che solitamente evitano.

In sostanza, pagano te piuttosto che il costruttore del plc.

 

Poi è anche una questione di scelte. Faccio solo un esempio: con una cpu "T" di Siemens (ma immagino sia più o meno così anche per altri marchi), usando poche istruzioni PLCOpen, è possibile gestire funzioni anche piuttosto complesse, tipo sincronizzazione di assi in vari modi, camme, portali 2D/3D, delta 2D/3D, e molto altro. Una CPU che mi permetta di gestire in modo facile e collaudato, per esempio, un Delta 3D + rotazione, mi costa 500 euro (o forse anche meno) più dell'equivalente senza funzioni tecnologiche. Chiedo: chi me lo dovrebbe far fare di perdere centinaia di ore per sviluppare tutto da zero? Certo, poi il lavoro lo recupero nei progetti successivi, ma quanto mi ci vuole?
Il mio lavoro, alla fine, consiste nel far funzionare la macchina. Per farla funzionare devo anche scrivere del codice (ed è una delle parti che più mi appassionano), ma se posso mettere in piedi un delta con poche ore di lavoro, ben venga. Da non trascurare poi il vantaggio di utilizzare funzioni ampiamente testate, che, si presume, dovrebbero essere esenti da bachi.

[leleviola]

19 minuti fa, batta ha scritto:

Poi è anche una questione di scelte. Faccio solo un esempio: con una cpu "T" di Siemens (ma immagino sia più o meno così anche per altri marchi), usando poche istruzioni PLCOpen, è possibile gestire funzioni anche piuttosto complesse, tipo sincronizzazione di assi in vari modi, camme, portali 2D/3D, delta 2D/3D, e molto altro.

e visto che usi istruzioni PLC Open dovrebbe essere abbastanza semplice passare da un marchio a un altro se hai necessità in un secondo momento

 

1 ora fa, lelos ha scritto:

non volevo nomine Weintek  perché ho rilevato un po di ostilità tra molti programmatori ad usarlo.

l'ostilità l'ho trovata anch'io da alcuni programmatori ma il fatto è che sono sul mercato da 25 anni e ormai mi sa che sanno il fatto loro e spesso hanno funzionalità che altri non hanno,

daltronde è su questo che si battono,

ultimamente è capiatato di usarli al posto di Siemens e il cliente è rimasto comunque meravigliato, si sa il nome si paga

[Livio Orsini]

4 ore fa, Marco Mondin ha scritto:

Porgo comunque le mie più sentite scuse per il mio modo di atteggiarmi. Non è mia intenzione offendere nessuno. Anzi...

 

Credo che le scuse non siano dovute e nemmeno necessarie.

La tua è solo una filosofia di concepire il lavoro di programmazione. Si può non essere d'accordo, ma tu hai il sacrosanto diritto di esprimere le tue idee, visto che lo fai in modo civile ed educato.

 

4 ore fa, Marco Mondin ha scritto:

in realtà, anche se non ci piace utilizzarlo per vari motivi, vedo molti lavori ben fatti anche in tale stile, come ahimé ne vedo anche molti fatti veramente male.

 

Come tu hai evidenziato il lavoro può essere ben fatto o mal fatto, indipendentemente dal linguaggio e dallo stile. Ci sono linguaggi come il "ladder diagram" o i vecchi "spaghetti like programming" (Fortran, basic, etc.) che consentono moltissime porcate, altri come PL1,PLM, Pascal, etc.che invece obbligano maggiormente ad una programmazione ben fatta.

Alla base di tutto, comunque, c'è l'educazione informatica, ma anche quella linguistica, per realizzare programmi in modo logico. Io, ad esempio, ho capito l'utilità dello studio obbligatorio del latino quando ho iniziato a studiare informatica. Anche se al tempo della sua riforma scolastica, il filosofo Gentile non poteva nemmeno immaginare che di li a meno di mezzo secolo sarebbe nata un branca della scienza denominata informatica.

 

Purtroppo il linguaggio "a contatti" ha permesso di programmare a persone senza nessuna cultura informatica. Sino a quando i PLC potevano solo emulare sequenze di relè le cose funzionavano; poi con l'evolversi della tecnologia i PLC son diventati sempre più simili ad elaboratori numerici e son cominciati i guai.

 

E sempre utile confrontare le proprie idee con quelle degli altri, anche se sono diametralmente opposte; basta che il confronto avvenga in modo pacato e civile.

Modificato: 17 febbraio 2020 da Livio Orsini

[leleviola]

5 ore fa, Marco Mondin ha scritto:

  Chiedo scusa... Effettivamente non ho un bel carattere... Comunque concordo che il mondo non sia tutto bianco o tutto nero. Anzi di frequente io ed il mio socio non seguiamo lavori dal principio alla fine, ma sviluppiamo sovente librerie, FUB, moduli etc per conto di altri sviluppatori permettendogli di prendere lavori che solitamente evitano.
 

Scusami @Marco Mondin perchè devi scusarti?

è sempre un gran piacere ascoltare le tue opinioni, sono sempre molto interessanti credimi e invidio tanto le tue capacità informatiche

[ETR]

Il concetto di Yiogo è chiaro e concordo nel suo principio ma lo libererei dai termini HMI e SCADA, perché il discorso allora andrebbe a lambire per sua natura anche il DCS (che per sintetizzare, ha parte grafica, ha parte logica, ha parte di storicizzazione dbase ecc... e funziona anche senza operatore) ed entreremmo nel discutere se non chiamare un Yokogawa Centrum ... SCADA o DCS, per via dell'hardware o per il software. Ma allora per esempio B&R, ha Aprol, che è un DCS non basato su HW specifico e quindi cosa è ? Uno scada ? Un mini DCS ? Ultimamente ho visto che Siemens sta "snellendo PCS7" chiamandolo NEO e cosa è allora ?

 

Per riassumere, si vuole e parer mio racchiudere in diciture costringenti, qualcosa che sta cambiando molto velocemente. Ci saranno (o ci sono già in alcuni casi) prodotti che tenderanno sempre più a sovrapporsi senza avere una netta demarcazione, ma avranno moduli e costi gestibili a seconda dell'esigenza. 

 

Li potremo chiamare HMI ? SCADA ? DCS ? Certamente non ci sarà l'oggetto che potrà coprire tutto (economicamente e tecnicamente è improponibile), anche se qualche commerciale ci proverà a vendervelo ! 

 

Rimarranno i capisaldi che conosciamo (ABB, Yokogawa ecc...), ma ne nasceranno di nuovi che avranno funzioni anche legate all'aumento delle prestazioni hw e alla delocalizzazione computazionale. 

 

Buona giornata, Ennio 

[ETR]

Mi scuso con tutti, se rischio di andare fuori OT, ma colgo l'occasione  :

Quote

la differenza è che nel caso specifico lo decidi tu, in genere ciò che nasce plc sarà comunque plc e uguale per i dcs

 

Per il pacchetto B&R, Aprol, il discorso software non si esime dalla tua considerazione. Per l'hardware invece è cosa completamente diversa in quanto lavora su un minimo hardware necessario (il PC per la parte historian e tutto il non real time), ma poi si basa su hardware comunissimo PLC , che può essere usato per CNC, robotica o processo. 

 

Il discorso è stato apprezzato al corso che ho seguito l'anno scorso con persone molto più autorevoli di me (tutti di ABB, con esperienza sui DCS di lunga data), in cui questa flessibilità tecnica non ti cotringeva in hardware speciali e dedicati e garantiva dei costi nettamente inferiori.

 

Detto ciò, va valutato poi prestazionalmente cosa viene richiesto dal processo, ma comunque le prestazioni non sono scarse e limitate ad un prodotto di basa fascia. E' il concetto che cambia in un ambiente che essendo MOLTO chiuso, ha delle dinamiche diverse rispetto all'automazione più comune.

 

Non so se altri (come dicevo ho intravisto Siemens) stiano pensado ad intraprendere una filosofia di questo tipo. ABB, sta cercando di integrare, ma ovviamente senza snaturare il suo DCS, visti gli ovvi vantaggi economici, ma come detto, le dinamiche sono diverse cosi come sono anche le aree di "prevalicazione" di un marchio rispetto al altri.

 

Buona giornata, Ennio

[Marco Mondin]

3 ore fa, ETR ha scritto:

Il discorso è stato apprezzato al corso che ho seguito l'anno scorso con persone molto più autorevoli di me (tutti di ABB, con esperienza sui DCS di lunga data), in cui questa flessibilità tecnica non ti cotringeva in hardware speciali e dedicati e garantiva dei costi nettamente inferiori.

Infatti anche secondo me questa sovrapposizione hardware porta ad un enorme vantaggio per noi sviluppatori, il crollo dei prezzi e di conseguenza l'aumento della marginalità.
Alla fine sviluppandoci le cose da soli e svincolandoci dai concetti di alcuni big dell'automazione il vantaggio (Quando il cliente lo accetta) di solito è tutto nostro.
 

Quote

Detto ciò, va valutato poi prestazionalmente cosa viene richiesto dal processo, ma comunque le prestazioni non sono scarse e limitate ad un prodotto di basa fascia. E' il concetto che cambia in un ambiente che essendo MOLTO chiuso, ha delle dinamiche diverse rispetto all'automazione più comune.

Prestazionalmente oggi con un i5 mediocre (di costruzione per uso industriale) dal costo inferiore ad un PLC di fascia alta, il CPU pinning, la gestione dei runtime in realtime si superano le prestazioni di quasi tutti i PLC in commercio e ci si fa anche tutta una serie di cose per cui, con i PLC, sarebbe necessario acquistare un sacco di hardware e licenze.

 

Quote

Non so se altri (come dicevo ho intravisto Siemens) stiano pensado ad intraprendere una filosofia di questo tipo.

La stanno seguendo credo tutti i CODESYS derivati che sono la maggior parte dei produttori di PLC non Omron, Siemens, Rockwell o B&R(Tuttavia quest'ultimo segue abbastanza la filosofia restando però un pelo più chiuso).

[Marco Mondin]

 

9 ore fa, Yiogo ha scritto:

sono scelte già a suo tempo perseguite ma allo stato attuale in abbandono, anzi sta venendo sempre più fuori il concetto di Edge

 Come soluzione edge ho trovato banale l'utilizzo degli edge gateway con Node-RED a bordo, tuttavia dopo il primo utilizzo ho scoperto che Node-RED può essere installato su qualunque PC ed esteso con moduli software in nodejs scritti in JavaScript.
Ora la soluzione che prediligo è un PC industriale debian, runtime CODESYS (per il momento SL anche se stiamo valutando seriamente l'acquisto dell'SDK), docker con Node-RED, openVPN, firewall gestito con il netfilter del kernel linux ed il nostro framework.

In alcuni casi ci nascondiamo una virtual machine KVM con windows 7 PRO ed i vari software per le configurazioni delle apparecchiature di campo. Può essere avvivara da VPN e gestita in remote desktop non facendo vedere nulla all'operatore.
Con una singola apparecchiatura abbiamo PLC realtime con ciclica veloce fino a 250us (anche se sotto 1ms non scendiamo "quasi" mai), jitter minore di 65us (Si potrebbe anche scendere un po' a patto di scegliere bene CPU e compilare a mano il kernel, ma è una noia paurosa e serve a poco anche se a tempo perso ogni tanto qualche test lo faccio), scambio dati tra framework e PLC tramite Shared Memory, HMI sviluppato con il nostro framework derivato da Qt in C++\QML, telegestione tramite VPN, sistema di interfacciamento con il mondo esterno tramite Node-RED ed il nostro framework. 

Modificato: 20 febbraio 2020 da Marco Mondin