Dichiarazione Conformità Software Plc

[andrea73]

Buongiorno a tutti, mi è stata chiesta da un mio cliente (è la prima volta che mi capita) la dichiarazione di conformità del software PLC che ho realizzato qualche anno fa per implementare l'automazione di una cava. La parte sw comprende ovviamente il programma a bordo del PLC (S7-300) e l'applicazione HMI a bordo del pannello di interfaccia. In cosa consiste questa dichiarazione? Qualcuno ne ha già rilasciate? Esistono dei modelli scaricabili in rete?

Grazie a tutti

Ciao

Andrea

[Nino1001]

Non ho il coraggio si scrivere che cavolta è mai questa perchè tempo che possa essere .....vera...

Ma chi mette in giro queste voci! ( versus cliente beninteso!).

Conforme a che cosa? C'è un linguaggio ed una simbologia che rendono un lavoro "internazionale"... boh...certo che se il lavoro è stato fatto ed il cliente la vuole o non sborsa una lira

[del_user_56966]

La parte sw comprende ovviamente il programma a bordo del PLC (S7-300) e l'applicazione HMI a bordo del pannello di interfaccia. In cosa consiste questa dichiarazione? Qualcuno ne ha già rilasciate? Esistono dei modelli scaricabili in rete?

Il massimo che tu cliente può pretendere è che il software rispetti una data specifica, quindi che sia conforme all'ordine, sempre

che questa specifica esista!, poi può pretendere che il linguaggio di programmazione sia conforme a uno dei 5 linguaggi

che sono dichiarati come standard nelle normative internazionali quindi alla IEC1131-3.

Oltre questo, che si limita a un autocertificazione dello sviluppatore/Software House non penso tu possa (non dico voglia..) dichiarare altro,

se vedi nessun programma software di nessun tipo di apparato è garantito nelle sue funzioni in quanto il programma gira su un sistema operativo che a sua volta

lavora su un hardware e su delle memorie... e quindi non essendo garantito nulla

dal produttore primario, il sistema su cui il tuo programma gira.. cosa pensi di poter garantire tu!

Sarebbe come se io produttore del "volante" ti garantissi che non sbandi in auto, che dici dipende anche dal produttore delle gomme oppure credi di no?...

[Livio Orsini]

Che io sappia non esiste legge o norma che prescrivano questa dichiarazione.

Se esite una specifica, che deve essere parte integrante dell'ordine, è implicito che anche il software, come tutta la fornitura, sia conforme alla specifica.

[MABE]

Ciao

Il tuo cliente fa riferimento alla norma CEI EN 62061 che entrerà in vigore a fine anno.

Il software applicativo deve essere conforme alla norma CEI EN 61508-3

[Livio Orsini]

CEI EN 61508-3, “Sicurezza funzionale dei sistemi elettrici, elettronici ed elettronici programmabili per applicazioni di sicurezza. Parte 3: Requisisti del software”

Mi sembra che riguardi applicazioni particolari: la sicurezza.

[del_user_56966]

CEI EN 61508-3, “Sicurezza funzionale dei sistemi elettrici, elettronici ed elettronici programmabili per applicazioni di sicurezza. Parte 3: Requisisti del software

Non so di cosa tratta di preciso la norma, ma penso che comunque non possa valicare il limite della rispondenza del software a determinate funzioni

da svolgere, in ogni caso il software gira su un dispositivo quindi analizzare solo il software non serve a nulla se poi il problema viene creato da dispositivo stesso.

Quindi tale norma è ininfluente se il dispositivo non è comunque certificato allo stesso livello del software.

Questo in ogni caso non invalida l'uso di dispositivi di sicurezza, in quanto al software non è permesso per natura di essere considerato come elemento finale

di sicurezza la dove vi sia rischio di danni a cose e persone.

[Savino]

La dechiarazione di conformita' fornita per l'apparecchiatura elettrica contenente il PLC, sarebbe piu' che sufficente come documentazione a questo fine. Il programma PLC forma parte del HW stesso, e' una estensione delle sue funzionalita' elettriche/elettroniche, di supervisione,controllo, comando, sicurezze.. etc.

Piuttosto di dichiarazione di conformita' del SW, bisognerebbe parlare dell'assunzione per le responsabilità civili per la globale funzionalita' del sistema di controllo sull'impianto e persone che ci lavorano con esso.

Forse sarebbe qui il nocciolo della quetione da superare.

Queste sono cose che bisogna sempre chiarire all'inizio delle trattative di business, poiche' le cose all'ora dei pagamenti sempre si complicano.

Livio

Se esite una specifica, che deve essere parte integrante dell'ordine, è implicito che anche il software, come tutta la fornitura, sia conforme alla specifica

Questo e' corretto. In certe occassioni, alcuni SW devono seguire una determinata specifica di stessura, per conservare un determinato standard costruttivo in linea con le regolazioni voluta dalla impresa.

Modificato: 22 maggio 2009 da Savino

[MABE]

Ciao

Per ogni macchina od impianto (qui addirittura si parla di gestione di automazione in una cava....), deve essere eseguita una valutazione di sicurezza, in particolare,da fine 2009, sui sistemi di comando relativi alla sicurezza deve essere eseguita una progettazione in conformità alla norma UNI EN ISO 13849-1 e/o CEI EN 62061.

Io ritengo che il cliente stia chiedendo ad Andrea 73 la dichiarazione di conformità a tale normativa.

[andrea73]

Intanto grazie a tutti per la velocità e precisione nelle risposte: siete stati molto utili e adesso ho un po' più chiara la situazione...

Ora ho bisogno un consiglio: navigando nel forum ho trovato dei post inerenti il calcolo dei vari PL, SIL, ecc. e addirittura sono venuto a conoscenza dell'esistenza di software (PAScal della PILZ) che automatizzano il calcolo di tali fattori. Ho visto un post dello stesso MABE che parlava di una semplice macchina di collaudo con comando bimanuale, ma il mio dilemma è: a fine 2009 diverrà obbligatorio certificare tutti gli impianti secondo le norme UNI EN ISO 13849-1 e/o CEI EN 62061? Questo varrà anche per impianti già realizzati (come nel mio caso della cava, la cui messa in servizio risale ormai all'estate del 2006)? E comunque, parlando dell'automazione di una intera cava, anche utilizzando ad esempio PAScal, non diventa un lavoro immane (centinaia di sensori e altrettanti attuatori)?

Inoltre, leggendo l'. di PAScal, ho visto che tutto ciò che quest'applicazione riesce a fare non riguarda comunque ancora la certificazione del software del PLC (che aggiungo essere un "normale" S7-300, non classe F), come richiesto dalla CEI EN 61508-3: esiste un modello scaricabile per compilare questa certificazione?

Scusate la raffica di domande, ma vista l'ottima preparazione di gran parte di voi in questo campo ho pensato di approfittare del momento "caldo" di questo post per avere delle riposte.

Grazie di nuovo.

Ciao

Andrea

[MABE]

ciao

vorrei aggiungere ancora una cosa

La normativa EN ISO 13849-1 impone di calcolare il PL del sistema di comando inerente alla sicurezza e di confrontarlo con il livello di prestazione richiesto PLr.

La norma non dice che si deve usare un PLC di sicurezza

Si può usare un PLC standard a cui però devi fare assumere un valore del suo MTTFd = 10 anni, se con questo valore il PL del sistema è inferiore o uguale al PLr richiesto il sistema è progettato correttamente.

Solitamente con sistemi che richiedono un PLr pari ad a oppure a b, si utilizzano PLC non di sicurezza.

[andrea73]

[at] MABE: grazie per la precisazione, ma il PLr da chi deve essere stabilito? E' il cliente che lo decide o ci sono delle "norme di prodotto" (passami il termine) per ogni tipologia di macchina/impianto?

Hai qualche consiglio sul resto delle domande del mio penultimo messaggio?

Andrea

[MABE]

ciao

In poche righe spiegare la normativa 13849 è dura..., ma ci provo

1- individuare i sistemi di comando relativi alla sicurezza presenti nell'impianto (SRP)

2-individuare le funzioni di sicurezza assolte da un sistema SRP e le relative peculiarità (nella norma le trovi)

3- determinare il PLr (è un grafico presente nella norma)

4-progettazione tecnologica del sistema SRP

5- determinazione del PL richiesto

6- se PL<= PLr il sistema SRP è progettato correttamente, altrimenti devi ritornare al punto 4 e rivedere la progettazione tecnologica del sistema

7- sicurezza del software (era la tua domanda iniziale)

8- validazione

Il processo di validazione del sistema SRP va fatto in conformità alla 13849-2 e deve essere condotta da persona indipendente da quella preposta alla progettazione delle parti alla progettazione delle parti relative alla sicurezza.

Il software che tu citi ti aiuterà probabilmente a svolgere i calcoli matematici previsti nella norma. Ma progettare un SRP non è una semplice applicazione di una formula matematica

La norma sarà retroattiva? secondo me no.

Ovviamente quando però un impianto verrà modificato, automaticamente dovrà essere reso conforme anche alla 13849.

[Livio Orsini]

1- individuare i sistemi di comando relativi alla sicurezza presenti nell'impianto (SRP)

2-individuare le funzioni di sicurezza assolte da un sistema SRP e le relative peculiarità (nella norma le trovi)

e e solo

Attenzione sono queste e solo queste le funzioni che devono essere certificate. Ma questo da sempre.

...assumere un valore del suo MTTFd = 10 anni,

...

Non credo sia sufficiente.

Son trascorsi quasi dieci anni da quando facevo parte, come membro corrispondente, del comitato IEC per la determinazione dei criteri certificazione del software di sicurezza. In questi anni presumo che i criteri, se modificati, sian diventati più restrittivi e non più permissivi.

Un dispositivo di sicurezza certificato deve garantire che, anche in caso di guasto, metta l'apparecchaitura in sicurezza oppure, tramite ridondanze, permetta comunque l'intervento delle sicurezze. (semplificano e banalizzando i concetti)

[del_user_56966]

Un dispositivo di sicurezza certificato deve garantire che, anche in caso di guasto, metta l'apparecchaitura in sicurezza oppure, tramite ridondanze, permetta comunque l'intervento delle sicurezze. (semplificano e banalizzando i concetti)

Quoto pienamente questo concetto!...

[Adelino Rossi]

questo è un tema talmente variegato, dalle mille sfaccettature e realtà e vissuto in modo diverso da moltissime

persone e aziende, grandi e piccole, costruttori e utenti, che meriterebbe alla grande un convegno.

[del_user_56966]

che meriterebbe alla grande un convegno

Sono daccordo, ma conoscendo bene il mondo dei programmatori ci si accorgerebbe che

non li metteresti mai in linea tra loro...quindi secondo la mia modesta opinione le norme sul software

saranno applicabili quando il software sarà certificabile come esente da Bug... ovvero mai...

[Adelino Rossi]

alen

sono d'accordo con te sulla difficoltà del dialogo ma a mio parere una grande quota di mercato sarà sempre più legata alla trasparenza

e alla certificazione, quelli del software proprietario e segreto, (a mio parere) ad ogni costo sono destinati a ridursi sempre di più o rimanere relegati in un mercato di nicchia.

non è il programmatore che fa il mercato,

almeno non sempre, ma una combinazione di situazioni di mercato, leggi, ispezioni obbligatorie e quant'altro.

anche nel campo legale, leggevo oggi che ci si illude che le leggi siano permissive in realtà la filosofia di aver fatto leggi in cui

il titolare di azienda ha l'obbligo lui stesso di effettuare o far effettuare i controlli e le certificazioni di controllo, pone su quest'ultimo le responsabilità di qualsiasi tipo.

il fatto e che molti non lo sanno.

Modificato: 22 maggio 2009 da Adelino Rossi

[del_user_56966]

il titolare di azienda ha l'obbligo lui stesso di effettuare o far effettuare i controlli e le certificazioni di controllo, pone su quest'ultimo le responsabilità di qualsiasi tipo.

il fatto e che molti non lo sanno.

nella realtà quando si parla di software se vai a fondo vedrai che nessuno e dico nessuno garantisce proprio nulla!

e in ogni caso prima di aver risolto la questione del copyright sul codice

dire che la maggior parte dei programmi saranno aperti per come le conosco io non la vedo nell'interesse delle aziende..!

[Savino]

Buongiorno a tutti, mi è stata chiesta da un mio cliente (è la prima volta che mi capita) la dichiarazione di conformità del software PLC che ho realizzato qualche anno fa per implementare l'automazione di una cava. La parte sw comprende ovviamente il programma a bordo del PLC (S7-300) e l'applicazione HMI a bordo del pannello di interfaccia. In cosa consiste questa dichiarazione?

Prima di comminciare, dovresti chiedere al tuo cliente cosa esattamente vuole.

Perche se un determinato sistema - impianto ( HW-SW) dovrebbe essere ubbediente-servile (compliant) ad un determinato insieme di regolamenti e/o standards di qualita' costruttivi vari, allora basta seguire le adeguate norme, capitolati, sistemi di convalidazione, vigenti in merito per il suo corretto sviluppo.

Quindi la richiesta della dichiarazione di conformita' del SW mira alla convalidazione-certificazione di che questo sistema SW PLC e HMI e' servile con questi regolamenti e standarizzazioni per quanto riguarda alla completa funzionalita', procedure operative e di convalidazione.

Questo non vuoldire che dovresti adottare soltanto dei specifici sistemi HW e SW che vengono venduti come standad e servili a questi processi, basta che tu ti adegui ai modelli gia' esistenti per i requisiti richiesti.

Modificato: 22 maggio 2009 da Savino

[Adelino Rossi]

nella realtà quando si parla di software se vai a fondo vedrai che nessuno e dico nessuno garantisce proprio nulla!

su questo ti quoto al 100%

in ogni caso prima di aver risolto la questione del copyright sul codice

la questione copyright sul codice non è l'unico aspetto ma è uno degli aspetti tra cliente e fornitore.

dire che la maggior parte dei programmi saranno aperti per come le conosco io non la vedo nell'interesse delle aziende..!

non la vedi nell'interesse delle aziende perché, giustamente, la vedi solo come tua fonte di reddito.

ci sono centinaia di applicazioni di sicurezza certificata perché verificata e verificabile da ISPSEL. ASL ARPA, VVFF e altri enti, alcuni con potere di fermo impianto.

che se durante i collaudi di primo impianto o i controlli periodici non trovano chiara e soddisfacente risposta alla loro verifica documentale e di impianto

pongono il veto nel peggiore dei casi sull'avviamento dell'impianto.

ad un ispettore di un ente di controllo non puoi dire che la logica di un controllo a rischi ambientale è racchiusa in una scatola nera di un quadrato che rappresenta

un blocco funzione, (ad esempio), le conseguenze le puoi immaginare.

altro esempio generico

misura a microprocessore di grandi quantità di gas ad uso fiscale, acquisto per uso proprio o per vendita a terzi, sia per fatturazione che per le emissioni di co2,

protocollo di kyoto a cui l'talia ha aderito. in tutti i casi di verifica, normalmente una volta all'anno devi dimostrare agli ispettori che i sistemi di misura comunque siano tarati e certificati.

mi dispiace interrompere il discorso ma altri impegni mi chiamano.

[del_user_56966]

ad un ispettore di un ente di controllo non puoi dire che la logica di un controllo a rischi ambientale è racchiusa in una scatola nera di un quadrato che rappresenta

un blocco funzione, (ad esempio), le conseguenze le puoi immaginare.

Dipende, se la scatola nera racchiude in se, degli algoritmi di comune utilizzo non ha neppure senso, nel caso

comune che la scatola contenga Know Now di una specifica azienda e quindi non funzioni pubbliche e di uso comune

l'azienda è tenuta a certificare il funzionamento e eseguire i collaudi del caso in presenza del cliente, ma nessuna norma

può bypassare il diritto d'autore, al massimo il cliente può rinunciare all'acquisto del prodotto, e qui entra in gioco solo quanto

il prodotto è veramente interessante a livello di mercato e appunto per il cliente finale, cosi è in realtà!..

dalle mie parti si dice "chi a i denari vince sempre" ma nel caso del Know Now i denari sono il software per applicazioni specifiche..

infatti è vero che il tuo programma può essere richiesto aperto ma visto che dipende sempre da un Kernel PLC prova per esempio

a chiedere i sorgenti alla Siemens per vedere se le routin sono a norma e vedi cosa ti dice...

[Adelino Rossi]

vedo che potremmo girare all'infinito sull'argomento.

il software e il mondo del software ha aspetti infiniti, tu fai bene a difendere la tua realtà perchè comunque sia e con i money che si campa, alcuni bene altri meno bene.

in quanto alla rinuncia all'acquisto di un prodotto, questo e vero nella misura in cui tu fai onestamente capire al cliente che quelle sezioni software

non sono presentabili all'ispezione di enti esterni per motivi di sicurezza, ambientali o fiscali, altrimenti il cliente lo scopre a sue spese con gli ispettori in casa.

sapessi quante scatolette esterne omologate e/o certificate bisogna poi aggiungere in seguito al di fuori dell'automazione, tante, troppe.

In quanto ai plc stai volutamente estremizzando, in quanto acquisti un prodotto noto, collaudato e con decine di certificazioni, comprese quelle necessarie per l'applicazione in oggetto,

dopodichè l'installatore lo installa con un software che se richiesto, certificato per usi di sicurezza o fiscali o per controlli ambientali ha il suo flow chart, le formule, e le logiche necessarie.

qual'ora l'apparecchiatura sia un monoblocco HW e SW certificato, questa ha un proprio documento di riferimento di un ente certificatore presso il quale deve essere depositata tutta

la documentazione di dettaglio del caso.

pero ripeto il mondo del software è fatto di milioni di applicazioni, le più disparate in tutti i campi.

potremmo scrivere all'infinito ognuno con idee diverse e attualmente tutti avrebbero ragione.

[del_user_56966]

potremmo scrivere all'infinito ognuno con idee diverse e attualmente tutti avrebbero ragione.

Questo è vero, ma a me interessa più l'aspetto legale e normativo collegato ad esso che non l'aspetto burocratico della cosa,

e per quanto ne so, l'unico motivo per poter ispezionare i sorgenti di prodotto software riservato sta nel contesto che si sospetti che

l'azienda racchiuda in questi esplicite contravvenzioni alla legge, al fisco o di sicurezza nazionale e in caso questo poi non sia riscontrato

i sorgenti devono essere resi integralmente all'azienda senza poterne trattenete alcuna copia, il solo disassemblare un codice senza un

reale motivo è un reato che a secondo del casi e della nazione interessata è punito severamente...

e la sicurezza di una macchina per esempio non è un motivo ritenuto sufficiente...

[Savino]

alen

Dipende, se la scatola nera racchiude in se, degli algoritmi di comune utilizzo non ha neppure senso, nel caso

comune che la scatola contenga Know Now di una specifica azienda e quindi non funzioni pubbliche e di uso comune

l'azienda è tenuta a certificare il funzionamento e eseguire i collaudi del caso in presenza del cliente, ma nessuna norma

può bypassare il diritto d'autore

Io su questo sono d'accordo. Infatti, sono un sostenitore del copyright.

Comunque, penso che per il caso di andrea73, lui non dovrebbe avere problemi di questo genere..

Per verificare se un sistema e' servile ad un determinato standard, basta convalidare il suo corretto funzionamento, che non vuoldire dire come e' stato fatto...

In ogni caso, gli interventi di Adelino sono moderatamente accettabili.