Plc : Dispositivo Real Time? - Che significa

[rob10kg]

Perchè un PLC è definito un dispositivo real time?

Perchè non soffre di blocchi nell'esecuzione del programma?

Grazie e ciao.

[walterword]

essere real time vuol dire rientrare in certi parametri posti come target

Cio' non vuol dire far girare il programma in 10 uS , anche perche il tempo di scansione dipende

dalla quantita di istruzioni da eseguire

Molti plc e cnc hanno un sistema operativo che esegue diversi tasks , con diversi tempi , in foreground ed in background .Alla fine leggi sempre lo stesso tempo di scansione anche se aumenti il programma .

Essere real time per un plc vuol dire girare entro alcuni millisecondi .

I task sono eseguiti senza interruzioni , senon programmate (interrupt) .

La comunicazione viene svolta da un processore parallelo che condivide la memoria ram con la cpu del plc ,

tipo dual port .

In alcuni nuovi plc , per esempio A&B o texas instr. , vengono usati degli fpga con sintetizzati all'interno

la cpu per eseguire il programma utente ed un'altra cpu o piu di una o anche un controller ethernet per controllare la comunicazione .

Questo sitema chiamato multiprocessor crea un arbitrio tra le diverse cpu che comunicano tra di loro

attraverso un bus interno al fpga .

Cosi quando una cpu ha caricato le variabili e le passa alla sua alu , essendo libera , lascia alla cpu della comunicazione il tempo per poter rinfrescare i dati ricevuti nel buffer o preparare un buffer da spedire .

In molti plc , l'architettura utilizza anche dei controller DMA (direct memory access ) che lavorano in parallelo alle cpu menzionate prima .

Come ben saprai di solito la comunicazione si basa sulla spedizione e ricezione di un byte per volta .

Come accade nei micro , si scatenano degli interrupt quando il buffer e' pieno oppure pronto a trasmettere.

La cpu , in un sistema monoprocessore , si deve far carico di gestire il tutto , penalizzando i tempi di esecuzione del programma utente .

Qua invece con DMA oppure con multiprocessore le cose capirai che sono molto piu performanti , avendo

piu velocita' di scansione ed esecuzione del programma a parita di clock , ed una comunicazione piu efficente .

ciao

walter

[AndreaC]

Perchè un PLC è definito un dispositivo real time?

Non mi risulta.

Perchè non soffre di blocchi nell'esecuzione del programma?

I blocchi di esecuzione dipendono, a meno di guasti dell'HW, da cattiva programmazione.

Essere real time per un plc vuol dire girare entro alcuni millisecondi .

Non sono d'accordo.

Un controllo real time è tale quando i tempi di esecuzione del controllo sono <= ai tempi di variazione delle grandezze controllate, cioé non ci sono "ritardi" tra evento e correzione.

Quindi 10 ms possono essere tanti o pochi, dipende dal sistema sul quale il controllo interagisce.

Il PLC ti può consentire una attività a tempo determinato, cosa non trascurabile, o garantirti un tempo di scansione mediamente basso anche se a tempo indeterminato (o meglio, determinato dalla particolare sequenza di istruzioni eseguita in un ciclo in funzione dei vari ingressi), ma non per questo è real time.

L'accezione real time deve essere valutata per l'insieme del sistema di controllo (dai sensori agli attuatori), non solo per l'unità intelligente.

[Livio Orsini]

Perchè un PLC è definito un dispositivo real time?

Qualsiasi sistema di controllo può essere definito "in tempo reale (real time)" a condizione che il suo tempo di risposta massimo, ad un evento esterno, sia trascurabile rispetto al tempo in cui evolve la variabile da controllora.

Chiarisco con esempi. Controllo della temperatura di un salone. Per ottenere un incremento di 0.1C sono necesari, p.e., 180". Se il regolatore controlla ogni 0.1" è ampiamente un controllo in tempo reale.

Controllo di posizione di un asse. Precisione richiesta 1um, velocità 5um/msec. Se il regolatore controlla con tempo di campionamento pari a 1msec non controlla in tempo reale. Perchè possa essere considerato controllo in tempo reale deve eseguire un ciclo con un tempo <=0.05msec

[AndreaC]

Grazie Livio per l'esempio, prima non ho avuto modo di completare il post.

[rob10kg]

Livio rispiegami per cortesia l'esempio del controllo dell'asse.

[Livio Orsini]

C'è poco da spiegare! Se vuoi un aprecisione 1um devi poter discriminare almeno 0.5 um. Con velocità di 5um/msec hai 1 impulso ogni 0.1 msec. Per leggerlo con sicurezza devi campionare con tempo <= alla metà, da cui 0.05msec. Ma è proprio il limite, meglio sarebbe usare un tempo 10usec

[walterword]

bravo livio mi hai tolto le parole dalla bocca

E' proprio quello che volevo dire io e che ho spiegato in parte .

Se devo regolare un processo la cui variabile cambia di stato ogni ora (per assurdo )

ed ho un controller che esegue los can ogni 10 minuti , questo e' real time .

bravo livio !!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Savino]

Perchè non soffre di blocchi nell'esecuzione del programma?

Perche i blocchi programma girano asincronicamente con respetto alla unita' di governo.

Per esempio l'orologgio del sistema PLC si aggiorna in real time (beh...quasi.....aggiornarebbe forse ..)... in cambio un orologgio "programmato" soffrerebbe di tutta l'astrazione del codice di libreria e quindi si aggiornarebbe in RUN TIME ( Real time + errore ). Dopo 24 ore trascorse l'orologgio programmato avra' un tempo di valore piu' alto ( errore ).Tuttavia, valendosi dei blocchi speciali tipo interrupt si riuscirebbe ad avere aggiornamenti con valori di errore bassissimi.

Modificato: 9 settembre 2006 da Savino

[IMM-Domenico]

Un aspetto molto importante dei PLC è il così detto determinismo.

In questo ambito il determinismo è rivolto ai tempi di esecuzione del software. In base al programma che intendiamo eseguire, possiamo calcolare il tempo massimo di ciclo, ed essere sicuri che il PLC farà sempre in tempo ad intervenire entro tale tempo. Questa caratteristica è molto importante nella maggior parte delle applicazioni dei PLC, e non è indispensabile in alcuni sistemi real-time.

Un distributore automatico di lattine, tanto per fare un esempio, può essere considerato real-time (soft real-time), nel senso che risponde con una tempistica sufficiente rispetto ai tempi richiesti da chi ha acquistato la lattina (purchè sia dotato di un minimo pazienza).

In questo caso il determinismo è meno importante che nel caso di controllo assi citato da Livio, ma non perchè le tempistiche del controllo assi sono meno rapide, ma semplicemente perchè un ritardo potrebbe provocare dei danni, a differenza del distributore che creerebbe semplicemente un attesa superiore per la lattina.

Modificato: 11 settembre 2006 da IMM-Domenico

[Luca Bab]

Argomento molto interessante

ma quand'e' che un SO viene riconosciuto come real time ???

Perche' in automazione W2000 non e' riconosciuto come real time ???

Non e' che per ritenere un sistema real time viene riconoscito il tempo massimo di ciclo ( noto ) come accettabile per il lavoro da svolgere ??? e che in nessun caso ci sia un'allungamento del ciclo ?

Saluti

Luca

[Livio Orsini]

Un aspetto molto importante dei PLC è il così detto determinismo.

Forse quanto ho scritto nel #41 non è stato sufficientemente chiaro per tutti.

Se il tempo di esecuzione del controllo è ininfluente o trascurabile per il processo da controllare il controllo si può definire "in tempo reale" o "real time".

Diversa è la tolleranza sui tempi di esecuzione. Un processo può essere attivato con variazioni di tempistica anche pari al 100% ma, se il tempo massimo di esecuzione è inifluente sul processo da controllare è sempre un controllo in tempo reale. Al contrario un processo di controllo può ripetersi con una precisione temporale avente uno scostamento <0.00000001% ma non può essere classificato "in tempo reale" perchè l'intervallo di tempo non è trascurabile per il processo controllato.

La precisione dell'intervallo di tempo invece è molto influente nei processi di regolazione, perchè un a variazione del periodo di campionamento o di aggiornamento della variabile di controllo causa rumore di regolazione, ne più ne meno di una instabilità. Per chi volesse approfondire questo argomento consiglio la lettura di manuali come "Digital Controls usin microprocessor" del Katz un po' datato ma validissimo, o il smepre valido "digital Controls" del Quo.

Perche' in automazione W2000 non e' riconosciuto come real time ???

Perchè no? Dipende dal processo da controllare.

Modificato: 11 settembre 2006 da Livio Orsini

[IMM-Domenico]

Forse quanto ho scritto nel #4 non è stato sufficientemente chiaro per tutti.

Come sempre, livio, sei stato chiarissimo. Io comunque non stavo parlando più del concetto di real-time, ma di un altro aspetto, il determinismo.

Sistemi come Windows 2000, per esempio, sono NON deterministici, ma possono essere real-time a seconda dell'ambito, come hai già sottolineato.

I sistemi che nel linguaggio comune, al di là delle definizioni accademiche, vengono definiti real-time (RTOS, real-time operating systems) sono sistemi con un alto grado di stabilità e tipicamente deterministici soprattutto per quanto riguarda la schedulazione dei processi in esecuzione. Lo schedulatore di sistemi come Windows non è deterministico, nel senso che non si riesce a stabilire con certezza matematica un istante entro il quale un certo processo verrà eseguito.

[Livio Orsini]

Lo schedulatore di sistemi come Windows non è deterministico, nel senso che non si riesce a stabilire con certezza matematica un istante entro il quale un certo processo verrà eseguito.

No, non è del tutto vero. Se i tempi sono dell'ordine dei 100ms è possibile anche con WINxx determinare l'istante esatto di avvio di un processo con (quasi) assoluta ripetibilità.

Per i tipici RTOS come RTOSS (Siemens) RMX8x (Intel), QNX, Paradox e altri la granularità entro cui si può schedulare un processo è dell'ordine della decina di microsecondi, mentre la latenza alla rispsota degli interrupts e dell'ordine dei 100ns (cito molto a memoria e quindi non garantisco la precisione dei dati).

Quindi la differenza sostanziale tra i due tipo di SO, a mio parere, sta nella granularità o quantizzazione dei tempi di schedulazione.

D'altro canto si può osservare qualche cosa di simile nei PLC. Per esempio si può schedulare un processo, legandolo ad un interrupt su timer di sistema, con quantizzazione minima di 10ms per una CPU della serie 200, mentre per la serie 300 si può scendere alla metà (riferimento S7 Siemens). Qui le differenze sono legate alla potenza del sistema HW, mentre per SO citati in precedenza le differenze sono dovute alla diversa organizzazione del SW.

Modificato: 12 settembre 2006 da Livio Orsini

[IMM-Domenico]

Quindi la differenza sostanziale tra i due tipo di SO, a mio parere, sta nella granularità o quantizzazione dei tempi di schedulazione.

Che io sappia, correggetemi se sbaglio, la differenza consiste negli algoritmi, oltre che ovviamente alla granularità dei tempi. Gli algoritmi di schedulazione deterministici danno più garanzie rispetto agli altri. La "(quasi) assoluta ripetibilità" in certi casi non è sufficiente.

Nei sistemi operativi real-time, inoltre, si limita il ricorso ad alcune soluzioni tecniche, come ad esempio i meccanismi di cache, memoria virtuale, ecc, che possono migliorare "mediamente" le prestazioni percepite da un utente umano, ma aggiungono componenti di aleatorietà indesiderate nei RTOS.

Modificato: 13 settembre 2006 da IMM-Domenico

[Livio Orsini]

La "(quasi) assoluta ripetibilità"...

Questa allocuzione sta proprio ad indicare che l'assoluto non esiste, neanche negli RTOS tradizionali, neanche se te fai uno ad hoc (ed io ne ho fatti almeno un paio di kernel di RTOS embedd).

Nei sistemi operativi real-time, inoltre, si limita il ricorso ad alcune soluzioni tecniche, come ad esempio i meccanismi di cache, memoria virtuale, ecc, ....

La differenza principale tra un multitask tipo WinXX ed un multitask RTOS classico sta nella protezione della memoria. In un vero multitask RTOS si proteggono, da corruzzioni casuali, sia l'area codice che quella dati, purtroppo non è così nei sistemi Win. Basta osservare idati di debug dopo un blocco: si nota la stack andato a...ranocchie E' questione di filosofia progettuale, non di algoritmi. Tra l'altro non ci sono algoritmi, nel senso classico del termine, in un sistema operativo.

Piccolo inciso.

Algoritmo è la corruzzione dell'allocuzione araba che significa "colui che proviene da Bassora". In uno scritto di un filosfo-matematico del medioevo si citava, appunto, una metodologia per svolgere i calcoli descritta da un matematico di Bassora, l'estensore confuse l'allocuzione con il nome proprio del matematico e riportò il nome come "Algoritm". Da allora Algoritm, poi latinizzato in algoritmo, divenne sinonimo di calcolo.

Ecco perchè, in luogo del politicamente scorretto: "I conti della serva", si usa "L'algoritmo della collaboratrice domestica"

Modificato: 13 settembre 2006 da Livio Orsini

[IMM-Domenico]

E' questione di filosofia progettuale, non di algoritmi. Tra l'altro non ci sono algoritmi, nel senso classico del termine, in un sistema operativo.

A volte ho l'impressione che ti diverti a provocare ...e io non resisto, devo rispondere.

Penso che la filosofia progettuale, alla fine di tutto il processo di sviluppo del software, si esprima in codice eseguibile. Da che mondo e mondo, un codice eseguibile di una certa complessità nasce sempre da un algoritmo. Ora possiamo stare a filosofeggiare mesi interi sull'origine delle parole, di indubbio interesse da un punto di vista culturale, ma in un forum non strettamente informatico preferisco usarne il significato più popolare che nel caso di algoritmo, senza dare una definizione troppo pignola, è una sequenza di istruzioni (che tipicamente viene espressa graficamente con un flow-chart) e che può essere poi trasformata in codice sorgente in un determinato linguaggio di programmazione. Sinceramente non riesco ad immaginare uno schedulatore senza relativo algoritmo... forse quello del dos e di tutti gli altri sistemi monotask.

...va be', filosofia informatica

Penso che stiamo annoiando chi legge, ho notato che non sta intervenendo più nessuno, e sono anche uscito fuori tema... scusate! Mi fermo qui.

Ciao. Domenico

[Luca Bab]

Non state per niente annoiando

continuate pure...............

A volte serve anche la teoria

ciao

Luca

[Livio Orsini]

Questa parte della discussione è forse marginale ma non completamente OT, si tratta in fatti di dispositivi real time e della loro definizione.

..preferisco usarne il significato più popolare che nel caso di algoritmo, senza dare una definizione troppo pignola, è una sequenza di istruzioni (che tipicamente viene espressa graficamente con un flow-chart) e che può essere poi trasformata in codice sorgente in un determinato linguaggio di programmazione.

Puoi preferire un termine qualsiasi ma, nella semantica corrente, algoritmo indica una serie di calcoli. Riporto da un dizionario enciclopedico:

"algoritmo s.m. - (da Muhammad ibn Musa al-Karazmi matematico arabo, inizio IX secolo) Insieme di simboli e procedimenti del calcolo matematico".

Non solo ma, sotto l'influsso prepotente dell'informatica, il termine algoritmo ha assunto il significato di procedura avente carattere generale in grado di risolvere ogni problema di una certa classe. Questo dal punto di vista matematico. Dal punto di vista filosofico, invece, con la notazione di algoritmo si indicano le componenti di automatismo e di meccanicità presenti in ambito matematico.

Ora un sistema operativo, mono o multi task che sia, è essenzialmente un insieme di processi logico - decisionali del tipo: posso o meno accedere ad una determinata risorsa? Devo rilasciare la risorsa? e via elencando.

Considerare algoritmi questo tipo di processi mi sembra un po' troppo estensivo.

Tanto per fare un esempio un classico algoritmo del mondo informatico è l'algoritmo di sort (ordinamento). Era il primo problema di programmazione che veniva ssegnato agli allievi (ricordo di molti decenni addietro, corso di "macchine calcolatrici" 1.o anno del corso di laurea in fisica ad indirizzo informatico: ordinare un vettore di 100 elementi in ordine crescente e decrescente).

Testi (quasi)sacri come il Buvet (Sistemi operativi) non usano definire algoritmi questi processi logici. Mentre un altro mostro sacro dell'informatica Niklaus Wirth (l'inventore del Pascal) titola un testo bello, seppur noiosetto, "Algorithms + Data Sequences = Propgrams", in cui non si fa cenno a sistemi operativi.

Ovviamente sono solo due piccoli esempi.

Poi ognuto è libero di attribuire al termine algoritmo l'accezzione che preferisce, nella sua personale semantica però. Potrei definire algoritmo di marcia arresto anche la semplice sequnza di marcia e arresto di un motore (2 pulsanti e un contatto NC del relè di marcia). "Algoritmo di marcia e arresto per motore asincrono": detto così suona molto più ...paludato .

Anche affermare che :"..sequenza di istruzioni (che tipicamente viene espressa graficamente con un flow-chart).." mi sembra esageratamente assolutistica.

Anzi da decenni i puri dell'informatica (come Wirth) tendono a non usare diagrammi di flusso ma descrizioni dettagliate o addirittura linguaggi strutturati dedicati alla descrizione. E' curioso che linguaggi come l'Algol (Algo[rithmic] L[anguage]) siano stati più usati per l'analisi e la documentazione che per la programmazione propriamente detta.

PS Ovviamente ho dovuto semplificare e riassumere in pochi concetti argomenti a cui si dedicano usualmente almeno interi capitoli. Tutto questo nulla ha a che vedere con il fatto che un sistema operativo sia o meno "real time".

Modificato: 14 settembre 2006 da Livio Orsini

[IMM-Domenico]

Come sempre molto esaustivo.

Forse dò un'accezione sbagliata al significato di algoritmo, forse la mia definizione è esageratamente grossolana, ma nulla mi toglie dalla testa che uno schedulatore, per decidere quale sarà il prossimo processo ad essere eseguito tra quelli in memoria, esegue delle operazioni del tutto paragonabili a quelle eseguite in un algoritmo di ordinamento o di ricerca. Non vedo perchè non si può usare la parola algoritmo in questo contesto. Dove sbaglio?

Sono d'accordo sul fatto che ormai i flow chart si usano soltanto a scuola, e forse neanche lì. Li ho citati semplicemente per rendere l'idea del concetto che volevo esprimere nella mia definizione grossolana.

Una mia idea, del tutto personale, è che le lingue si evolvono in continuazione, soprattutto per quanto riguarda materie così giovani come l'informatica. Termini generici, come algoritmo, vengono spesso utilizzati (mi riferisco alla gente comune) senza andare prima a consultare i testi che hai diligentemente citato. Nascono in questo modo diverse sfumature del significato della parola, e alcune di queste potrebbero anche affermarsi col tempo, così com'è successo in passato per altri termini.

La cosa più importante, però, è che queste parole svolgano il loro compito, cioè quello di permetterci di comunicare, e mi auguro che le differenze che abbiamo illutrato tra i sistemi real-time e quelli false-time siano state esposte con chiarezza a chi era interessato. Ovviamente l'espressione false-time non esiste, l'ho inventata io ora per scherzarci su, e anche per provare a trasmettere un concetto usando parole che addirittura non esistono.

[Livio Orsini]

Una mia idea, del tutto personale, è che le lingue si evolvono in continuazione,...

E' un'idea che condivido ed è condivisa da molti. Appunto per questo il termine algoritmo, in campo matematico, ha assunto il significato che ho riportato.

....uno schedulatore, per decidere quale sarà il prossimo processo ad essere eseguito tra quelli in memoria, esegue delle operazioni del tutto paragonabili a quelle eseguite in un algoritmo di ordinamento o di ricerca. Non vedo perchè non si può usare la parola algoritmo in questo contesto. Dove sbaglio?

Non per amore di pura polemica ma perchè ritengo che sia basilare per la comprensione di come lavora un SO devo dirti non posso condividere la tua definizione.

Un algoritmo di ricerca o di ordinamento non lavora come lo schedulatore di SO. Questi effettua in continuo verifiche logiche sulle condizioni; se lecondizioni sono vere il task viene attivato, se false viene disattivato. Ovviamente il concetto è semplificato e banalizzato perchè non si può condensare in poche righe un intero libro.

Comunque, divergenze semantiche a parte, credo sia stato un bello scambio di opinioni che fortifica lo spirito del forum. Forum che non è e non deve essere un surrogato di un "call center" aziendale, bensì un luogo di incontro e di confronto, mai di scontro, di idee. Se questo avviene tutti i partecipanti si arricchiscono.

Modificato: 14 settembre 2006 da Livio Orsini

[weather]

...... vado un po' OT , conoscete qualche libro che spiega piu' nel dettaglio come è fatto e come lavora un Sistema Operativo ??

[IMM-Domenico]

conoscete qualche libro che spiega piu' nel dettaglio come è fatto e come lavora un Sistema Operativo ??

Ce ne sono tonnellate. I migliori, e più completi, sono solitamente di autori stranieri. La mia memoria non è un gran chè, però come dimenticare il mitico "Modern Operating Systems" di Tanenbaum? Per me è stato un punto di riferimento. Altri titoli sinceramente, su due piedi, non ne ricordo... Livio saprà sicuramente consigliartene di più.

Comunque, divergenze semantiche a parte, credo sia stato un bello scambio di opinioni che fortifica lo spirito del forum. Forum che non è e non deve essere un surrogato di un "call center" aziendale, bensì un luogo di incontro e di confronto, mai di scontro, di idee. Se questo avviene tutti i partecipanti si arricchiscono.

D'accordo al 1000 per 1000.

[Livio Orsini]

...conoscete qualche libro che spiega piu' nel dettaglio come è fatto e come lavora un Sistema Operativo ??

Come propedeutico generale puoi pensare a Buvet "Sistemi operativi". Non ce l'ho a portata di mano quindi non posso darti informazioni aggiuntive.

Dopo aver acquisito una cultura generale sui sistemi operativi, potresti rivolgerti a testi specializzati sui singoli sistemi operativi. Per questo dipende dalle tue esigenze e preferenze. Su WinXX ne trovi parecchi, io consiglio quelli della Mondadori che sono emanazione diretta MS. Per gli altri....bisogna far ricorso ai manuali del produttore che non sono sempre facili da reperire

Modificato: 15 settembre 2006 da Livio Orsini