Newsgroup: it.lavoro.informatica
Titolo: Monitor per impianto risalita

a leggere il 3d vengono i brividi.
 
UN impianto di risalita cosa fa risalire ? persone?
2 volte i brividi.
 
-- 
Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.
(Victor Hugo)

 
 
Guarda che tu dovevi andartene. Parole tue, non mie.

 Guarda che tu dovevi andartene. Parole tue, non mie.
 
Ma delta11 è un mito e come tale immortale.


Un altro morph?
Noto che metterci la faccia devi trovarla una cosa vergognosa.
E non so darti torto.
Spero che non mi scoppi il killfile.
PLONK

>>
 
Sorridi dai, Doctor Ugo, ho l'impressione tu sia un tipo in gamba
ma sicuramente creatività ZERO.
 
No problem, tranqui, fai il tuo compitino e porta a casa la pagnotta.
 
--
Colui che è maestro nell'arte della vita, non distingue tra il
suo lavoro ed il suo tempo libero,
ma semplicemente persegue la sua visione d'eccellenza, qualsiasi
cosa stia facendo. Lasciando agli altri decidere,
se sta lavorando, o semplicemente giocando. [Massima Zen]
 
 


un applicativo del genere si fa in C e basta , e non in c++, ne 
tantomeno in java o uno dei vari scriptin languages.
 
Si fa in C, PUNTO! BAMBOCCIONE DELL'OSTIA!



 
Va be,si fa in C,ma perchè no in C++ ?
 

 un applicativo del genere si fa in C e basta
 
Ma come, non si fa in Cobol?

 un applicativo del genere si fa in C e basta
 
Ora prendo lo spunto per una digressione tecnica.
Il C (e il C++) è stato largamente usato in passato per la produzione dei sistemi di supervisione. 20 anni fa tutti i supervisori dell'azienda con cui collaboro erano scritti in C (con le librerie dr.Halo per la grafica), e devo dire che abbiamo fatto delle cosine carucce, molte cose girano ancora oggi.
Oggi il C sostituisce l'Assembly nella programmazione del firmware delle schede a bordo macchina. Per una serie di motivi (curve di apprendimento lunghe, costi di sviluppo, potenziale pericolosità) si preferiscono altre strade. Posso tranquillamente affermare: "un applicativo del genere NON si fa in C e basta". Negli anni sono stati usati diversi strumenti, compreso VisualBasic, che io MAI avrei usato per applicazioni del genere, ma che tutto sommato si è rivelato abbastanza adeguato - leggi, se son stati creati problemi, l'origine non è stato lo strumento ma il disegno.
La sfida che forse (*) porteremo avanti è quella di non basarci più su sistemi operativi Windows; oltre a questo scopo io ho in testa che i nostri applicativi di supervisione _devono_ essere cross-platform.
 
(*) Dico forse perché chi propone la sfida non ha le idee ben chiare in testa: pensa di fare una banale operazione di maquillage del supervisore senza modificare l'elettronica o il sistema di comunicazione esistenti. Da un punto di vista normativo la parte elettronica può e deve rimanere immutata; questo però spinge a sistemare i problemi, dove ci sono, non a ridisegnare un supervisore da zero!
 
-- 
Ciao!
Luca
 
 

sistemi di supervisione.
 
Nel mondo embedded (che e' grande) e in quello industriale il C (e C++) e' 
ancora molto usato.
Tutti i progetti industriali che porto avanti sono in C++; nell'embedded e 
nei microcontrollori (almeno in cio' che ho visto io) e' quasi tutto C.
Poi c'e' anche altro, sicuramente, sopratutto quando ci si interfaccia col 
resto del mondo. Ma un sistema di controllo industriale o un sistema 
embedded si fa spesso in C o C++.
 

 ancora molto usato.
 
E' più o meno quel che ho detto io. Però, sinceramente, ti ci metteresti in C++ a far sistemi di supervisione (ocio, il discorso è relativo esclusivamente alla supervisione)?
Io l'ho fatto, oggi non lo farei più.
 
-- 
Ciao!
Luca

Io l'ho fatto, oggi non lo farei piů.
 
Certo che si. A meno che non devi fare il display nella cabina, per cui puoi 
usare quello che vuoi, se il sistema e' critico non puoi usare a mio avviso 
null'altro che C/C++ e con opportune procedure di certificazione.
Conta che ci sono anche quintali di normative da rispettare quando si fanno 
sistemi che possono far danno a persone. E se il fatto che il software si 
blocchi/ritardi/s'incazzi/quant'altro puo' provocare danni a persone (ad 
esempio perche' non ti indica bene l'altitudine e la cabina si schianta), 
beh soccazzituoi.
Pensaci prima di farlo, se succede qualcosa perche' il tuo software si e' 
piantato il culo che vengono a cercare e' il tuo.
 

 piantato il culo che vengono a cercare e' il tuo.
 
Guarda che tu stai SEMPRE parlando di firmware. 
 

news:d85455f9-c601-4c98...@googlegroups.com...

No, parlo anche dell'interfaccia utente. Se succede qualcosa e dipende dal 
fatto che l'interfaccia utente non visualizza bene un dato inducendo 
all'errore l'operatore o, peggio, trasmette male un comando di chi pensi che 
sia la colpa?
 

 sia la colpa?
 
Al di la che - mi ripeto - un impianto industriale, almeno quelli in cui ho messo le mani io, deve funzionare senza supervisione (e quindi le informazioni importanti sono ripetute da strumenti analogici), dimmi: secondo te un dato mal visualizzato dipende dallo strumento che usi per sviluppare, e non dal disegno del supervisore? Consentimi di essere MOLTO perplesso circa questa affermazione (e ti prego di apprezzare l'understatement).
 
-- 
Ciao!
Luca
 

news:d15a8428-d9d7-45d7...@googlegroups.com...

Poi dite che delta11 non ha ragione, eh. 
 


..a questo punto io però vorrei sapere la tua testolina cosa ti dice di 
usare....


 Poi dite che delta11 non ha ragione, eh.
 
Senti, se mi porti motivazioni tecniche un po' più serie di 'ommioddio', allora possiamo discutere - inter nos, stai facendo un bel po' di confusione tra i livelli di software coinvolti in un impianto industriale. Senno' è vero, ha ragione il deltino.
 
-- 
Ciao!
Luca

 usare....
 
D'istinto, ti manderei a cagare, visto il tono; in seconda battuta, ti risponderei 'ma è ovvio, il Cobol'; però sono buono perché lo spunto è interessante. Ma devo fare una piccola digressione.
 
Dunque, a bordo macchina ci sono diverse cose che puoi usare, e ci sono almeno due livelli. L'azienda con cui collaboro impiega:
 
- schede proprietarie (*), progettate per un compito specifico, normalmente con micro Intel; qui la fa da padrone il C, che ha de facto soppiantato l'Assembly;
- a livello superiore, e a meno che non si parli di programmi molto vecchi (**), PLC; tipicamente usano Siemens, ma hanno usato anche altre marche, e hanno anche un piccolo PLC proprietario.
 
(*) per impianti poco complessi tutto viene demandato al PLC;
(**) il PLC un tempo era sostituito da un accrocchio proprietario che veniva chiamato 'coordinatore', programmato con la stessa logica delle schede.
 
A fronte di questo ci sono due 'entità' che consentono l'interazione con l'operatore:
- un pulpito, contenente tutti i comandi (pulsantoni e manopolone) e gli strumenti principali per poter far funzionare la macchina;
- un supervisore di impianto (*), con tre scopi: 1) il setup di macchina, durante la messa in servizio; 2) una presentazione più completa all'operatore dei dati di funzionamento e 3) il log dei dati di funzionamento (a volte per normativa, a volte per puro scopo statistico).
 
(*) anche se la divisione logica permane, anche qui le due entità possono essere integrate in un unico armadio/pulpito.
 
Occorre tenere a mente una direttiva, che spero condivisa: la macchina deve poter girare, magari a ridotta velocità perché con penalizzazioni, ma anche SENZA SUPERVISORE.
 
Da qui in avanti parlo di supervisori, il mio campo.
 
L'azienda un tempo faceva supervisori sotto DOS, in C, con librerie grafiche drHalo; è li che ho iniziato a occuparmi di supervisione per gli impianti di risalita, e credi, è stata una bella pena far stare tutto nei 570k che DOS metteva a disposizione.
Grossomodo dal 2000 a oggi ha lavorato, soluzioni proprietarie a parte (a proposito, bellissima la roba di Pro-Face), esclusivamente sotto Windows - banalmente, Siemens allora non considerava alternative. Li chi allora ha fatto la scelta ha optato per VisualBasic. Perché? perché conosceva solo quello. Io non l'avrei mai scelto (no multithreadig, no OOP, no variabili unsigned, byte a parte, ecc. ecc.), però tutto sommato si è rivelato abbastanza solido negli anni, non ostante quel che ci ha messo l'allora programmatore di turno (tutte le volte che apro il codice mi metto le mani nei capelli).
Io ho introdotto C#, e ci ho scritto i supervisori per campo eolico e fotovoltaico. Presi alcuni accorgimenti (precarico degli oggetti coinvolti, in modo da usare il JITter il meno possibile, impiego oculato dei threads e attenzione alla garbage collection) ho ottenuto prestazioni di tutto rispetto, anche su PC industriali di livello base (che comunque van più dei PC di 15 anni fa).
 
Ovviamente l'azienda va avanti, Siemens non è più così imperativo, e si inizia - ripeto, finalmente - a prendere in considerazione il mondo Linux. Ottimo, ma io ho sempre il tarlo in testa: cross-platform. Devo riuscire a pensare a una cosa che, mutato poco, possa girare tranquillamente su qualsiasi piattaforma. Di ciò che conosco io:
 
C#, con il progetto Mono, è OK.
C++, con QTCreator, è OK.
 
Volendo proprio considerare linguaggi di scripting (ma ne vale la pena?), io opterei per Python, ma solo come backend - a questo punto il front-end dovrebbe essere giocoforza scritto con altri strumenti, e qui io torno a QTCreator.
 
Ci sono sicuramente altre soluzioni possibili, ma di cui non ho esperienza, ed ecco perché, nel momento della scelta, è opportuno sentire voci alternative che segnalino eventuali opzioni interessanti ma ignote.
 
-- 
Ciao!
Luca

 Senti, se mi porti motivazioni tecni[]
 
Nono, hai ragione tu.
 

 Volendo proprio considerare linguaggi di scripting (ma ne vale la pena?), io opterei per Python, ma solo come backend - a questo punto il front-end dovrebbe essere giocoforza scritto con altri strumenti, e qui io torno a QTCreator.
 
Vorrei fare una piccola precisazione.
 
Qt è una libreria grafica multipiattaforma e supporta, fra l'altro, i 
linux embedded.
 
Sulle varie piattaforme usa compilatori diversi e su una stessa 
piattaforma supporta compilatori diversi. Su Windows, ad esempio, puoi 
avere come compilatore mingw o visual studio.
 
QtCreator è un IDE che integra un editor di codice e un editor di form, 
entrambi orientati allo sviluppo nativo c++. Se necessario, puoi creare 
"profili" tipo Release/Debug di Visual Studio, per puntare a diversi 
compilati, anche cross, e fai girare lo stesso codice su WIndows, cambi 
profilo, ricompili, e lo spara sull'emulatore Android....
 
Esistono poi delle librerie che interfacciano vari linguaggi di più alto 
livello, fra cui Python, a Qt. Una cosa che non so dirti, al momento, è 
se la libreria Python permette di usare nativamente i file .ui creati 
dall'editor di form di QtCreator (sono file xml).
 
 


SCADA industriali già esistenti li avete scartati per qualche motivo?
Chiedo eh.
 


Dai su, fate la pace, e dettaglia meglio please, il discorso è interessante.
 


Ma interessante de che, se il culo che balla e' il tuo in caso di 
disastri ti metti a fare i software di controllo industriale con 
linguaggi di livello inutilmente alto o roba di cui non hai il pieno 
controllo (*)? E cosa dobbiamo dettagliare?
 
(*)
E nel "pieno controllo" rientra, ad esempio, l'uso smodato di librerie 
terze per fare cose magari banali.

 Chiedo eh.
 
I costi delle licenze, orientati al numero di variabili. Se ne fai uno, ok, se ne fai qualche decina, inizia a convenire scegliere la strada di lavorare in casa (l'azienda rilascia il supervisore come commodity).
Gli unici che finora hanno, a quel che ho visto, un sistema di licensing sensato son proprio quelli di Pro-Face.
 
-- 
Ciao!
Luca


Rigiro anche a te la domanda: ma allora gli SCADA industriali che ci 
stanno a fare?
 

 controllo (*)? E cosa dobbiamo dettagliare?
 
Ma lo vedi che non leggi? E si che ho scritto una pappardella - forse prolissa, lo riconosco - per spiegare come vengono costruite le macchine industriali dall'azienda con cui lavoro. E ti ho ben spiegato che il controllo è a bordo macchina (PLC/schede proprietarie) e che la supervisione fa - e deve fare - solo supervisione, ma tu: "ti metti a fare i software di controllo industriale con linguaggi di livello inutilmente alto".
 
NONEEE!! STO PARLANDO DEL SUPERVISORE!!!! LA MACCHINA DEVE POTER GIRARE SENZA!
 
Spero di essere stato sufficientemente chiaro, ora. Sennò troverò un altro sistema per dirlo, tranquillo.
 
-- 

 NONEEE!! STO PARLANDO DEL SUPERVISORE!!!! LA MACCHINA DEVE POTER GIRARE SENZA!
 
Il problema, prima che tecnico, e' giuridico. Se succede qualcosa di 
grave E dipende dal tuo supervisore (*) perche' la libreria sarcazza di 
python o java o monicelli (**) ha un bug, e questo stampa fischi per 
cazzi e induce l'operatore all'errore, oppure manda comandi sbagliati 
alla macchina, il culo che salta e' il tuo.
Per cui io mi metto al sicuro usando solo roba di cui ho il pieno 
controllo, tu fai come ti pare.
 
(*) poi magari intendiamo cose diverse per "supervisore".
(**) 
https://github.com/esseks/monicelli
 


Ma dello scada hai pieno controllo (e in ogni caso e' roba che non hai 
fatto tu..). Se scrivi male e' ovviamente colpa tua, ma se c'e' un baco 
da qualche altra parte hai su chi rivalerti. Se usi python e una 
libreria e' bacata ti attacchi al cazzo.
 
Pero' rigetterei il sasso nello stagno su un'altro argomento: secondo me 
oggi si usano troppe librerie esterne per fare anche cose banali, e 
questo e' un problema.

 controllo, tu fai come ti pare.
 
Ah, allora deduco che ti scrivi il sistema operativo, il compilatore, il firmware delle schede del PC industriale che vai a usare noché i relativi drivers, e solo dopo il linguaggio (e anche allora...); perché un supervisore gira sotto un sistema operativo e, anche se scritto in C o C++, usa librerie e runtime.
 
Ti suggerisco peraltro di non essere così tranquillo, perché nella mia carriera di robe strane ne ho viste; ricordo ad esempio un TurboPascal 6 che sballava i calcoli negativi in virgola mobile, ma solo entro un certo intervallo, un C++ Microsoft che aveva una libreria di comunicazione bacata, ecc. ecc.
 
-- 
Ciao!
Luca

 questo e' un problema.
Ma anche prima delle librerie, i copia & incolla di codice trovati via 
google e portati nei sw direi che sono più numerosi ancora...
 

 Niente, a quanto pare non riesci a
 
Ok, hai vinto tu. Ora pero' basta, eh.
 

 questo e' un problema.
 
Questo invece è un buon argomento. Le librerie esterne però sono abbastanza inevitabili. Se vuoi parlare con le apparecchiature Siemens, ti serve la roba loro (anche se, mi dicono, si stanno aprendo a BUS di campo aperti). Se hai a che fare con roba National, idem.
 
E talora non è nemmeno detto che sia un male. Perché devo riscrivere per l'ennesima volta una libreria ModBUS (a meno che non voglia deviare dallo standard) se ce ne sono n+1 che lo fanno egregiamente? Compito mio sarà valutare quella opportuna.
 
-- 
Ciao!
Luca
 

 Ok, hai vinto tu. Ora pero' basta, eh.
 
Non mi interessa vincere. Mi interessa farti comprendere come progetta e lavora un impianto industriale un'azienda che fa automazione industriale da 40 anni e con cui collaboro dal '97.
 
Non suscita la tua curiosità? pazienza.
 
-- 
Ciao!
Luca

 ... Perché devo riscrivere per l'ennesima volta una libreria ModBUS
 
Prendi proprio l'esempio sbagliato :) una libreria modbus bacata (con 
baco rarissimo che si manifesta in casi rarissimi che pero' quel sistema 
generava) ci ha creato bei problemi.
 
Una delle prime cose che ho fatto qui e' stato, laddove possibile, 
svincolare il software dalle dipendenze esterne e riscrivere le cose 
importanti (quella libreria non faceva parte delle cose inizialmente 
riviste in quanto considerato "sicuro", poi ovviamente e' stata corretta).
Poi certo anche io uso le nidaqmx per interfacciarmi con le schede 
national, ci mancherebbe. Ma, e torniamo a bomba, se c'e' un baco li' 
posso dimostrare di aver fatto tutto il possibile usando le cose 
migliori e di aver agito "secondo scienza e coscienza" e il giudice e' 
piu' contento. E posso teoricamente chiamare in causa il fornitore.
 

 riviste in quanto considerato "sicuro", poi ovviamente e' stata corretta).
 
E' ovvio che, ove possibile, meglio poter toccare in giro; proprio a proposito di ModBUS, usiamo NModbus (open) e stiamo pensando di metterci le mani per supportare alcuni fuori standard. 
Questo però, e me lo insegna la mia esperienza, non mette al riparo da problemi. Io di buchi nei compilatori ne ho trovati: pochi (due o tre), ma ne ho trovati. E' per questo che dico che, fatti salvi alcuni ambienti, si può usare anche altro. Insomma, se per gli impianti CE hanno usato VB6 per fare il supervisore (scelta per vari motivi pessima), e son li che vanno con pochi problemi da decenni, e quei pochi problemi son legati a buchi di disegno, temo che stiamo parlando abbastanza di cose irrilevanti.
 
-- 
Ciao!
Luca

con pochi problemi da decenni, e quei pochi problemi son legati a buchi di
 
Io continuo a dirti che per compiti seri bisogna usare gli strumenti giusti 
e tu che continui a rispondermi che una volta tuo cuggino ha gestito una 
centrale nucleare in javascript e non e' esplosa.
E' evidente che hai ragione tu. 
 


 
Ciao,
mi scuso se intervengo OT, ma quanto sopra mi interessa in merito alla 
responsabilità civile/penale dello sviluppatore, avendo in passato 
chiesto, inutilmente, una polizza assicurativa per i rischi connessi.
Probabilmente ora le cose saranno anche cambiate.
Hai per caso i riferimenti delle sentenze che citi?
Grazie, ciao. Stefano.

 C++, con QTCreator, è OK.
 
FLTK?
Non è Qt, ma è molto leggero, semplice, portabile, e il suo lavoro lo fa.

 affermano.
 
la cassazione si pronuncia su fatti precisi e dubito si possa 
generalizzare, è chiaro se fosse bacata la curl non è che puoi andare 
dall'autore a dire "oh guarda che io la tua libreria l'ho usata in una 
applicazione critica e sono morte 15 persone per colpa del tuo bug". deve 
esserci una responsabilità diretta sull'accaduto, non è facile ci sia ma 
non è neanche uno scenario impossibile. 

 centrale nucleare in javascript e non e' esplosa.
 
Se questo hai capito, non hai capito una mazza e, temo peggio, non vuoi capire.
Spiace, non vali il mio tempo.
 
-- 
Ciao!
Luca
 

 Hai per caso i riferimenti delle sentenze che citi?
 
 
Parto da in fondo. Non ho i riferimenti. Ho letto le sentenze, ma non me le son tenute. Se hai un amico avvocato, sicuramente te le trova in poco tempo.
 
Per quanto riguarda l'assicurazione, anni addietro avevo cercato un'assicurazione adeguata, per scoprire che anche quelle professionali, che teoricamente dovevano essere funzionali, coprivano tutto TRANNE il rischio di dolo derivante da errori durante il mio lavoro di sviluppatore. Confrontandomi con il broker che all'epoca mi seguiva, mi ha confermato la cosa. Spero che nel frattempo le cose siano cambiate. In ogni caso, ti suggerisco di andare oltre l'intestazione e di verificare MOLTO bene cosa è coperto e cosa no, dall'eventuale polizza che dovessero proporti.
 
-- 
Ciao!
Luca


Gli darò un occhio. Grazie.
 
-- 
Ciao!
Luca

 applicazione critica e sono morte 15 persone per colpa del tuo bug". 
 
In realtà è una cosa abbastanza complicata da determinare, dal momento che stiamo parlando di apparecchiature complesse. Esempiello.
L'altranno una funivia, in fase di manutenzione, quindi non esercizio, non si arresta e le cabine vanno in velocità a sbattere contro i muri delle due stazioni.Per fortuna nessun morto, ma feriti in modo serio i tecnici che erano a bordo di una delle cabine.
 
Ovviamente, il giudice compie l'atto dovuto di metter sotto inchiesta tutti: il gestore, il costruttore e chi ha fornito l'elettronica. Ovviamente, giorni di panico. Le prove documentali (i log del supervisore) han dimostrato che l'impianto girava con tutte le protezioni escluse; non si capisce come il gestore abbia potuto decidere di togliere tutto, tuttavia questo scagionò completamente sia la costruttrice che l'azienda con cui collaboro.
 
-- 
Ciao!
Luca

 coperto e cosa no, dall'eventuale polizza che dovessero proporti.
 
Fu quello che dissero anche a me: una società canadese mi chiese, per 
poter lavorare con loro a partita iva, di sottoscrivere una polizza.Il 
mio assicuratore cadde dal pero. Speravo le cose si fossero evolute, 
soprattutto con la tendenza odierna delle compagnie a voler assicurare 
tutto. Evidentemente hanno ritenuto che, nell'impossibilità di una 
quotazione definita dei possibili danni, il rischio fosse troppo 
elevato...
Ciao, Stefano.

 sviluppatore. 
 
il dolo in effetti è un po' difficile trovare una compagnia che 
l'assicuri.
forse ti riferivi alla colpa grave.

 forse ti riferivi alla colpa grave.
 
Vero. Pensato colpa, scritto dolo. Refuso tipografico. Grazie.
 

 Gli darò un occhio. Grazie.
 
Da noi usiamo dei software con l'iterfaccia grafica scritta in FLTK, che non hanno mai dato problemi. E sono programmi grossi (per intenderci, hanno componenti che girano a regime per settimane, arrivando ad occupare 3000 e passa cores simultaneamente su 5 terabyte di RAM distribuita tra i vari nodi), l'interfaccia grafica e' molto spartana, ma non ha mai dato problemi. FLTK viene distribuito coi sorgenti in una sottodirectory, si compila in una manciata di minuti, piccolo, snello, discreto, che funziona. Qualcosina con FLTK l'ho scritta anch'io e posso dire che dal punto di vista dell'interfaccia grafica non e' niente di eccezionale, pero' e' facile integrarlo nel progetto usando CMake, e grazie a CMake non e' un problema portarlo per Windows e Mac  (CMake e Qt non e' cosi' immediato). Occupa pochissimo spazio, non devi scrivere tonnellate di codice come con QT, si puo' creare un OpenGL display, ed e' documentato discretamente (
http://www.fltk.org/doc-1.0/toc.html
). Insomma e' un gioiellino, ha l'essenziale, e ci puoi fare comunque cose interessanti.
 
Di contro, se il tuo programma e' massivamente improntato sull'interfaccia grafica piuttosto che sulla componente computazionale, probabilmente Qt e' la scelta migliore. Qt ha un IDE degno di questo nome, mentre FLTK ha FLUID che e' una specie di QTCreator ma mooolto striminzito (a me non serve, visto che programmo ancora con vim e gedit). Insomma, per le mie esigenze Qt e' un pachiderma, le linee di codice crescono esponenzialmente, ha una valanga di librerie accessorie, ben documentate, sicuramente anche ben scritte, ma che a me fondamentalmente non servono.