Su indicazioni degli amministratori ho aperto qui qesta discussione relativa a software e sistemi di controllo utilizzati nelle centrali nucleari.
In vari forum si affrontano vari argomenti riguardo alle nuove centrali, la sicurezza, il fonzionamento ecc.. ma in nesun forum ho potuto avere informazioni relative ai sistemi di controllo realmente/praticamente impiegati.
Sperando che qualche addetto ai lavori partecipi alla discussione.

In effetti all'universita' non si studia particolarmente questo aspetto.

So che l'elettronica di controllo, sistemi "embedded", si basano sugli FPGA,, che sono schede con microcontrollori programmabili. Tali sistemi hanno software specifico che non richiede i classici sistemi operativi (windows o UNIX), scritti per usare le solite architetture (x86, Alpha, ecc..).
Hanno software scritto per lavorare in modo efficiente e fare le operazioni specifiche e previste, con eventuali deviazioni.
In tal modo non sono soggette a errori tipi delle piattaforme con sistemi operativi piu' complessi (e meno implementati), come windows e sistemi UNIX.

E' probabile ci siano macchine con sistemi operativi classici, per operazioni meno funzionali ai fini del controllo dell'impianto.

Il SW in effetti sembra rimanere un mistero anche se si trovano marginalmente tracce di un sistema WINCC di Siemens che, leggendosi i manuali, servirebbe propio a gestire i vari microcontrollori purtroppo si basa su XP o peggio VISTA.
La mia richiesta era esattamente mirata a sapere qualche cosa di specifico riguardo ai sistemi di controllo e relativo SW.
Ho un'esperienza lavorativa più che trentennale su PLC, attuatori, Microcontrollori e loro programmazione dedicati ai sistemi di alimentazione dai GE di emergenza a tutti i vari sistemi inverter e UPS, e mi sono sempre chiesto cosa veniva utilizzato nelle centrali nucleari.

Interessante l'articolo che oggi ha postato Don Peppone su archivionucleare.com, il testo originale completo e' questo:

http://www.articlesbase.com/electronics-...79975.html

Il trend e' certamente quello di portare ad un bus comune che da un punto hardware si chiama Ethernet, con la sua versione industriale denominata senza grande fantasia Industrial Ethernet:

http://en.wikipedia.org/wiki/Industrial_Ethernet

Il layer dati invece ricade certamente sul protocollo IP come trasporto, anche se questa scelta apre un po' di dubbi sulla questione Security (la Network Security e' incidentalmente il campo di cui mi occupo da 20 anni).

Come gia' accennavo su archivionucleare.com, il disegno di questo genere di reti diventa di fondamentale importanza.  Non c'e' miglior sicurezza di avere reti separate da aria!  Seriamente, in gergo militare si chiama "air gap".

Quindi reti fisicamente diverse per ogni tipo di livello di criticita' dei sistemi coinvolti.

Discussione molto affascinante per me, dato che avvicina il mondo a me ben conosciuto a quello della tecnologia nucleare che e' un interesse recentissimo per me.

Cordiali saluti,
Luca Bertagnolio

Riprendo l'argomento già in parte discusso nel thread
http://www.archivionucleare.com/index.ph...a-daiichi/

Domanda:
siamo sicuri che il virus stuxnet che colpisce i sistemi simatic sia stato concepito per creare problemi alle centrali nucleari?

Voglio dire, i sistemi WinCC sono diffusissimi in migliaia di aziende, dalla fabbricazione di biscotti all'automotive, dai mulini per il grano alle macchine per la stampa, ed anche in qualche piccola centrale elettrica tradizionale che ho visto... ma in ambito critico si usano ben altri sistemi, in generale DCS avanzati in RTOS, dedicati ai settori chimici, oil-&-gas e nucleare.

Ora, vista la scarsa diffusione nell settore nucleare e l'esiguità del numero di centrali, mi sembra che il virus che aggredisce i sistemi Siemens vada a colpire decisamente altri settori industriali, piuttosto che il nucleare.

Certamente LIVINGREEN i sistemi WINCC sono utilizzati nei più varicampi e non credo assolutamente che sia stato pensato un virus solo per le centrali nucleari. Il problema è un altro, se nelle centrali vengono utilizzati SW commerciali basati su SO commerciali il rischio diventa serio, un NIMDA o chi per esso potrebbe causare danni.
In ogni modo la mia richiesta si rivolgeva agli addettii al settore per conoscere come realmente vengono gestiti e con cosa i controlli.

Certamente MAGNOX è esattamente quello che penso anch'io.
Avevo già detto che non credevo possibile l'utilizzo di SOeSW commerciali.
La mia richiesta era propio di sapere quale tipo di architettura HW/SW e RTOS vengono realmente utilizzati.
Esistono un discreto numero di RTOS anche di tipo open-source e sarebbe interessante sapere quali sono realmente le scelte dei vari consorzi e costruttori di centrali

Si la domanda è molto interessante.

Ricordo che anche l'hardware può avere bugs, la cui probabilità aumenta con l'aumentare della complessità del sistema, esattamente come per il sw.

Non a caso sui grandi aerei di linea commerciali è stato imposto l'uso di 2 sistemi paralleli di controllo, e sia l'hardware che il software devono essere di progetto e fornitori diversi.

In ogni caso mi sembra poco probabile che l'interfaccia utente di tali software possa totalmente prescindere da software di largo utilizzo, sarebbe un costo enorme riprogettare tutto, però potrebbero aver separato la logica di controllo dall'interfaccia, il che andrebbe ugualmente bene.

Di errori SW è costellata la storia, a volte però si esagera un po.
Qella di Arianne non la sapevo, avevo sentito dire però che per le stesse cause si erano bloccati i calcolatori di bordo (ben 5) del primo shuttle COLUMBIA costringendo il pilota ad un rientro manuale.
Non vorrei che come al solito con un minimo fondo di verità si creino fantasiose leggende un po come quelle che circolano sul nucleare.
SO come Vista hanno già problemi da soli senza che vengano per giunta attccati.
Uno Shuttle è si esploso ma le cause sono purtroppo ben note e accertate da tutte le commissioni, in fondo le cause sono sempre le stesse (economiche)

Fonte : wikipedia, ma lo avevo appreso altrove.

Il primo volo dell'Ariane 5 (Ariane 5 volo 501) svoltosi il 4 giugno 1996 fallì e il razzo si autodistrusse dopo 40 secondi dal lancio per via di un malfunzionamento del software di controllo, creato da uno dei più famosi bug della storia. Un dato a 64 bit in virgola mobile, probabilmente quello della pressione, venne convertito in un intero a 16 bit con segno, questa operazione causò una trap del processore (operazione errata): il numero in virgola mobile era troppo grande per poter essere rappresentato con un intero a 16 bit. Motivi di efficienza avevano spinto i progettisti a disabilitare il controllo software (scritto in Ada) sulle trap, anche se altre conversioni simili nel codice erano corrette. Questo errore scatenò una reazione a catena che causò poi la deviazione distruttiva del razzo a causa delle enormi forze aerodinamiche. Fu necessario quasi un anno e mezzo per capire quale fosse stato il malfunzionamento che aveva portato alla distruzione del razzo.

Però ricordavo male, era una conversione errata tra tipi di dato...

http://www.loccidentale.it/articolo/ahma...2.00100130
Cyber-change
Ahmadinejad deve riconoscere di essere stato battuto da "Stuxnet"

di Jonathan V. Last20 Dicembre 2010
........."Stuxnet ha fatto per la prima volta la sua comparsa lo scorso 17 Giugno, quando una compagnia di sicurezza digitale di Minsk, VirusBlokAda, ne fece la scoperta in uno dei suoi computer destinato ad uno dei suoi clienti iraniani. E' stato immediatamente chiaro che Stuxnet non era un comune malware (N.d.T. per malware si intende qualsiasi programma inteso a danneggiare o mettere fuori uso computer o sistemi per computer).
Infatti Stuxnet non è un virus ma un worm. Si tratta di virus che si appoggiano su programmi già presenti su di un computer. I worm sono programmi in tutto e per tutto, che si nascondono dentro un computer, e che segretamente si propagano in altri computer. Dopo un mese di studio alcuni ingegneri di cyber-sicurezza hanno emesso la sentenza: Stuxnet è stato disegnato per interferire con sistemi industriali costruiti dalla casa tedesca Siemens, con la finalità di mettere fuori uso i controlli di supervisione ed i protocolli di acquisizione dati degli stessi, i c.d. SCADA. Come a dire che, a differenza di molti malware oggi in circolazione (tesi alla mera manipolazione di operazioni virtuali), Stuxnet può invece generare conseguenze nel mondo reale: questo worm è infatti in grado di comandare tanto i lavori di un grande stabilimento industriale, quanto quelli di una centrale energetica, di una diga o di un'industria. Di quale impianto si sia trattato in questo caso, non è dato saperlo.
Quel che sappiamo però, è che Stuxnet ha sin da subito mostrato un profilo di anomalia rispetto ai suoi predecessori. I worm che hanno interferito con SCADA non sono sconosciuti ma eccezionalmente rari. Quale sequenza di codice fisico, Stuxnet è enorme (si stima che pesi all'incirca mezzo megabyte), superando in grandezza, di molti multipli, un medio esemplare di worm in circolazione.
Prendiamo in conto ora il suo raggio d'infezione: Stuxnet è riuscito ad infiltrarsi in almeno 100.000 computer in tutto il mondo, di cui il 60% solo in Iran. Senza contare che la potenza e l'eleganza di Stuxnet lo rendono ancora più intrigante agli addetti ai lavori. Molti sistemi industriali girano su computer che usano Microsoft Windows quale sistema operativo. Gli hacker mettono alla prova costantemente quelle che in gergo vengono chiamate le vulnerabilità del “giorno zero” (zero day vulnerabilities), i punti deboli del codice non identificati dai programmatori-creatori. Su un pezzo di software sofisticato quale è Windows, la scoperta di una sola vulnerabilità del “giorno zero” è estremamente rara. Basterà dire allora che i creatori di Stuxnet ne hanno trovate, e usate, ben quattro. Nessuno negli ambienti della cyber-sicurezza aveva mai visto niente del genere.
Il worm ha ottenuto il suo primo accesso attraverso un drive USB ordinario. Immaginate quando attaccate un flash drive nel vostro computer: il computer incomincia a fare una serie di operazioni in modo automatico; una di queste è quella di far comparire le icone sul vostro schermo, le quali rappresentano i dati sul drive ospite. Attraverso questa procedura di inserimento del drive USB, Stuxnet si inoltra nel computer. Ora, una volta nella macchina, il worm diviene visibile ai protocolli di sicurezza, i quali monitorano costantemente i file alla ricerca di malware o virus. Per non farsi scoprire, Stuxnet installa quel che è chiamato un 'rootkit', ovvero un pezzo di codice che intercetta i monitoraggi di sicurezza e che invia indietro falsi messaggi di sicurezza, a voler indicare che il worm è innocuo.
L'installazione di un 'rootkit' ha bisogno di driver dai quali i sistemi Windows sono abituati a guardarsi bene. Windows infatti richiede che tutti i driver immessi in una macchina che si affida al suo sistema operativo, forniscano una verifica della loro 'sincerità' attraverso la presentazione di una firma digitale sicura. Queste firme digitali sono segretamente custodite. L'aspetto interessante di questa vicenda è che i driver di Stuxnet avevano in dotazione firme digitali per così dire originarie, ovvero provenienti da due compagnie di computer, Realtek Semiconductor e JMichron Technologies. Entrambe le compagnie hanno uffici negli stessi stabilimenti del parco scientifico di Hsinchu, sull'isola di Taiwan. Con frode elettronica o con scasso e furto (non è dato sapere), i creatori di Stuxnet hanno rubato queste firme digitali, in modo abbastanza sofisticato da fare in modo che nessuno sapesse che esse fossero compromesse.
Per ricapitolare: la chiavi di sicurezza danno il là ai driver, i quali permettono l'installazione di un 'rootkit', che a sua volta nasconde il worm che è stato consegnato dal drive USB corrotto. Stuxnet a quel punto ha l'obiettivo di propagarsi con efficienza e in modo silenzioso. Allorché un altro drive USB viene inserito in un computer già infetto, esso viene infettato a sua volta. Ma per ridurre la sua tracciabilità, Stuxnet permette ad ogni USB infetta di passare il worm in soli tre computer alla volta. Ma questo non è il solo modo con cui Stuxnet si propaga. (Fine della prima puntata, continua...)
Tratto da The Weekly Standard
Traduzione di Edoardo Ferrazzani

non intendevo l'economico nel senso di risparmio, ma economico inteso come contratti da rispettare e nel caso penali da pagare..
Interrompere il lancio avrebbe causato un insolvenza contrattuale e allora si è rischiato, le guarnizioni avrebbero forse tenuto.
Per quanto concerne i rootkit e la loro diffusione sarei di tutt'altra opinione, incontrandone tutti i giorni , i sistemi windows sono completamente vulnerabili e i monitoraggi di sicurezza sono cose da operetta o forse ne sono la causa.
in ogni modo non è questo l'argomento da trattare qui.

Vecchio aforisma informatico : l'unico computer sicuro è un computer spento

ci vuol far arrivare a credere che l'unica centrale nucleare sicura è una centrale spenta, Sarek?  

Cyber-change/ 2
Chi ha inquinato il programma nucleare dell'Iran col virus "Stuxnet"?

di Jonathan V. Last21 Dicembre 2010
http://www.loccidentale.it/articolo/chi+...F.00100171

"Stuxnet" è stato disegnato per propagarsi su internet in generale, ma può muoversi anche attraverso reti locali che usano programmi di gestione delle azioni in attesa delle stampanti, i c.d. “print scoolers”. In ogni gruppo di computer con una stampante in comune, quando un computer si infetta, Stuxnet striscia velocemente attraverso il print scooler della stampante per contaminare tutti gli altri. Una volta raggiunto un computer con un accesso alla rete, esso comincia a comunicare con i centri di comando e controllo dei server in Danimarca e in Malesia (chiunque abbia gestito l'operazione in questione ha messo questi server fuori rete, ovvero offline, appena Stuxnet è stato scoperto). Mentre i server erano in funzione, Stuxnet ha rilasciato informazioni che aveva raccolto a proposito dei sistemi che aveva invaso, immettendole nei server e richiedendo delle versioni aggiornate di sé stesso.
Varie versioni di Stuxnet sono state isolate, e ciò significa che i programmatori sono stati in grado ridefinire in tempo reale il worm, ben oltre il momento del suo rilascio. Infine si parli degli effetti del worm. Una volta dentro una macchina con sistema operativo Windows, Stuxnet cerca i programmi WinCC e PCS 7 SCADA. Se la macchina non possiede nessuno dei due, allora Stuxnet si dà il semplice obiettivo di propagarsi. Quando invece Stuxnet riesce a trovare uno dei due programmi, allora il worm inizia la riprogrammazione del software di controllo logico programmabile (programmable logic control, PLC), apportando modifiche in un pezzo di codice chiamato Blocco Operazionale 35 (Operational Block 35). Per mesi nessuno è riuscito a comprendere cosa Stuxnet intendesse fare con questo blocco una volta impossessatosene. Da tre settimane la ragione è divenuta chiara.
L'ingegnere di cybersicurezza Ralph Langner la mette cosi: Stuxnet è un'arma con due testate. La prima 'testata' è stata indirizzata al programma di controllo Siemens S7-417 della centrale nucleare di Bushehr. La seconda ha puntato al programma di controllo Siemens S7-315 della centrifuga di Natanz, dove l'uranio è processato e arricchito. A Bushehr il worm Stuxnet ha probabilmente tentato di degradare la turbina a vapore dell'impianto, con risultati che ci sono sconosciuti. Quanto all'attacco a Natanz, sembra aver dato risultati brillanti. Ancora una volta, la progettazione di Stuxnet ha dimostrato un'eleganza inaspettata. Assumendo il controllo della centrifuga di Natanz, il worm ha scatenato un singolo e catastrofico incidente.
Stuxnet ha di fatto assunto il controllo dei convertitori di frequenza della centrifuga durante le operazioni di routine giornaliera, dando il là a piccole esplosioni accelerative delle attività della macchina, seguite da repentine decelerazioni. Questi cambi di velocità hanno sottoposto a stress le componenti della centrifuga. Le componenti si sono deteriorate velocemente, sino a rompere misteriosamente le centrifughe. Inoltre ciò ha permesso che l'uranio sottoposto ad arricchimento si corrompesse. Nel frattempo mentre i danni si estendevano, Stuxnet ha continuato ad inviare agli iraniani normali feedback, dicendo loro che dal punto di vista del computer, il sistema stava operando come un orologio svizzero. Questo lenta degradazione è andata avanti per un anno, portando gli iraniani all'esasperazione per ciò che sembrava sabotaggio e che sapeva di sabotaggio, benché i loro computer non mancassero di rassicurarli sul fatto che tutto stesse filando liscio.
Per farla breve: Stuxnet ha mandato al macero un anno di sforzi di arricchimento a Natanz, fatto danni nelle componenti della centrifuga e nei luoghi di stoccaggio dell'uranio, seminato il caos nel programma nucleare iraniano e forzato con buona probabilità l'Iran a spendere un anno ancora nella disinfestazione di propri sistemi prima che possano operare con i picchi di operatività pre-infezione. Considerato tutto, un'operazione di successo.
Chi merita credito per Stuxnet? Tre possibilità: la prima un singolo attore statuale; seconda possibilità: un consorzio di Stati; e terza possibilità: un gruppo privato. Ognuna di queste possibilità è a prima vista plausibile. Ma l'exploit è certamente stato molto più complicato di quanto non appaia a prima vista. La pianificazione e l'implementazione di Stuxnet è certamente passata per il superamento di tre livelli di complicazione.
Il primo livello sta nella sofisticazione del worm stesso. Microsoft ha stimato che la codificazione di Stuxnet ha avuto bisogno di qualcosa di simile ad un monte ore vicino alle 10.000 giornate di lavoro umano. Con una squadra composta da una gruppo di programmatori oscillante tra le 30 e le 50 unità, la sua progettazione avrà avuto bisogno di almeno un anno o due di sforzo creativo. Tra il monte ore, i test del “giorno zero” e il design innovativo del worm, Stuxnet ha certamente richiesto non solo tempo, ma anche enorme sofisticazione tecnica e significativa dotazione finanziaria.Il secondo livello riguarda la competenza da parte dei creatori di Stuxnet delle misteriose maestranze dello spionaggio. I certificati di verifica digitale devono essere stati rubati a Taiwan, e le USB infette devono essere state seminate dentro, o intorno, alla comunità di persone che lavorano nel programma nucleare iraniano, e ciò reso possibile con le tecniche di spionaggio moderno espresse ai più alti livelli.
Il terzo e ultimo livello di complicazione sta nell'ampio livello di competenza richiesto in termini di ingegneristica nucleare. Non è sufficiente infatti progettare un worm da infiltrare in una centrale nucleare. I creatori di Stuxnet dovevano avere delle competenze in almeno tre ambiti.  In primis essi dovevano sapere quali parti attaccare. Secondo: essi dovevano conoscere i dettagli della progettazione dei sistemi. E terzo: essi dovevano sapere come manipolare i sistemi al fine di raggiungere gli effetti desiderati.
Non v'è dubbio che raccogliere questi tre livelli di competenza deve essere stata impresa molto ardua. Il mondo è pieno di zelanti appassionati di computer; ma non ci sono tante persone che comprendano esattamente come centrifughe e reattori nucleari funzionino, oltre ad avere una minuta comprensione delle complessità dei sistemi di controllo quali il Siemens S7-315 o il S7-417. Appare improbabile che una parte privata – un gruppo di reprobi hacker o civili interessati – possano aver raccolto le competenze richieste in queste tre aree di conoscenza.
Allora chi è stato: gli israeliani, gli Stati Uniti, la Germania o la Russia? Una qualche combinazione dei suddetti? Non lo sapremo mai. Dato lo scopo dell'operazione, è già abbastanza incredibile che si possa capire quel che già abbiamo colto sul conto di Stuxnet. Molti dei precedenti atti di cyber-guerra hanno avuto luogo nell'ombra. Stuxnet è la prima seria cyber-arma vista in azione da civili. E questa è proprio la ragione per cui abbiamo assistito, negli scorsi mesi, alla nascita di un gruppo d'investigazione open-source, composto da esperti in differenti discipline da ogni parte del mondo. Gli entusiasti di tecnologia continueranno a spingere e a testare Stuxnet, nel tentativo di capire come abbia funzionato, e soprattutto per comprendere come certi sistemi possano essere protetti da simili attacchi. E questo ci porta in estrema analisi ad affermare che fondamentalmente la cyber-guerra non è diversa dalla guerra tradizionale. Le innovazioni possono essere copiate, e esiste sempre la possibilità che i nemici possano usarle a proprio vantaggio. (Seconda puntata. Fine)
Tratto da The Weekly Standard
Traduzione di Edoardo Ferrazzani

Quando ho aperto questa discussione speravo fosse possibile affrontare argomenti tecnico specialistici, ma vedo che è molto difficile entrare nello specifico.
La discussione relativa ai sistemi informatici, più o meno sicuri, può essere interessante e deve far pensare, ma dalla mia esperienza personale posso affermare che i sistemi SW "di funzionamento" delle reti di telecomunicazione non sono  attaccabili dai cosi detti virus, worm e company.
Per condurre un attacco, escludendo un complice, e prendere il controllo del sistema è necessario che questo sia interfacciato alla rete esterna con SW di tipo commerciale, a questo punto l'attaccante (umano) dopo essersi scavato un tunnel deve essere in grado di agire sul sistema, conoscendolo a fondo.
Per non entrare nei particolari, posso dire che i comandi Uomo/Macchina di un complesso HW/SW tipo centrale telefonoca sono qualche centinaio, tutti specifici e devono essere impartiti conoscendo perfettamente la configurazione/tipologia/architettura dell'impianto stesso e dell'insieme della rete, pena l'impossibilità di agire e tanto meno provocare danni o fermi.
E' possibile altresi creare un insiema di disservizi a tutto quello che sta intorno, sistemi commerciali e gestionali, praticamente all'interno delle intranet LAN/WAN che si basano su SO commerciali stile Microsoft in primis.
Per deontologia professionale non posso divulgare il metodo di attacco e relative malfunzioni subite "a opera di NIMDA" da una delle più grandi reti LAN/WAN nazionali, ma posso affermare che la cosa era mirata a server e PC Microsoft, provocando notevole "fastidio" numerosi restart della intranet ma nessun disservizio agli apparati di sistema.
Il SW dedicato ai vari apparati,vi assicuro molto eterogenei, non ha accusato nessuna defaiance e di conseguenza nessun disservizio.
Il disagio diciamo era solo a livello di ufficio non di sala macchine.
Ma se usiamo come piattaforma un SO commerciale (Microsoft) e sopra ci mettiamo un gestionale per controlli e attuatori, poi colleghiamo il tutto a una LAN con accessi verso WAN, tutto diventa possibile, tipo inchiodare i PC in un momento delicato del processo. In queste condizioni gli operatori (umani) potrebbero essere sviati e aver bisogno di parecchio tempo prima di passare ai comandi "manuali"

Ho parlato cosi' tanto di NIMDA negli anni, ma era un po' che non mi capitava di ricordarmelo! Grazie Walter per il flashback!

Sono d'accordissimo con lei, c'e' una gran differenza tra un attacco stupido, che mira ad un Denial of Service o DoS, rispetto ad un hacker che impianta un qualche worm o rootkit e, durante un periodo di tempo anche lungo, continua ad operare inosservato all'interno di una infrastruttura a lui sconosciuta, capendo sempre di piu' l'ambito in cui si trova e potenzialmente crescendo la sua capacita' di andare a fare danni in maniera molto precisa.  Altroche' Denial of Service!

Rimango dell'idea che reti con livelli di sicurezza diverse possano anche essere fisicamente, e non solo logicamente, separate.  Le VLAN possono essere un sistema accettabile a livello commerciale, permettendo di segmentare traffico in LAN virtuali differenti, ma magari in un ambito di comando e controllo di una centrale nucleare o comunque di un impianto con processi industriali di una certa criticita', potrebbero essere gia' un compromesso non accettabile.

Cordiali saluti,
Luca Bertagnolio

Concordo pienamente su tutto con LUCABERTA

Niente panico ma è correto informare che solo gli aerei militari( non ricordo i modelli) hanno la compesazione volumetrica nel svutamento dei serbatoi  con gas inerte ( azoto?) per neutralizzare la formazione di miscele potenzialmente esplosive.
Per le aereomobili civili costerebbe troppo...........

Si grazie, il mio voleva solo essere una indicazione ( x Sarek) che troppo spesso ci allarma su cose che non si conoscono e si ignorano cose che se le conosci ti fanno accaponare la pelle.

Naturalmente il calcolo statistico gioca un ruolo fondamentale.....il famoso tzunami con onde da 14 metri bisogna andare indietro di 1040 anni fà in Giappone.
Ps non è una scusante!

http://nuclearstreet.com/

qui avevo trovato del materiale interessante sia software e controllo, quando lo trovo lo posto.
Potete cercare anche Voi

Argomento molto interessante.
Ho girato la domanda del post ad un amico di EDF (che pero' si occupa di altro, anche se ha fatto training presso un simulatore).
Non mi ha dato una risposta (tecnicamente) estesa. Ha tagliato corto, facendomi notare che, parole testuali, "una centrale nucleare non e' un aereo" ne' un comune PLC... e che "anche su un aereo il software non ha il totale controllo dei sistemi" (esiste sempre il controllo manuale).
La questione "uso del software" non intacca gli aspetti della sicurezza, per es. in caso di sisma, gli accelerometri (non interfacciati in nessun modo con il software esterno e all'hw riprogrammabile) inviano automaticamente, come e' successo a tutte le centrali giapponesi, fukushima compresa, il segnale (elettrico) di scram [senza considerare lo scram passivo, in caso di anomalie elettriche].
Inoltre ricordo a tutti che la sala controllo e' piena di manopole e bottoni (specie nelle vecchie centrali), con cui si possono fare le principali operazioni, e che tali sistemi sono ridondanti.
La mail continuava dicendo che se la MCR saltasse in aria, il reattore si spegnerebbe e i sistemi di raffreddamento inizierebbero a lavorare. Il resto non conta. L'isola nucleare andrebbe in sicurezza.

I sistemi di emergenza non sono riprogrammabili e il software non interferisce in alcun modo; non possono essere "sabotati" neanche manualmente dagli operatori.

Penso che non si possa paragonare una centrale nucleare ad un "oggetto che vola", perche' l'oggetto che vola e' per sua natura instabile e per sua natura "tende a rompersi" (a cadere al suolo). Richiede un controllo ben piu' sofisticato e flessibile. Inoltre se una aereo va in stallo e' fottuto (in ogni caso). Il controllo e' ben diverso.
Una centrale nucleare deve fare poche cose: produrre energia e garantire di farlo in modo sicuro (e possibilmente efficiente).
Poi tutto il resto puo' essere reso complicato quanto si vuole (si puo' prevedere un sistema che analizza e fa previsioni sul burnup, ci saranno processi per l'acquisizione dei dati e la loro elaborazione, altri sistemi che inviano i dati, altri che visualizzano cosa sta succedendo, altri che permettano di inviare/ricevere richieste varie dall'esterno, altri che permettono, per assurdo, di andare a cazzeggiare su facebook), ma la parte critica e' semplificata e resa autonoma in caso di avaria.

Il prof. di impianti nucleari una volta disse "l'informatica non e' affidabile".

Ho letto l'articolo di "The Weekly Standard". Ho cercato qualche fonte non giornalistica. Non ho trovato niente, e per come funziona il mio "software", sono portato ad essere abbastanza perplesso sulla veridicita' di quella notizia.
Una centrifuga di un impianto di arricchimento non e' una comune centrifuga industriale e il processo di arricchimento non ha eguali; una volta messa in marcia non ha senso variare la velocita'... sono in cascata, a migliaia, modificare la velocita' di una di esse sarebbe stupido (perche' prevedere allora quella possibilita'?).
La mia e' pero' una critica perfettamente sindacabile (non so come sono controllate le centrifughe).
Avrei preferito leggere quella notizia da qualche altra parte... sapete, i giornalisti come sono... ma certo, non per questo l'accaduto e' falso...
Cmq, un impianto di arricchimento e' ben diverso da una centrale nucleare (e molto piu' simile ad un impianto chimico).

Fino a che non avremo documentazione specifica, penso si possano fare tutte le ipotesi che uno vuole.
Per quello che ho studiato all'uni, mi verrebbe da dire che, ammesso che sia possibile l'hacking, l'eventuale software presente, se compromesso potrebbe provocare al max lo scram. Cosa non da poco, perche' lo spegnimento del reattore provocherebbe un danno economico sensibile; e, per chi non lo sapesse, un reattore non e' una caldaia che puo' essere riaccesa subito dopo lo spegnimento... per colpa di Xe e Sm, ci possono volere decine di ore prima di ripartire.

Nessuna equiparazione di una centrale ad un aereo!
Era intenzione di Serek di fare una similitudine, la mia ripresa era che la similitudine ( giusta ) racchiudeva un aspetto tecnico sconosciuto ai più.

Confermato da LB e la valutazione finale era che "la tecnologia c'è" il mitico rapporto costo/sicurezza e finchè la statistica pende dalla parte "niente coastrofe" niente incremento.

Fukuschima : il costo per dei ricombinatori catalitici dell'idrogeno + l'innoservanza delle regole di manutenzione hanno generato un risparmio significativo alla compagnia ?
Vuole essere una domanda.

Vorrei qualche notizia in più sul virus o malware Stuxnet che ha colpito le centrifughe nucleari iraniane. Devo dire che la cosa mi ha impaurito, pensando ad un possibile attacco ai sistemi informatici di una qualsiasi centrale nucleare.
Grazie

(sto facendo sempre piu' spesso il polemico... e' una cosa che mi infastidisce, spero di non creare fastidio ad altri)

Rispondo a Walter e a Luca:

Neanche io intendevo equiparare direttamente una centrale ad un aereo, ma il parallelo sulle metodologie mi sembrava praticabile.

Se non vado errato, così come un aereo senza il corretto funzionamento di tutto un insieme di teconolgie non potrebbe volare, un reattore ha ugualmente bisogno che tutta una serie di tecnologie funzionino correttamente per poter operare. Insomma entrambe le cose sono 'tecnologicamente' stabili, non 'naturalmente' stabili.

Sul fatto che i reattori abbiano margini più ampi nei modi e tempi di intervento non concordo. Dipende dalla situazione a dalla sorte. A Cernobyl sono passati solo 7 secondi tra l'attivazione dello SCRAM e l'irrecuperabile perdita di controllo del sistema.

Quindi, a mio avviso, alcuni approcci potrebbero essere mutuabili, considerando anche che l'aviazione civile è arrivata ad essere il mezzo di trasporto statisticamente più sicuro.

Per quanto riguarda l'informatica io non sarei così categorico da definirla inaffidabile. E' indubbio che le probabilità di un difetto aumentino con l'aumentare della complessità, ed esite, in informatica, un acronimo per ricordare la cosa.
KISS = Keep It Simple Stupid
Effettivamente mettere un computer a fare il lavoro di un banale accelerometro inerziale non offrirebbe alcun vantaggio aumentando invece le probabilità di problemi.

Però è anche vero che sistemi complessi riescono a produrre risultati non raggiungibili in altro modo, il che potrebbe avere tutta un'altra serie di vantaggi. Per continuare il parallelo avionico veivoli con ali a freccia negativa o motori a spinta vettoriale probabilmente non sarebbero utilizzabili senza l'informatica di controllo.

Qui per farsi un'idea sulla sicurezza di reattore:
http://www.ingegnerianucleare.net/Temati...D_note.htm

--------------

http://www.ingegnerianucleare.net/Temati...aD_epr.htm

Per i ricombinatori di idrogeno:
Inoltre i dispositivi ricombinatori (che ‘bruciano’ l’idrogeno gradualmente) ne mantengono la concentrazione sempre al di sotto del 10 %, scongiurando in questo modo ogni pericolo di detonazione (tale gas è esplosivo in un range di concentrazioni[3] comprese fra il 15 ed il 59 %);

Ho appena letto di questo video su TED che ha come tema Stuxnet:

Altre informazioni su Stuxnet da un blog molto popolare in Silicon Valley, in un post che cita anche il video su TED da me linkato qui ieri:

http://blogs.siliconvalley.com/gmsv/2011...-iran.html

Un altro post relativo a Stuxnet sullo stesso blog, scritto quando si scopri' il worm, e' questo:

http://blogs.siliconvalley.com/gmsv/2010...erwar.html

Ciao, Luca

http://www.ted.com/talks/lang/ita/bill_gates.html