Chi Certifica Il Software In Automazione? - facciamo un po' di luce sul sw

[effebi]

Mi sono spesso chiesto se e quando il software va "certificato" o se vanno rilasciate "dichiarazioni di conformita'" su di esso.

Tranne in particolari ambiti (es. aviazione civile) dove ci sono enti appositi e normative stringenti mi sembra che in Automazione non si faccia molto.

Mi riferisco ad esempio ai programmi dei PLC e dei Robot, al codice HDL delle logiche programmabili, al codice C/C++ di sistemi di controllo, agli SCADA.

E, nel caso che la certificazione sia richiesta, chi e' abilitato a rilasciarla? Intendo, che so, basta un corso effettuato dalla Camera di Commercio, (quale corso?) o

e' necessario avere superato l'Esame di stato come ingegnere dell'Informazione o essere iscritti all'Albo o al Collegio?

So che spesso l'opinione corrente e' che il software non sia pericoloso, perche' "tanto ci sono le protezioni fisiche" a valle, ma mi sembra che questo approccio si limitativo. I bambino e' cresciuto, si intrufola ovunque, ed un cattivo software secondo me puo' fare molto male.

Spero che ci sia qualcuno che possa chiarirmi le idee.

P.S. ho consultato cerca/FAQ ma non mi sembra che l'argomento sia gia' stato sviscerato a dovere. Spero solo di essere nel forum giusto, se ce n'e' uno. Se fosse altrimenti, prego gentilmente il moderatore di spostare la discussione.

Grazie a tutti qelli che vorranno intervenire magari portando la loro esperienza di casi concreti.

effebi

[ifachsoftware]

Sicuramente un cattivo software puo' creare molti problemi anche se c'e' da dire che nel campo ristretto dell'automazione industriale la sicurezza non e' demandata al software ma alle apparecchiature elettromeccaniche esterne ... a meno che non si utilizzino dei plc di sicurezza che da qualche anno stanno prendendo piede ed ai quali anche le normative si stanno pian piano adeguando ...

Ciao

[walter.r]

Attenzione !!

La parola "certificato" cosa vuol dire ???

Che il software risponde a determinati criteri di STESURA , oppure a determinati criteri di FUNZIONALITA' ??

Nel primo caso, occorrerebbero leggi, specifiche, metodi, procedure a loro volta CERTIFICATI da poter usare come strumento di verifica e validazione. In tal caso un Ente qualunque potrebbe rilasciare una certificazione di rispondenza a determinati requisiti di stesura.

Nel secondo caso, chi certifica dovrebbe essere in grado di CONTROLLARE NEI DETTAGLI le funzionalità del software in riferimento all'applicazione per la quale è stato sviluppato. Credo che un burocrate di un qualsiasi Ente non sia in grado di fare ciò; l'unico o gli unici che possono riuscire in questo sono gli sviluppatori del software stesso, oppure i collaudatori degli impianti.

Quindi, siamo all' AUTOCERTIFICAZIONE.

Secondo me i termini "software" e "certificazione" sono incompatibili, per ovvie ragioni pratiche.....

[Livio Orsini]

Dal punto di vista normativo è in atto da tempo un tentativo di far passare una nuova privativa: il progetto software deve essere e può essere firmato esclusivamente da un ingegnere informatico abilitato alla professione.

Fortunatamente, sino ad ora, questa ennesima idiozia non è ancora passata. Però, essendo la nostra bella (si fa per dire) nazione patria del diritto e, soprattutto, del rovescio, ptrebbe anche passare, magari infilata come comma 22 in qualche DL sul recepimento della direttiva CE sul dimensionamento delle banane (purtroppo la normativa esiste, come esiste quella sul profumo delle rose ).

La situazione legislativa attuale non provede timbri e firme.

Altro discorso, questo si serissimo, è la qualità del software e relativa certificazione.

Un'azienda che applica le normative ISO9xxx deve certificare anche la qualità dei prodotti software. In pratica l'azienda certifica che tutto il processo di progettazione, realizzazione e collaudo del software rispetta i protocolli e le procedure stabilite.

Se poi tutto questo avvenga realmente o sia solo sulla carta è il vero limite della normativa ISO. Sicuramente l'azienda certificata è soggetta a verifiche ed ispezioni periodiche dell'ente certificatore, però tutti sappiamo bene come vanno queste cose, non solo nel nostro bel paese.....

Modificato: 12 gennaio 2007 da Livio Orsini

[SimoneBaldini]

La certificazione ISO9XXX o successive modifiche VISION ecc.. non certificano il prodotto i la qualità del servizio ma solo che è stata applicata correttamente la procedura dell'azienda. In sostanza per una società di servizi (manutenzione) è certificato che viene correttamente elaborata la chiamata d'intervento per esempio, registrata, che vengono prodotti tutti i documenti interni di registrazione ma non che il problema sia risolto con competenza. Idem per il prodotto, peggio per il software. Il software è un prodotto molto variabile, c'è chi chiede la funzionalità senza badare a come è strutturato, chi invece vuole un software aperto con una dettagliata descrizione per poterlo modificare anche da altre persone. La normativa di qualità non entra nel merito del prodotto ma solo di come viene gestita la commessa di costruzione del prodotto o del servizio. Per assurdo puo' succedere che si produca un prodotto pessimo ma per il sistema qualità è stato tutto perfetto, cioè sono state registrate tutte le attività della commessa correttamente.

Come detto da Livio è in atto una forzatura nel voler atribuire solo a professionisti iscritta agli albi l'autorizzazione per firmare detti software, io credo che sia scorretto per vari motivi. Uno per primo di tutti perchè i migliori programmatori sono dei ragazzini che nel caso verrebbero sfruttati da chi ha la firma, e in secondo luogo perchè un software (almeno nell'automazione) è una componente non un prodotto finito.

[effebi]

Bene, vedo dalle risposte di chi coraggiosamente si e' voluto addentrare nel ginepraio che abbondano i condizionali: potrebbe, dovrebbe, etc.

In pratica, mi sembra di capire, non si fa nulla o quasi. Spero di aver capito male.

Il tutto e' demandato alla buona volonta' o all'etica professionale dello sviluppatore.

Pero' sappiamo come vanno le cose: pressioni commerciali, tempi ristretti, modifiche su altrui lavoro senza la necessaria conoscenza, ed ecco che spesso il pasticcio è servito.

Ma e' possibile che per l'industria del software siamo ancora nel far west? Che non esistano nemmeno autocertificazioni (rilasciate da persone "abilitate" a farlo)?

Non sto parlando di caste protette, come Livio teme, ma semplicemente di quanto accade normalmente per elettricisti, idraulici, termotecnici, etc. Non mi sembra che nessuno si scandalizzi piu' di tanto per questi.

Per Ifachsoftware: I famosi PLC di sicurezza mica avranno all'interno dei teleruttori con l'autoritenuta tagliata, spero. Cio' che li rende sicuri sara' che qualcuno dopo aver fratto le prove del caso avra' dichiarato, certificato, che il sistema (incluso quindi lo strato software di sistema) è sicuro. O no?

Io non vedo molta differenza tra un impianto realizzato a regola d'arte e un software realizzato a regola d'arte. In entrambi i casi ci possono essere casi opinabili e controversi (vedi colore dei fili, etc) , fantatanorme etc., ma e' indubbio che anche per il software si possano stabilire delle regole di stesura e che si possa valutare la funzionalita'. Faccio un esempio stupido, verificare obbligatoriamente che un array non possa essere essere indicizzato oltre i suoi limiti...

E' chiaro che non sarebbe un mondo perfetto, che sorgerebbero delle rotture di...., ma non credo che l'alternativa di lasciar fare a tutti cio' che meglio credono sia la migliore, almeno coerentemente con gli altri settori.

Vabbe', vediamo se qualcuno ha ancora qualche eperienza concreta, altrimenti grazie a tutti.

Ciao

effebi

[Livio Orsini]

I famosi PLC di sicurezza mica avranno all'interno dei teleruttori con l'autoritenuta tagliata, spero.

No! Qui si parla impropriamente di software, sarebbe più corretto parlare di firmware. Con firmware si intende quella parte di programma che, una volta unito al relativo HW, non può essere modificato se non con procededure e attrezzature specifiche, in altri termini non è liberamente modificabile come il software.

Per qualche anno sono stato membro corrispondente del gruppo di lavoro che, nell'ambito dell'Ente europeo, doveva stabilire come e perchè certificare il software dei dispositivi di sicurezza, quindi qualcosina ne conosco.

In questi casi si tratta di sequenze e procedure ben precise, poco complesse e abbastanza facilmente verificabili.

Diverso è il problema relativo al software generico.

La certificazione ISO9XXX o successive modifiche VISION ecc.. non certificano il prodotto i la qualità del servizio ma solo che è stata applicata correttamente la procedura dell'azienda.

Questo è il punto. Sicuramente non sono stato sufficientemente chiaro.

Ci sono due punti singolari in queste normative.

1 - I requisiti minimi delle procedure sono molto generici e di per se insufficienti a garantire la qualitàè del prodotto-servizio

2 - Non esiste una verifica certa che l'azienda segua correttamente le procedure stabilite: è sufficiente che la "carta sia in ordine".

La qualità totale è nata per le tecnologie aereospaziali ed è stata estesa alla fabbricazione dei prodotti militari. Io ho praticamente iniziato la mia vita professionale come funzionario addetto alla garanzia di qualità in un'azienda di questo tipo.

Dai miei ricordi, risalenti a circa 40 anni addietro, le metodologie previste garantivano che tutto il processo di produzione, dall'acquisizione dei materiali, fabbricazione, collaudo, verifiche e imballo del prodotto fossero conformi alle specifiche. Ma se le specifiche non sono corrette? Per evitare questo anche le specifiche sono sottoposte a verifiche continue per evidenziarne eventuali falle.

La medesima metodologia può essere applicata alla progettazione sia Hw che Sw.

E' evidente che non si può imporre al progettista come pensare. Si possono però imporre tutta una serie di verifiche e controlli durante la fase di sviluppo del processo. Si possono e si devono imporre metodologie di sviluppo e di documentazione.

E' evidente che progettare software in questo modo costa. Se venissero applicate seriamente queste metodologie i prodotti dell'azienda di Guglielmino Cancelli non uscirebbero con tutte le falle solite della prima versione e non sarebbero necessari i primi due Service pack o aggiornamenti che dir si voglia.

Sarebbe altresì impossibile, per le aziende di automazione industriale, mandare i loro collaboratori a sviluppare software direttamente sull'impianto, durante la fase di avviamento

Applicando correttamente le procedure, anche quelle molto blande adottate da molte aziende, sarebbe obbligatorio che prima di iniziare la costruzione di un apparato si coniscesse esattamente cosa si deve realizzare.

Vi sembra ovvio? Allora non avete mai lavorato in una tipica azienda di automazione industriale.

[Savino]

Ciao effebi,

... Chi Certifica Il Software In Automazione?

:ph34r:

Ci mancherebbe anche questa!

In pratica, mi sembra di capire, non si fa nulla o quasi. Spero di aver capito male.

Si, infatti penso che non hai le idee troppo chiare... oppure ce le hai ma non ti piace come gira il discorso e allora vuoi alzare i muri che in europa ci sono voluti 50 anni per buttarli giu' .

Il tutto e' demandato alla buona volonta' o all'etica professionale dello sviluppatore.

E questo ti sembra ti poco valore? .. Aggiungerei "reputazione" e sopratutto "esperienza"

Ma e' possibile che per l'industria del software siamo ancora nel far west?

Questa tua personale opinione non la condivido affatto... anzi ce ne sono state fatte dei grandi progressi negli ultimi anni.

ma e' indubbio che anche per il software si possano stabilire delle regole di stesura e che si possa valutare la funzionalita'. Faccio un esempio stupido, verificare obbligatoriamente che un array non possa essere essere indicizzato oltre i suoi limiti...

Vedi se tu indirizzi un indice che non esiste, non riesci a far girare il SW. Mi spiego meglio.. con i tools di programmazione utilizzati oggigiorno, il sistema ti porta a un "Exception" tanto in fase di compilazione oppure di esecuzione.Comunque, anche se tu assambli del codice con un compilatore scarzo di debug, il tuo programma eseguibile non funzionarebbe correttamente oppure ne anche partirebbe in RUN.

Ma pensa te se ci vorrebbero dei certificatori per la stesura del codice, questa sarebbe mondiale vedi un codice potrebbe essere steso in una forma non molto ortodossa (si fa per dire) ma funzionarebbe bene comunque. Ce ne sarebbero altre aspetti molto piu' importanti da curare come ad esempio la gestione della memoria ( evitare i memory leak) , etc... Immagina se io, costruttore di SW, per vendere in Italia dovrei andare da un ente certificatore italiano a farmi autorizzare la stesura del codice , etc.. consegnare le sorgenti a queste persone , che chi a detto che sarebbero in grado di capire tutto cio', etc.. e poi, col copyright come la mettiamo.,non finirebbe mai, o meglio direi finisce che non sarei interessato a vendere in quel paese.

In cambio se tu me dici che "la funzionalita' " del SW dovrebbe venire sottomessa alla " Validation" dal "sistema di qualita'" vigente per essere accettata come regolare, allora SI', questo va bene ed e' gia' cosa che avviene di solito.

Comunque, la validazione di un SW complesso puo' richiedere mesi eppure anni di tempo. Un ipotetico ente certificatore non sarebbe in grado di "certificare" il corretto funzionamento perche ha accettato il modo e forma delle stesure delle sorgenti.

Un SW e' un "oggetto", la sua "Funzionalita'" viene "validata e accettata " per quello che dovrebbe fare. Se non va bene, se cambia per un'altro. Non ce ne sarebbe bisogno di guardare dentro l'oggetto per dire che funzionarebbe bene.

Modificato: 13 gennaio 2007 da Savino

[SimoneBaldini]

Aggiungo solo che nella programmazione esistono molti escamotage, genio del programmatore, che difficilmente possono essere capiti da terze parti. Inoltre come già detto in molti casi con interventi poco ortodossi si riesce a riparare ad errori di progettazione nella fase di collaudo, cosa che se fatta seguendo eventuali procedure richiederebbe la riscrittura parziale di tutto il programma.

Proprio in settimana ero in AerMacchi (oggi Alenia-AerMacchi) per una camera bianca esistente, poichè la Boeing ha imposto determinati parametri e non gli basta solo la carta ma bensì ha installato dei rilevatori nelle stanze (temperatura, umidità, qualità aria e sovrapressione) la AerMacchi si è dovuta attivare per ottenere questi valori. Ma il bello che questi valori sulla loro carta esistevano da sempra ma nella realtà forse non sono mai esistiti. La differenza tra noi Italiani e gli Americani è che loro vogliono dati certi (registrazioni da strumenti in tempo reale) mentre a noi ci basta un pezzo di carta con una firma.

[batta]

So che spesso l'opinione corrente e' che il software non sia pericoloso, perche' "tanto ci sono le protezioni fisiche" a valle...

Non mi pare che questa sia l'opinione corrente. Credo sia chiaro per tutti che un errore software può causare danni enormi.

Da qui a voler arrivare ad una certificazione del software...

Certificazione che, secondo me, non avrebbe utilità alcuna. Sarebbe solo una croce per gli sviluppatori.

Tanto per continuare col tuo esempio, che senso ha esigere, per poter certificare, che venga verificato il corretto utilizzo di un array, quando basta un semplice AND al posto di AND NOT per causare i danni di cui sopra? Come potrebbe l'ente certificatore verificare che tutto il software funzioni correttamente? Il corretto funzionamento del software si ferifica durante il collaudo dell'impianto, con particolare attenzione alle operazioni potenzialmente dannose.

Io ho solo il diploma di perito (e non mi sono mai iscritto all'albo per scelta), ma sviluppo software nel settore dell'automazione industriale da oltre 15 anni.

Che vantaggi ci sarebbero a dover far certificare il mio software, magari da un ingegnerucolo fresco di laurea che non ha mai avviato un impianto in vita sua? Una certificazione non offrirebbe nessuna garanzia. Sarebbe solo un ulteriore costo.

Del resto, anche per un impianto in logica cablata che rispetta la normativa, quali garanzie offre per quanto riguarda il funzionamento corretto? Un contatto cablato N.O. anziché N.C. non è fuori norma, ma causerà sicuramente un funzionamento anomalo.

No! Qui si parla impropriamente di software, sarebbe più corretto parlare di firmware. Con firmware si intende quella parte di programma che, una volta unito al relativo HW, non può essere modificato se non con procededure e attrezzature specifiche, in altri termini non è liberamente modificabile come il software.

Non è proprio così.

Mi è capitato una sola volta di utilizzare uno di questi plc (PILZ) e posso dire che un plc di sicurezza si programma più o meno come qualsiasi plc, salvo dover utilizzare dei blocchi software certificati per gestire le sicurezze a seconda della classe richiesta. Dopo aver rilevato, ad esempio, lo stato di un fungo di emergenza mediante l'apposito blocco, utilizzi poi lo stato come meglio credi.

Anche qui si può fare il confronto con una sicurezza cablata: il blocco software è paragonabile al modulo di sicurezza elettromeccanico, come vengono poi fatti i cablaggi è un altro discorso.

Per quanto riguarda le modifiche software, è necessario disporre del sistema di sviluppo (come per qualsiasi plc), dei sorgenti e della password. A questo punto sei libero di fare tutti i danni che vuoi , ma questo è possibile anche in un impianto in logica cablata con un semplice ponticello, alla faccia di tutte le certificazioni di questo mondo.

[effebi]

Rispondo,

soprattutto a Saverio, non me ne voglia :

No, non è mia intenzione (manco potessi) alzare "muri" di nessun genere.

Sto solo cercando di capire perche' in altri ambiti molti presuppongono ( a ragione o a torto, non so) di dover rilasciare carta anche per cambiare un interruttore living con un magic, mentre per quanto riguarda il software tutto il discorso e' inaccettabile.

Penso che sia propedeutico per coloro che partecipano a questa discussione andare a leggersi la discussione sugli interruttori posta subito dopo di questa. Fatelo se potete, cosi' capirete cosa intendo dire.

Mi sembra evidente che i programmatori sono molto piu' "liberisti" degli elettricisti, termotecnici, etc.

Ma non mi e' chiaro se tutta questa deregulation vada a loro vantaggio e nemmeno se vada a vantaggio del cliente - utilizzatore.

Il fatto di darsi delle regole ( e la carta serve solo come minimale dimostrazione che si sono seguite) potrebbe portare al limitare comportamenti deprecabili come quelli a cui accennava Livio. Certo c'e' il rovescio della medaglia, l'aumento di burocrazia, i costi, il protezionismo, ma io credo che nei settori di cui sopra in cui ci si e' dotati di certificazioni , ecc, la professionalita' sia decisamente aumentata, e che gli operatori stessi non vorrebbero tornale indietro. Magari verro' smentito da qualcuno di loro, vedremo.

Una nota che non c'entra niente con il resto, per quanto riguarda l'esempio degli array che Saverio ha voluto quotare.

Non sempre si ha a che fare con linguaggi fortemente tipizzati (tipo java) che appena sfori un array ti danno una ArrayOutOfBound Exception.

Ci sono linguaggi che lasciano di proposito la massima liberta' al programmatore di fare cose "strane" percui anche gli strumenti di sviluppo debbono lasciar fare. Un esempio a caso ? compilatori "C" di tutte le salse.

Certo e' stato un esempio infelice, ma e' proprio una di quelle situazioni che creano errori a runtime , tipicamente solo in particolari situazioni difficili da individuare durante il test. Pericolo latente.

Siamo a vedere

ciao

effebi

[walter.r]

Io ho solo il diploma di perito (e non mi sono mai iscritto all'albo per scelta), ma sviluppo software nel settore dell'automazione industriale da oltre 15 anni.

Siamo almeno in due, Batta !

effebi , come avrai capito dal mio precedente intervento, sono anch'io assolutamente convinto dell'inutilità di una procedure di certificazione del software, soprattutto nel campo dell'automazione.

Le cose che ti sono state dette da Livio, Batta, Savino, Simone, etc.... sono solo la rappresentazione di una realtà, non teorie.

Su un PC è diverso, l'hardware sai come è fatto. Su un impianto spesso non lo conosci tutto fin dall'inizio, e spesso di cambiano o aggiungono cose a lavoro terminato.

Cosa facciamo, ri-certifichiamo ogni volta che aggiungono un sensore ??

Hai presente i costi ??

Credimi, chi fa il nostro mestiere non ha bisogno di gente che verifichi funzionalità che non sarebbe in grado di capire.

Il nostro ambiente ha bisogno SOLO di un'economia che funzioni, di governi che sappiano fare le cose giuste, di certezze sulla stabilità di tutto il "sistema" Italia.

Non è un certificato che risolve questo ...!!!

[Savino]

Ciao effebi

..soprattutto a Saverio, non me ne voglia

Please allow me to introduce myself, I am Savino ...

Ci sono linguaggi che lasciano di proposito la massima liberta' al programmatore di fare cose "strane" percui anche gli strumenti di sviluppo debbono lasciar fare. Un esempio a caso ? compilatori "C" di tutte le salse

Come ho scritto in precedenza...

anche se tu assambli del codice con un compilatore scarzo di debug

Se tu utilizzi il C oppure Assembler, se al'Instruction Pointer li carichi un indirizzo che non esiste, il sistema operativo si pianta emmetendo un messagio di "out of memory".

quelle situazioni che creano errori a runtime , tipicamente solo in particolari situazioni difficili da individuare durante il test. Pericolo latente.

Non so a quale sistema operativo ti riferisci... per quanto riguardano i sistemi "protetti" avresti meno problemi.

[Livio Orsini]

e posso dire che un plc di sicurezza si programma più o meno come qualsiasi plc, salvo dover utilizzare dei blocchi software certificati per gestire le sicurezze a seconda della classe richiesta.

Batta questo è firmware! Tu questi blocchi non li puoi modificare a meno di perdere la sicurezza certificata! Tutto quello che programmi nulla ha a che vedere con la sicurezza certificata.

Poi, come dici tu tutto, si può fare, anche scablare i circuiti di emergenza. A me è successo. Ho anche ricevuto una lettera maleducata dal direttore della cartiera, che minacciava richieste di danni, azioni legali e, soprattutto, metteva in dubbio la serietà e l'onestà professionale di chi aveva realizzato la macchina.

Dopo vent'anni sono ancora in attesa delle sue scuse ,dopo che gli era stato dimostrato che i danni li aveva combinati la manutenzione della sua fabbrica. Gli schemi elettrici dicevano una cosa, il cablaggio un'altra.

Idem per i PLC di sicurezza (Piltz lo conosco bene; nel 1986 sono anche stato 5 giorni loro ospite nella fabbrica di Stoccarda). Se modifichi i blocchi certificati sono cavoli tuoi....

Modificato: 14 gennaio 2007 da Livio Orsini

[Piero Azzoni]

e' successo qualcosa a questa discussione

io avevo fatto un intervento che e' andato perso, ma mi pare anche di avere letto qualcosa di altro che non c'e' piu' ??

se c'e' un momento di instabilita' nel motore vale la pena di avvertire

devo anche fare il login a tutti gli accessi; sono l'unico ?

[effebi]

QUOTE< "Please allow me to introduce myself, I am Savino ">UNQUOTE

Sorry for the mistake, please accept my apologies.

Pe quanto riguarda gli array "sfondati" intendo dire proprio che l'indirizzo puntato E' VALIDO , ma appartiene ad un'area di memoria nella peggiore delle ipotesi allocata a qualcosa d'altro. Il registro interessato non sarebbe IP in questo caso ma il data, che so, DX, ad esempio. Se poi si va addirittura a sforare nell'area codice, nel caso questa non sia fisicamente separata su un dispositivo non riscrivibile (ROM, EPROM, etc) , ancora peggio. Si hanno comportamenti imprevedibili ed instabili.

Il sistema operativo puo' essere troppo semplice per aiutarci, o addirittura non esserci.

Comunque non voglio insistere, era solo un esempio un po' troppo complicato, mea culpa, non voglio andare OT.

Per tornare al topic, invece, l'opinione che mi sto facendo e' che l'industria del software, data la sua giovane eta' ripetto che so, all'elettotecnica, all'elettronica o alla termotecnica non e' ancora del tutto matura. Essa e' ancora modellata sullo stampo dei primi entusiasti che con molta fatica ed ingegno una trentina d'anni fa l'hanno fatta nascere. Tant'e' che molti di questi tuttora sono in attivita', per fortuna. Questo mondo di maghi, stregoni e soprattutto apprendisti stregoni (non offendetevi, mi ci metto anch'io per primo ) che ora va per la maggiore e' pero destinato a ridimensionarsi molto quando l'industria del software avra' raggiunto una certa maturita', come le altre. Non sono d'accordo con chi dice che le regole non sono applicabili al software perche' questo e' un prodotto intrinsecamente DIVERSO dagli altri. Per me e' un prodotto dell'ingegno e della tecnica, esattamente come un circuito elettronico od un impianto elettico o del gas e come tale va trattato. Ci vogliono delle regole, anche se questo comporta la "carta" che come si sa e' antipatica ai tecnici "puri". So che questo e' difficile da accettare , spece per noi italici, che siamo abituati a lavorare in modo "creativo", ma credo sia inevitabile ed alla lunga vantaggioso. Chi vivra' vedra'.

Ciao a tutti, buona domenica

effebi

[Piero Azzoni]

tutte menate, non e' necessario fare errori cosi' sofisticati, basta sbagliare !

basta non considerare una qualsiasi situazione e fare un errore

se il software non e' certificato e' un errore vulgaris, se il software e' certificato e' un errore comunque, alla faccia della certicazione che dice che errori non ce ne sono

la certificazione e' e continua ad essere un volgare pezzo di carta, che piu' il tempo passa e piu' e' avulso dalla realta'

ricordo che alla fine degli anni ottanta feci per una ditta la specifica di un sistema di qualita'

due annotazioni a margine

prima: notate come ci sia stato scritto "sistema di qualita'" e non "sistema di controllo della qualita'

seconda: chi mi conosce non mi prenda per il cu*o per questa esperienza del passato

allora ci si credeva ancora, si pensava che la qualita' possa essere descritta e analizzata come una cosa reale

poi negli anni novanta si temeva che il controllo qualita' divenisse nel futuro una triste necessita'

il millenio e' cambiato, ora ci si rende conto che ci sono solo due modi di "vedere" la qualita':

- o la si persegue

- o la si controlla

fortunatamente, anche se qualcuno dice purtroppo, i due modi sono antitetici tra loro

o mi metto in testa che "devo lavorare bene", cioe' devo FARLO !

o mi invento metodiche per "dimostrare che le procedure siano state tali per cui cio' che e' successo, per oggettivamente sbagliato che sia, ha una onesta giustificazione, cioe' e' accettabile"

lo stesso fallimento della 46.90 ne e' una prova

deficenti con la certicazione della camenra di commercio in tasca che chiedono aiuto, magari in nero a elettricisti non riconosciuti che la certificazione non possono avere

caro effebi, mi sembri bravo nella analisi di dettaglio quanto distratto nella visione globale dei problemi

il tuo esempio stesso ne e' una prova, l'apparente sovraposizione di diversi array e' una tecnica che a volte si usa per particolari situazioni, non e' un errore (ma questa e' un'altra storia, nulla c'entra con la discussione ...

[oiuytr]

IMHO anche tu hai le idee confuse, cioe' confondi la certificazione con la dichiarazione di conformita' rilasciata dagli installatori dopo aver eseguito determinati lavori. Tale "carta" e' la dichiarazione dell'installatore di avere eseguito il lavoro rispettando la regola dell'arte. Oltre il fiume di parole che sono gia' state scritte su PLCforum sull'argomento (se usi la funzione cerca trovi decine di discussioni), la vedo difficile applicarla al software.

[batta]

E non dimentichiamo che la dichiarazione di conformità garantisce che sono stati usati conduttori di sezione e isolamento adeguati, protezioni altrettanto adeguate, e via di questo passo. Nulla garantisce riguardo la corretta realizzazione dei cablaggi. Si può fare un impianto perfettamente a norma, ma non funzionante.

Nel caso di un software, cosa si dovrebbe certificare? Che le bobine non sono sovraccaricate? Che gli AND e gli OR sono di sezione ed isolamento corretti? Oppure dovremmo costringere tutti a programmare seguendo un unico metodo, deciso magari da chi di automazione industriale ne capisce ben poco, e introducendo così solo maggiori difficoltà di sviluppo, che avrebbero come conseguenza diretta un aumento di probabilità che il software contenga errori? Onestamente non capisco cosa si dovrebbe certificare.

Per Livio:

Nel plc di sicurezza da me utilizzato i blocchi di cui parlo sono blocchi software protetti, tipo le FC Siemens (spero solo siano protetti meglio ). Decidi quali utilizzare e li carichi nella memoria del plc insieme agli altri blocchi di programma.

Non è "Firmware", ma da un punto di vista pratico non cambia nulla.

[Piero Azzoni]

..... confondi la certificazione con la dichiarazione di conformita' rilasciata dagli installatori .....

non continuiamo a fare i perfetti sulla terminologia visto che tanti chiamano [erronamente, lo ammetto] certificazione la dichiarazione di ... comunque ci si capisce

E non dimentichiamo che la dichiarazione di conformità garantisce che sono stati usati conduttori di sezione e isolamento adeguati, protezioni altrettanto adeguate, e .....

e' la lettura canonica, potrei anche dire:

E non dimentichiamo che la dichiarazione di conformità dichiara con un documento scritto che sono stati usati conduttori di sezione e isolamento adeguati, protezioni altrettanto adeguate, e .....

sembra una illazione ma il significato non e' proprio lo stesso

[batta]

Piero,

giusta precisazione, alla luce della quale si capisce ancora di più quanto sarebbe assurda una certificazione del software.

[Livio Orsini]

Nel plc di sicurezza da me utilizzato i blocchi di cui parlo sono blocchi software protetti, tipo le FC Siemens (spero solo siano protetti meglio ). Decidi quali utilizzare e li carichi nella memoria del plc insieme agli altri blocchi di programma.

Non è "Firmware", ma da un punto di vista pratico non cambia nulla.

batta oramai ci conosciamo, quindi sai che se preciso non è per polemica ma per amor di verità e chiarezza.

Ora tu puoi considerare i blocchi protetti software e non firmware. Al di là del fatto che, come tu stesso ammetti, all'atto pratico nulla cambia, a mio avviso i blocchi protetti, che siano Siemens, o Piltz, o di altri rientrano nella casistica del firmware. E' software non modificabile dall'utente. Che poi l'utente capace possa anche modificarlo avvalendosi di artifizi o "grimandelli" è un altro discorso.

Al limite potrebbero avere solo una protezione facilmente superabile, anzi basterebbe l'avviso: "Questo è un blocco certificato. Una qaulsiasi modifica, anche della sola data di compilazione, fa decadere la certificazione". Visto che ad ogni compilazione la data viene aggiornata in automatico....

il millenio e' cambiato, ora ci si rende conto che ci sono solo due modi di "vedere" la qualita':

- o la si persegue

- o la si controlla

fortunatamente, anche se qualcuno dice purtroppo, i due modi sono antitetici tra loro

Questo concetto era ben chiaro anche nello scorso millennio. Chi della qualità ne ha fatto il pilastro fondamentale, come l'industria automobilistica giapponese, applica questo concetto da decenni.

Io ho un'autovettura Toyota, garantita per 5 anni o 150.000km (se rispeto la scheda di manutenzione). Quando l'ho acquistata 3 anni fa tutte le altre case garantivano il loro prodotto per 2 anni (secondo la legge) con estensione a 3 anni (pagando un extra o come bonus).

Perchè Toyota può permettersi una garanzia più estesa? Perchè è sicura della qaulità del suo prodotto. Perchè ha questa sicurezza? Perchè ha un ottimo controllo di qaulità? Forse, ma non basta. Alla base sta sicuramente un livello qualitativo superiore, livello raggiunto perseguendo la qualità passo dopo passo. Analizzando i guasti, ricercandone le ragioni, emendando i problemi ed emendando le procedure di controllo che non li avavano prevenuti.

E' possibile fare questo con il software? Assolutamente si! Anzi è l'unico modo per avere del software di qualità.

In questo modo si eliminano tutti i bachi? No. Però si riducono di molto e si ha l'assoluta certezza che non saranno ripetuti.

Centra qulache cosa con un'eventuale certtificazione? Assolutamente no!

La certificazione è solo un pezzo di carta che vale meno dell'inchiostro usato per scriverlo. Solo la procedura corretta è garanzia della qualità

... l'opinione che mi sto facendo e' che l'industria del software, data la sua giovane eta' ripetto che so, all'elettotecnica, all'elettronica o alla termotecnica non e' ancora del tutto matura. Essa e' ancora modellata sullo stampo dei primi entusiasti che con molta fatica ed ingegno una trentina d'anni fa l'hanno fatta nascere....

No Effebi. La scienza dell'informatica e l'industria del software sono molto più antiche e mature. Risalgono ad almeno la seconda metà degli anni '40. In genere si pone la data di nascita con la scoperta di Von Neuman che per programmare un elaboratore bisogna farlo fare all'elaboratore stesso con un programma adatto alla bisogna.

Diciamo che l'informatica, e la programmazione, di massa nasce con il PC, quindi un'anzianità di circa 30 anni è una stima corretta.

Ma gli apprendisti stregoni, i cosidetti Guru, sono confinati in questo ambito. Chi fa dell'informatica seria lo fa in modo scentifico e deterministico. L'informatica è una scienza esatta, però come tutte le attività umane è soggetta ad errori ....umani.

Anche in ambito industriale, como ho scritto in precedenza, si potrebbe operare con qualità molto più alta. Con i costi che salgono esponenzialmente.

E' vero che tra la metodologia da industria aereospaziale ,e la metodologia del "quadrista" che randella istruzioni mentre mette in servizio la macchina, esiste una giusta via di mezzo: una corretta progettazione del software a tavolino, ed una successiva messa a punto sulla macchina.

Ma questo ha qualche cosa a che vedere con certificati e certificazioni? Assolutamente no.

Parafrasando Piero, la qualità la si persegue, certificarla non aggiunge valore alcuno.

Modificato: 14 gennaio 2007 da Livio Orsini

[Savino]

Ciao effebi,

please accept my apologies

Accetto volentieri

Ci vogliono delle regole, anche se questo comporta la "carta" che come si sa e' antipatica ai tecnici "puri".

Dunque, le regole ci sono gia'...

Ma e' possibile che per l'industria del software siamo ancora nel far west?

No, non siamo nel far west, anzi...

Oggigiorno i SW vengono sottomessi a proccessi di "SW Validation" per parte degli adetti al "Sistemi di Qualita'", per quelle emprese che seguono e si adeguano strittamente alle istruzioni regolative delle normative interessate... ma "certamente come funzionalita'".

Ad esempio, se tu pretendi di vendere delle applicazioni SW (PLC, PC, HMI, etc) nella industria farmaceutica, medica... dovresti adeguarti alle "regulative GAMP" ( Good Automated Manufacturing Practice ). Atrimenti, non ti prenderano in considerazione.

Ma ripeto, qui si parla di certificazione a livello " funzionalita' del SW " e non stesura, etc.

Modificato: 14 gennaio 2007 da Savino

[Piero Azzoni]

da wikipedia:

Il termine software ha origine durante la seconda guerra mondiale. I tecnici dell'esercito inglese erano impegnati nella decrittazione dei codici tedeschi di Enigma, di cui già conoscevano la meccanica interna (detta hardware, roba dura, nel senso di ferraglia) grazie ai servizi segreti polacchi. La prima versione di Enigma sfruttava tre rotori per mescolare le lettere.

Dopo il 1941, ad Enigma venne aggiunto un rotore, e il team di criptanalisti inglesi, capitanati da Alan Turing, si dovette interessare non più alla sua struttura fisica, ma alle posizioni in cui venivano utilizzati i rotori della nuova Enigma. Dato che queste istruzioni erano scritte su pagine solubili nell'acqua per poter essere più facilmente distrutte, e per contrasto con hardware, furono chiamate software.

Il senso moderno del termine deriva dalle istruzioni date ai computer, ed è stata utilizzata per la prima volta nel 1957 da John W. Tukey, noto statistico statunitense. Dal 1950 l'analogia tra l'hardware ed il corpo umano e quella tra il software e la mente umana si è fatta molto forte, dal momento che Turing ha sostenuto che il progresso tecnologico sarebbe riuscito a creare entro il 2000 delle macchine intelligenti, in grado di pensare autonomamente per la risoluzione dei problemi.

non vorrei entrare invece nel merito della validazione, quello che fda chiede somiglia molto di piu' ad un collaudo che ad un certificato, come tale puo' confondere le idee nel merito di questa discussione anziche chiarirle

per quanto riguarda la discussione su software o firmware la distinione e' molto semplice

se e' contenuto insieme ai codici del sistema operativo e viene caricato nella cpu prima dell'applicativo, contestualmente al sistema operativo stesso, e' firmware

se e' contenuto insieme ai codici dell'applicativo stesso, e contestualmente a questo, dopo il sistema operativo ed il firmware, indipendentemente se lo stesso e' protetto o meno, e' software

gli fb di siemens sono software, anche quelli protetti, se sicuramente non utilizzati possono essere rimossi

le funzioni, booleiane, avanzate o matematiche di qualsiasi plc sono comunque a disposizione entro il plc stessi anche se l'applicativo scritto in quel plc non le usa mai, non possono essere eliminate, sono firmware

[Livio Orsini]

per quanto riguarda la discussione su software o firmware la distinione e' molto semplice

No Piero, la distinzione non è ne facile ne semplice. Molte volte si è tentato di dare una definizione univoca di firmware. Inizialmente si ipotizzava come firmware la parte di codice "cablata" sul silicio. Poi con l'avvento dei dispositivi OTP si è esteso il termine anche al codice scritto su questi dispositivi. La motivazione era che una volta programmato il dispositivo non era più modificabile. Poi è stato esteso anche alla parte di codice dei blocchi o settorie di memeorie EEPROM non riprogrammabili dall'utente. In tempi successivi, con l'avvento delle memorie ottiche non riscrivibili (CD) si è creata la distinzione tra firmware resisdente (quello caricato nel dispositivo e residente su silicio) e quello non residente ma disponibile (quello su supporto ottico).

Da alcuni anni l'accezzione più diffusa per firmware è quella di software non liberamente modificabile dall'utente. Questo software "diventa" firmware dal momento che viene caricato sul silicio (EEPROM, FLASH).

Comunque la distinzione è puramente accademica e, da qualsiasi punto la si voglia osservare non muta il concetto che sta alla base dei PLC, e di qaulsiasi dispositivo programmabile, certificato come dispositivo di sicurezza. Che i blocchi di sicurezza siano residenti sul silicio assieme al sistema operativo, oppure vengano caricati dall'utente secondo bisogna, il concetto non cambia: il dispositivo è certificato se, e solo se, fa uso di quelle sequenze certificate. Altrimenti è un qualsiasi dispositivo programmabile e quindi non risponde alle norme per le sicurezze.

Personalmente considero come firmware tutta la parte di codice che non è stata sviluppata dall'utilizzatore ma è fornita dal costruttore, o da terze parti, e deve essere usata "così come è stata scritta". Se, ad esempio, uso un M7 con RTOS, per me RTOS, una volta caricato, fa parte del firmware.

Comunque tutto questo non ha molto a che vedere con l'argomento iniziale della discussione. Il solo punto di contatto è la certificazione delle funzioni di sicurezza.

Questo è uno dei pochi casi in cui si può e si deve, a mio giudizio, certificare con timbri e firme, una funzione software.

Si può perchè si tratta di funzioni precisamente delimitate, con compiti precisi e limitati e sicuramente definiti. Soprattutto sono abbastanza facilmente verificabili al 100%

Si deve perchè realizzano funzioni concernenti la sicurezza degli impianti e delle persone. In questo caso è giusto che ci sia un Ente tecnico che garantisca l'affidabilità di queste sicurezze.