Newsgroup: it.lavoro.informatica
Titolo: Automazione

Ciao a tutti,
vorrei avere i vostri illustri pareri riguardo al lavoro nel settore 
sviluppo sw per automazione.
In particolare sarei curioso di sapere quali sono le differenze più grosse 
che si riscontrano rispetto allo sviluppo di sw di tipo più tradizionale 
come gestionali, erp, ecc. Mi interesserebbe sapere l'opinione di qualcuno 
che ha provato entrambe le cose.
Non parlo tanto delle differenze tecnologiche (C/C++ e Assembly piuttosto di 
C# o Java, sistemi operativi realtime piuttosto che windows, ecc.), quanto 
ad aspetti più "caratteriali" del lavoro.
Una grossa differenza che mi viene in mente è ad esempio che non esiste 
l'utente finale, cioè colui che ti bersaglia di richieste "vorrei avere la 
stampa di questo, vorrei un pulsante che mi apre questa pagina, vorrei 
aggiungere questi campi, spostare questi altri, eliminare quella colonna, 
cambiare questo calcolo, ecc."
Un'altra differenza che già conosco è la necessità, lavorando in tale 
settore, di compiere trasferte anche medio-lunghe per installare gli 
impianti.
Vorrei pareri obiettivi, tralasciando i gusti personali: è chiaro che se io 
sono un appassionato di elettronica/tecnologia preferisco sviluppare su un 
sw per pilotare un dispositivo elettronico piuttosto che scrivere una 
procedura di contabilità.
Grazie a coloro che mi risponderanno.

 come gestionali, erp, ecc.
che se fai una cazzata manovri qualcosa di fisico, quindi fai male o 
alla peggio ammazzi qualcuno. Magari per aver dimenticato che esiste il 
buffer overflow quando scrivevi il programma di una saldatrice e questa 
inizia a saltare per tutta la ditta assetata di sangue umano.
-- 
Michael: "Who are you people?"
The artist formerly known as Henry Gale: "We are the good guys..."

 alla peggio ammazzi qualcuno
Non sarebbe certo addebitabile al programmatore...
Il reparto di test e controllo qualità cosa viene pagato a fare!?! 
-- 
__________________________________________________
Luc (33, CO)
MS Visual Studio developer - Programmer since 1985
__________________________________________________

 Non sarebbe certo addebitabile al programmatore...
si vabbeh, a te per farti capire che e' una battuta devo telefonarti il 
giorno prima?


 Grazie a coloro che mi risponderanno.
chiedi pure.

 impianti.
Qualcuno ci deve andare. Non necessariamente chi ha scritto il software.

l'utente finale, cioč colui che ti bersaglia di richieste "vorrei avere la 
Scordatelo :-)
L'utente finale e' sempre li' a chiedere modifiche all'ultimo minuto,
spesso fino a stravolgere il piano originale.
La differenza e' che di solito modifiche all'ultimo momento
coinvolgono anche l'hardware oltre che il software.
Cioe' in genere piu' persone che stramaledicono i commerciali e i
clienti :-)
Poi bisogna vedere che "automazione e automazione" a cui ti riferisci.
Sviluppare un qualche aggeggio per un'industria automobilistica e' una
cosa totalmente diversa che sviluppare un aggeggio per l'industria
alimentare o per quello medico o per un magazzino o per uso militare o
per uso domestico.
Fox l'ha messo come battuta ma e' comunque vero che il SW che sviluppi
per l'embedded e' molto piu' critico e delicato del sito web o della
contabilita' e potenzialmente MOLTO piu' pericoloso, in grado di fare
danni.
Un "semplice" dosatore per vernici in ambiente critico puo' causare
esplosioni.
Bisogna fare molta piu' attenzione e programmare tenendo conto di
molte piu' cose, usando piu' trucchi per ridurre il piu' possibile
effetti indesiderati e devi sapere ESATTAMENTE quello il codice fa e
come lo fa.
Non solo devi conoscere un linguaggio molto bene ma anche come questo
viene compilato/gestito dal processore.
Poi per certi ambienti la conoscenza di come si comporta un SW deve
arrivare a livello base del processore, fino a prevedere come un
processore reagisce in determinate condizioni critiche.
Ad esempio per progettare un controllo per cooktop abbiamo dovuto
vedere come diversi processori reagivano in un ambiente dove le
temperature andavano da 40 a 120 gradi e ti assicuro che si comportano
in modo diverso, ad esempio le frequenze di clock cambiano facendoti
saltare i timer, ecc. forzandoci a trovare dei workaround (in genere
si lavora insieme la ditta che produce il processore) per avere un
ambiente il piu' stabile e affidabile possibile.
Ovviamente l'hardware e' parte integrante del software e viceversa,
non puoi progettare una cosa senza sapere l'altra.
Il goal e' di ridurre al minimo gli effetti indesiderati non tanto in
situazioni prevedibili, ma sopratutto in quelle imprevedibili.
Piu' riesci a scrivere un firmware capace di reagire in modo sicuro
alle cose non previste, piu' sei un automation developer in gamba.
IMHO ovviamente e' un tipo di lavoro molto piu' divertente,
affascinante e stimolante che sviluppare EDP :-)
Specie poi ultimamente, con l'ingresso in embedded sempre piu'
massiccio di connessioni di rete.
A tutto quello devi aggiungere anche la sicurezza che in ambito
embedded e' considerata una cosa altamente critica.
Un cracker (
http://catb.org/jargon/html/C/cracker.html
) che entra in
un sito al limite cambia qualche pagina.
Un cracker che entra in un apparato di controllo di un'industria puo'
fare danni e uccidere qualcuno .. prova a pensare ad un cracker che
entra nel sistema di controllo di una centrale elettrica ad esempio.
In genere per queste e altre ragioni, entrare nell'ambiente embedded
richiede molto piu' tempo e affiancamento rispetto ad altri ambienti
in IT.
Non ci si improvvisa progettisti firmware.
Se riesci, metti le mani su System Embedded Design
(
http://www.embedded.com/
) e su Circuit Cellar Ink
(
http://www.circuitcellar.com/
) due riviste dove si trovano moltissime
informazioni, spunti per progetti, trucchi, anche lezioni su vari
argomenti relativi all'embedded.
IMHO un must per chi gioca nell'embedded.
Ciao
	STeve
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://aledeniz.blogspot.com/2006/11/le-faq-di-itlavoroinformatica.html

 giorno prima?
Non sembrava una battuta, anzi, una questione che esce fuori spesso tra 
sviluppatori, tester e "capi".


 Non ci si improvvisa progettisti firmware.
Uh: questo lavoro quindi è off-limits per i guga-guga, pare.
F.B.
(non ti sto prendendo per il culo; facevo una constatazione amara... 
vagheggiavo l'utopica selezione naturale dei guga-guga, tanto per mandare a 
male i cetrioloni) 

Si trova qualche rivista che parli di embedded in edicola?Ho visto che
su IoProgrammo ogni tanto ci sono alcuni articoli, ma non tutti i mesi.



Io ricordo bene la notevole differenza dell'ambiente di lavoro, fare
automazione è sicuramente più stancante fisicamente, certo poi tutto è
questione di abitudine, però trovarsi a fare debug con il portatile
appoggiato sul carrellino degli atrezzi di un collega meccanico, mentre
tutto intorno ci sono rumori di ogni genere, la temperatura è sui 30 gradi
abbondanti con una bella umidità, e magari ti devi pure fare un po' di
arrampicata qua e la sul telaio della macchina per verificare il
funzionamento di sensori e attuatori vari, non è che sia il massimo...
Metti in conto anche l'attenzione costante che devi avere, sia per non
fare male agli altri, ma anche per non farti male proprio tu, e il quadro
che ne esce è abbastanza stressante.
Ciao, Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 richieste possono essere saltate difendendosi dietro congetture tecniche.
E in quale campo c'è cultura informatica?


Purtroppo è off-limits anche per chi vorrebbe imparare questo lavoro ma non 
avendo l'esperienza necessaria non trova chi gli dà questa possibilità. 

che ne esce è abbastanza stressante.
Ricordo ancora alcune "sedute" di debug fatte in fonderia, oppure in
mezzo a telai o in officina :-)
La piu' divertente e' stata una macchina conta-bulloni, quando andava
c'erano circa 130db di rumore, per cui era obbligatorio usare tappi
per le orecchie, montata in un officina con 3 dita di grasso sul
pavimento.
Con (allora) un incredibile "portatile" carrellabile (circa 40 kg :-)
) con floppy da 8" :-)
Anche solo riuscire ad evitare il grasso sui floppy era un'impresa
mica da ridere :-)
Sigh ... bei tempi :-) Adesso vai con il minimicrolaptopchemancosivede
:-) e con il wireless puoi stare lontano dalla macchina.


Si trova qualche rivista che parli di embedded in edicola?
Non ne ho la piu' pallida idea ma a naso direi di no.
In genere non e' materiale da hobbisti, nel senso che non fa mercato a
livello hobbistico.
Credo siano poche le persone che per hobby si mettono a progettare
contapezzi o movimentazione merci o apparati tlc o automotive.
L'unica rivista che conosco che "un pochino" supera il divario e'
appunto CCINK, ma non definirei appunto il tipico hobbista da edicola
chi compra CCINK.
C'ya	



Io sono stato più fortunato... all'inizio mi sono divertito con i PG della
Siemens, i loro portabili proprietari che in italiano si chiamavano
"valige programmabili", ti lascio indovinarne il motivo...
Una volta ero attrezzato con contemporaneamente con due PG davanti ad una
macchina, occupavo tutto il carrello di un collega meccanico, praticamente
su un PG funzionava l'interfaccia di comunicazione con il PLC ma non il
programmatore di flash, e sull'altro viceversa. Se chi stava attorna
avesse saputo il motivo di tutto quall'ambaradan, invece si credevano che
il motivo fosse chissà cosa... :-)


 :-) e con il wireless puoi stare lontano dalla macchina.
Nostalgico...del piffero :-D
Te lo darei io il "portatile" carrellabile da 40 kg, da portare in 
spalla per 10 km però.
Ma dico io rimpiangere l'officina unta, rumorosa e calda come il Sahara.
Sarebbe come rimpiangere la Mazzamauro quando si va a letto tutte le 
sere con Cindy Crawford ;-)

Ma dico io rimpiangere l'officina unta, rumorosa e calda come il Sahara.
No, rimpiango i miei 20 anni :-) e le prime esperienze lavorative.
C'mon :-)


jarod ha scritto:

Parlo per me, fare automazione mi dava più soddisfazione, ci perdevo
veramente parecchio tempo nel star li a guardare le macchine che
eseguivano il loro processo sapendo che ogni movimento, tutte le
sincronizzazioni, insomma "la vita" della macchina, dipendeva da un sw che
in qualche modo conoscevi e avevi in parte sviluppato.
Era bello, davvero, non so se in altre contesti ci possa essere questa
specie di "contemplazione", ma non credo di certo nel vedere usare un sw
di contabilità...
E' un po' come se la Cindy fosse frigida, mentre la Mazzamauro con
moooolta esperienza :-)


 su IoProgrammo ogni tanto ci sono alcuni articoli, ma non tutti i mesi.
http://www.vnu.it/ao/

 un sito al limite cambia qualche pagina.
Quindi se qualcuno ti cracca il sito della tua banca con le tue
credenziali e ti azzera il tuo conto non c'e' nulla di pericoloso? :-) Se
il software del trading online va in tilt quando i mercati asiatici sono
in rialzo e la borsa perde centinaia di milioni (ovvero parecchie aziende
chiudono e molti saranno licenziati) non esiste nessun danno?
Insomma, non generalizzare troppo dai...


Insomma, non generalizzare troppo dai...
Qui dovremmo andare nel filosofico, perche' un sistema dove una ditta
chiude per colpa di un glitch e' un sistema totalmente sbagliato IMHO.
Io sto parlando di danni fisici, a meno che uno sia depresso e si tiri
un colpo per aver perso soldi, in genere una manomissione di un dato
non e' "pericolosa".
Scocciante, irritante, infuriante quello si'.
Non sto dicendo che non e' grave ! Ma solo che non e' un "danno" nel
senso fisico e in genere non rischi la morte.
Ad esempio una pressa su un braccio fa lo stesso danno e lo stesso
male indipendentemente dalla cultura, dal posto e dalla persona.
Se sei a 8000 piedi d'altezza in aereo e il computer di bordo va in
tilt, la cosa e' dannatamente piu' grave che chiudere qualche conto in
banca.
Ecc. ecc.
Io vedo una differenza abissale tra i due tipi di pericolo e quindi la
necessita' di un approccio totalmente diverso nello sviluppo del
codice.
Per me .. per te magari e' la stessa cosa, che dirti ?
C'ya


 C'mon :-)
E s'era capito che rimpiangevi la giovinezza :-)
Caro vecchietto, ti dirņ sto meglio adesso di quando avevo 20 anni e non 
li rimpiango per niente ;-)

 moooolta esperienza :-)
Si ma la Crawford disponibile e molto esperta l'è n'altra roba ;-)

 Per me .. per te magari e' la stessa cosa, che dirti ?
Innanzitutto parlavamo di danno e non di pericolo. Sicuramente e' piu'
pericoloso per un essere umano un software che controlla un qualsiasi
aggeggio meccanico che possa far male fisicamente ovviamente ma il danno
e' un altra cosa. E' un software di trading online che va in tilt per un
giorno crea un bel danno. Poi ovvio non tutti ci occupiamo di trading
online come non tutti gli sviluppatori in automazione fanno software per
il controllo degli aerei (qualcuno sviluppera' il circuito per il
giocattolino del bambino per far uscire la voce della mucca e della capra,
tanto per dirtene una). Ma in generale non credo che sia onesto il tuo
discorso perche' puo' essere interpretato che sia un settore in cui serve
la qualita' mentre in altri non serve perche' a questo punto stai dando
ragione al tipico imprenditore da quattro soldi che assume gugaguga per
prodotti di scarsa qualita' tanto e' sicuro che non serve di meglio. Il
pericolo esiste anche per un trasportatore di materiale pericoloso, un
infermiere che manipola sangue infetto, il personale della pulizia che per
sbaglio pulisce la tazza del water con l'acido.... sono piu' importanti
per questo? Per me no, ogni lavoro ha una sua importanza e una sua
criticita', il fatto che qualcuno possa fare piu' danni di un'altro non lo
rende piu' importante.


rende piu' importante.
Infatti. Ma lo rende piu' pericoloso.


li rimpiango per niente ;-)
Beh ... in genere sono con te, ma quando ti alzi dalla sedia con il
mal di schiena o inizi ad avere il fiatone dopo appena 6 miglia di
camminata nel wilderness ... beh, qualche rimpianto mi viene :-)
Seriamente, nello specifico un po' rimpiango anche quel lavoro perche'
era vario.
Vero, a volte dovevi carrellarti il sistema di sviluppo (un bel Mostek
z80 per chi se lo ricorda, sostituito da un Sgs 8 ...) in posti non
propriamente belli, ma la varieta' dei problemi da affrontare devo
dire che e' stata raramente raggiunta negli anni a venire.
In pochi anni ho sviluppato macchinari per quasi ogni tipo di
industria, da meccanica a chimica, alimentare, magazzini, ecc.
Quello un po' lo rimpiango, la varieta' delle sfide e le cose che
potevi imparare, non solo software ma anche hardware.
Ora sono piu' specializzato, mi piace sempre quello che faccio ma c'e'
un che di monotono che stona.
E poi con la tecnologia che c'e' oggi le cose possono essere rese
molto piu' semplici, anche e sopratutto per chi sviluppa.
C'ya
	Steve


 molto piu' semplici, anche e sopratutto per chi sviluppa.
Per fortuna...pensa dover stare dietro oggi alle fisime tecnologiche dei 
clienti (e wifi, bluetooth, sms, mms) a colpi di assembly.
Con la fretta maledetta che hanno poi.

Con la fretta maledetta che hanno poi.
E' che li abbiamo abituati troppo bene, e' li' il problema.


 E' che li abbiamo abituati troppo bene, e' li' il problema.
Già. La tecnologia bisognava continuare a darla col camice bianco a quei 
miscredenti ... e dosata con avvertenze d'uso come in farmacia.
-- 
Qui vige l'uguaglianza, non conta un cazzo nessuno. (Sergente Hartman)