Newsgroup: it.lavoro.informatica
Titolo: Sistemi di supervisione con Linux?

Ciao a tutti.
Oggi ero presso un cliente per cui sto sviluppando del software.
Questo cliente fa elettronica industriale, e quest'anno gli sta andando
particolarmente bene: hanno due capannoni interamente pieni di macchine
in lavorazione o prossime alla consegna.
Bene, chiacchierando col mio interlocutore notavo come tutti i sistemi
di supervisione - uno per ogni macchina - girino sotto Windows. E,
facendo due conti, viene fuori una bella cifretta. Allora gli ho
buttato li qualcosa del tipo: perché voi non usate Linux come SO di
supporto? Questo PC deve fare solo il supervisore di impianto e basta,
in fin dei conti, e con quel che risparmiereste di licenze vi potreste
pagare l'acquisizione della cultura necessaria a mantenere nel tempo
una cosa a costo molto più basso.
Il tale mi dice che si, in effetti per loro sarebbe comodo, perché si
potrebbero evitare da un lato Windows che installa tutto lo scibile
umano, dall'altro i clienti che installano giochi su supervisori per
impianti di risalita. Il problema, mi dice, è che non hanno trovato
strumenti di sviluppo sufficientemente rapidi - loro sono abituati a VB
- , che avevano provato Delphi ma che poi la cosa era finita li. Io
francamente avevo pensato a Java, che secondo me è meglio almeno come
portabilità rispetto a .NET (nel senso, se stai progettando la
migrazione a .NET, forse faresti bene a fare un pensierino anche a
Java).
Io però non ho mai sviluppato per Linux, l'ultimo mio sviluppo sotto un
sistema Posix risale agli inizi degli anni 90 (erano uscite le prime
SparcStation e giravano con quello che allora si chiamava solo SunOS).
Quindi mi è venuta questa curiosità, più per cultura mia che non per
untilità, dato che il cliente continuerà con VB per un bel po'. Voi che
strumenti utilizzereste per sviluppare un sistema di supervisione (uno
SCADA) da far girare sotto Linux?
-- 
Ciao!
Luca

 facendo due conti, viene fuori una bella cifretta.
per curiosita', quanto incide in % il costo di win sul sistema
macchina+controllo?

 macchina+controllo?
Ah, l'incidenza è abbastanza ridicola, siamo a livello di punti
percentuali. Il fatto è che di questi punti percentuali ce ne sono
diverse decine - per non dire un paio di centinaia solo quest'anno...
-- 
Ciao!
Luca

 wrote in message
news:dc8ora$hf7$1...@area.cu.mi.it...

quindi, mettiamo di risparmiare 20.000 euro di s.o.
ci paghi il porting del software, la formazione degli sviluppatori, la
formazione di un sistemista/sviluppatore etc?
inoltre, la macchina avra' un utente non dell'azienda che deve fare alcune
cose sul pc? fosse anche lanciare un programma se va via la luce....?
accetterebbe un cambio di s.o?

 - , che avevano provato Delphi ma che poi la cosa era finita li. Io
Beh, guarda, se lo vogliono sviluppare da se, allora il primo anno di
sicuro non risparmiano. Come ti han fatto notare, devi trovare qualcuno
gia' pratico che possa formargli delle persone e devi riconvertire il
software esistente, compreso l'ambiente di sviluppo. Di roba
ingannevolmente facile come VB per Linux, per fortuna, non mi pare ve ne
sia. E Java lo eviterei come peste.
Gli anni successivi poi risparmiano di sicuro, sulle licenze e un po'
anche sull'hardware.
Non sapendo cosa faccia la loro applicazione non azzardo troppo, ma piu'
che il fare in casa, io farei due conti sul far sviluppare a terzi la
piattaforma Linux. Magari dotata di interfaccia di controllo web, cosi'
che lo sminchiamento della workstation diventa un fatto irrilevante per
l'impianto. O anche un sistema singolo autonomo, indubbiamente molto
meno facile da demolire rispetto ad un Windows (per quanto, giocando con
le policy, pure li qualcosa si puo' fare).
Ci sara' qualche piccola societa' o qualche intraprendente autonomo
dalle loro parti in grado di buttare giu' un minimo di analisi? No, io
sto a Roma, mi sa un po' troppo lontano. :)
	ridiscesamente,
	   Cthulhu
-- 
http://www.rlyeh.it/Rantolii/

 SCADA) da far girare sotto Linux?
io al momento lo farei in java non per moda ma per quello che è 
portabilità , parti con i loro win e passi dopo test a linux , e 
dovrebbero (condizionale d'obbligo) girare uguale.
poi bisogna vedere tutto il progetto , magari ci sono controindicazion 
italmente grosse che non le hai /abbiamo prese in considerazione , ma 
non credo.
Sviluppare in c/c++ fattibile ma oneroso per di + se lo vuoi fare 
portabile , insomma dipende come in tutte le cose.
my 0.5 cent

 SCADA) da far girare sotto Linux?
La butto li' :  perche' non considerare python ?
L'ho visto ormai usato per far tutto e devo dire che mi ha fatto una 
gran bella impressione

 luce....?  accetterebbe un cambio di s.o?
Mi sa che hai troppa fiducia nell'utente che usa questo tipo di
applicazione. L'imperativo normalmente è: applicazioni autopartenti,
con bei pulsantoni e magari un bel touch screen, in modo da far sparire
quelle cose strane tipo tastiera e mouse.
Ah, visto che ci sono, e che ci sono ancora moltissimi supervisori che
girano sotto DOS, non vedo dove sia il problema.
PS. Sotto Dos perché il ciclo di vita medio, ad esempio, di un impianto
di risalita è di una ventina d'anni, e fino almeno al '96 i supervisori
erano sotto DOS.
-- 
Ciao!
Luca

 (per quanto, giocando con le policy, pure li qualcosa si puo' fare).
Beh, se hai mai visto uno SCADA, sai cosa fa la loro applicazione, e
sai perché non è pensabile in questo caso l'idea dell'interfaccia web
(tempi di refresh di mezzo secondo sono talora già troppo lunghi).
In ogni caso, non è che loro vogliano svilupparlo, è che mi era venuta
'sta curiosità.... :)
-- 
Ciao!
Luca

 gran bella impressione
Ci avevo pensato, ma ho un dubbio. Python č un interpretato, e non
vorrei che in questo caso fosse troppo lento. Almeno Java ha un
compilatore JIT.
-- 
Ciao!
Luca

 ha scritto nel messaggio
news:%RSFe.17785$fm.13...@news4.tin.it...

secondo me per le problematiche di accesso alle reti dati industriali
(profibus, CAN e CANOpen, FieldBus, ModBus, etc. etc.) l' accesso
tramite le componenti Linux in C dovrebbe essere abbastanza veleoce.
Non so se Java ha tutti questi driver già sviluppati e non so se è oneroso o
no,
sia in termini di tempi che di costi/uomo, lo sviluppo delle stesse
componenti in
java.
Saluti

 Java).
Il tipo di applicazione mi farebbe pensare più a soluzioni basate su 
C/C++. Ci sono ambienti in cui si può essere molto produttivi anche 
sotto linux (tipo Kdeveloper),le prestazioni sono garantite, e non devi 
mettere in mezzo layer virtuali di sorta... ovvio che pero' se cerchi lo 
sviluppo point&click di VB, siamo lontani anni luce...
-- 
Fabrizio "Hermooz" Ermini

 cerchi lo sviluppo point&click di VB, siamo lontani anni luce...
Io sarei d'accordo, ma pensavo che, se gli vanno bene le applicazioni
scritte in VB, magari un'applicazione con un bel compilatore JIT dietro
può andargli altrettanto bene. Ovvio che le velocità che hai con C/C++
compilato te le sogni. Ovvio però che usando C/C++ la portabilità se ne
va a donne di facili costumi.
-- 
Ciao!
Luca

 
Dalla tua risposta si evince che mi sono spiegato male. Cerco di fare
un passo indietro.
Quando viene messo un supervisore su una macchina, il supervisore
accompagna la macchina per tutto il suo ciclo di vita, fatti salvi
interventi per soluzione problemi (ma questo succede nel primo periodo
di vita). Se un certo giorno decido di fare supervisori con VB sotto
Windows, non è che il giorno dopo vado a sostituire tutti i supervisori
in funzione: quelli già in servizio rimangono nella situazione
precedente; quelli nuovi avranno il nuovo supervisore.
Ciascuna macchina è poi un caso a se, che c'è davvero poca
standardizzazione. Per cui, il lavoro consueto è quello di prendere un
supervisore già esistente e adattarlo alle esigenze della nuova
macchina.
Infine, tutti i supervisori dell'azienda sono di tipo proprietario,
così come le schede e il bus di campo; anzi, il bus di campo è
proprietario, ma hanno usato anche cose differenti, tipo CanBus o
ProfiBus.
-- 
Ciao!
Luca

 ProfiBus.
ma non serve real time?
tra l'altro ho amici che sviluppano per canbus (che non e' un mezzo pubblico
usato da bobi) in vc++ per controllo di macchine in cui e' importante la
base tempi. ma win non e' real time, come si fa?

 va a donne di facili costumi.
la portabilità 'in teoria' cambi solo compilatore , il problema è che il 
codice lo devi scrivere che sia portabile (e li la vedo molto dura).

 portabile , insomma dipende come in tutte le cose.
io lo farei in C++ con librerie portabili al 100% per la gui, ma il 
problema sono eventuali altre librerie o sorgenti preesistenti.
Certo è che se puoi farlo in java, quindi rifare tutto da capo, puoi 
anche farlo in C++ con librerie e toolkit portabili.
Hai il vantaggio delle prestazioni del C++ e della portabilità ma hai lo 
svantaggio di cercare o formare qualcuno su toolkit portabili C++ e di 
rifare tutto il supervisore.
Ci vorrebbero maggiori dettagli, ma se il sw è qualcosa di gestibile, a 
livello di reingegnerizzazione totale e come costi, io sceglierei C++ e 
librerie portabili. Chiaramente bisognerà ricompilare non è proprio 
comodo come java, ma ai fini preposti non è assolutamente un problema, 
l'importante è avere gli stessi sorgenti per le varie arch di destinazione.

 va a donne di facili costumi.
Non è vero. La portabilità per applicazioni di quel tipo è spesso 
raggiungibile senza problemi a meno che non si utilizzino librerie 
particolari principalmente per lo scambio dei dati.
In ogni caso la portabilità viene meno quasi esclusivamente (spero 
soprattutto in questo caso) per la gui, e questa la puoi sviluppare 
senza alcun problema, nemmeno di licenza, con toolkit portabili, come 
per esempio wxwindows.

 importante la base tempi. ma win non e' real time, come si fa?
Per una precisa logica di costruzione, nonché - credo - per alcune
normative. Le macchine che loro fanno sono autosufficienti - leggi,
devono essere indipendenti dal funzionamento del PC - , per cui la base
tempi è abbastanza poco importante. Va peraltro notato quanto sia vero
il discorso che facevi tu, dal momento che proprio ieri stavo vedendo
alcuni test con pacchetti al millisecondo, e il grafico dei tempi era
quanto di più erratico si possa immaginare.
-- 
Ciao!
Luca