Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
By signing up, you agree to our Terms & Conditions and agree that Teknologiens Mediehus and the IDA Group may occasionally contact you regarding events, analyzes, news, offers, etc. by telephone, SMS and email. Newsletters and emails from Teknologiens Mediehus may contain marketing from marketing partners.
thorium energy bloghoved

Copenhagen Atomics Control Systems (del 2)

Jeg har netop modtaget endnu en god nyhed for thoriumenergi i Danmark. Jeg har fået mulighed for at tale om thoriumenergi og Copenhagen Atomics på TEDxCopenhagen 7. april.

Denne blog er anden del i en serie om kontrolsystemer. I første del fik vi forklaret, hvad walk-away-safe- og priminister-safety-principperne går ud på. Copenhagen Atomics ønsker at overholde begge disse sikkerheds- principper. Men vi vil gerne endnu videre:

Der findes en række systemer i verden, hvor der er brugt for MEGET sikker computer/software. Nogle af dem er:

  • Nuclear Power Plants
  • Body Implants
  • Self Driving Cars
  • Drones and Quadcopters

Jeg har været så heldig at være involveret i flere projekter med software til nogle af de ovenstående, og det blev meget hurtigt klart for os, at det er meget langt fra optimalt at bruge de gængse operativsystemer, vi har i verden i dag. Det ville være formålstjenligt, hvis vi kunne skabe et helt nyt VERY SECURE OPERATING SYSTEM (VSOS), som kan bruges af alle ingeniører til applikationer som de ovenstående. De 5 primære egenskaber skal være:

  1. Det går ikke ned
  2. Det kan ikke hackes
  3. Softwaren kan opdateres sikkert på/fra den anden side af jorden
  4. Det har internetadgang
  5. Det skal være open source, så alle kan have tillid til det

De, som ved noget om software og hardware, kan se, at dette bliver SVÆRT! Målet er heller ikke 100.0000 % fejlfri, men 99.999999% fejlfri. Så det handler om at minimere fejl til næsten ingen. Lad os starte ved punkt 1. Hvis hardware og software ikke må kunne gå ned, så skal hardwaren dubleres en eller flere gange, og den skal være godkendt via meget grundige tests til det driftsmiljø, som den udsættes for. Softwaren skal laves, så den ikke kan lave deadlock og den skal kunne tåle memory- og CPU-fejl. Desuden skal den være så simpel, at det er nemt at forstå, hvad den laver. Dette gøres bedst ved at lave softwaren som en state-maskine på det øverste niveau og have en række hardware watchdog timers som sikker genetablering, hvis noget er gået galt.

Hvis noget ikke skal kunne hackes, skal vi sikre os, at der er meget begrænset skriveadgang til systemet, samt at det kræver adgang til flere nøgler, før man kan opdatere systemet. Som hovedregel må skriveadgang til systemet ikke kunne ændre layout og regler for state maskinen på det øverste niveau. Det må kun være data, som kan bruges af subrutiner i de underliggende niveauer af systemet. Skriveadgang kan altså godt igangsætte state change, på topniveau, men ikke ændre selve state maskinen. Hvis dette princip overholdes, bliver det MEGET svært for en hacker at få kontrol med systemet. Skriveadgang skal f.eks. bruges til at fortælle en drone, hvor den skal flyve hen eller fortælle et atomkraftværk, hvor meget power output man ønsker den næste time.

Der er kun ét stort hul tilbage, nemlig at hackeren kommer ind via en software update. Men samtidig vil vi gerne have at det er muligt at lave opdatering af software af vores kirurgiske implantater og selvkørende biler, efterhånden som teknologien bliver forbedret. Så hvordan sikrer vi os lige, at en hacker ikke får puttet noget kode med ind i en af disse opdateringer eller bare snyder vores VSOS til at tro at hans opdatering er en officiel handling og dermed få den kørt på.

Dette punkt kræver nok lidt mere debat og dialog, men et af de forslag vi er kommet frem med er, at før man kan lave en software opdatering, skal den nye kode altid uploades via VPN fra 2 forskellige adresser, som man har tillid til. Når systemet har modtaget 2 pakker, som er ens, så giver VSOS besked til fabrikanten og evt. andre ”myndigheder” om, at den vil opdatere om 24 timer. Grunden til at vi ønsker, der skal gå 24 timer før opdateringen bliver installeret, er for at give tid til at opdage, hvis noget er galt og sende en update abort command. Samtidig lægger dette også et pres på dem, som laver en officiel software opdatering, så de ikke er uforsigtige og frigiver noget skidt. Der går altså 24 timer, før de kan overskrive forrige opdatering. Grunden til, at det skal være open source, er for at skabe maximal tillid til systemet. Måske starter vi kun med 99.999% fejlfri på første version, men vi skulle gerne nå meget højere op. Dette gøres bedst igennem åbenhed og input fra et stort antal mennesker = open source.

Som omtalt i første del af denne artikel, så vil vi gerne have en stor grad af læseadgang til kontrolsystemet, hvis det bruges til at styre et atomkraftværk. Dette gælder også hvis det er et kirurgisk implantat med bloddata eller en quadcopter med positionsdata. Men det er selvfølgelig vigtigt at læseadgangen altid er sekundær til afvikling af den styrekode, som lever inde i kontrolsystemet, og læsesystemet må ikke åbne for yderligere huller, som hackere kan bruge. Derfor skal man altid tænke på læseystemet, som om det allerede er blevet hacket.

Illustration: Thomas Jam Pedersen

Ovenstående figur viser tydeligt at Read controllerne kører på hardware, som er helt adskilt fra den centrale kontrolenhed (CCU). I dag hvor en CPU med hukommelse og internetadgang kan fås til $5 eller kan laves, så den fylder mindre end 1 mm2, så ville det være helt forkert at designe dem på samme hardware.

CCU’en skal være dupleret, så man kan lave software opdatering og teste, at den nye software virker, før man skifter over. Den skal selvfølgelig også kunne tåle, at strømmen forsvinder midt under software opdateringen. Samtidig giver en duplering også mulighed for at overleve i nogle uger fra, at den ene enhed fejler, til man får skaffet og skiftet til nyt hardware. Figuren viser også, at det er CCU’en, som styrer al kommunikation imellem Read controlleren og det øvrige system. Der sker ingen eller næsten ingen dataflow fra Read controlleren og ned til CCU’en, højst nogle få flag eller enkelte talværdier for at undgå sikkerhedshuller.

Det er tanken, at hardware design og software i Read controlleren og CCU’en er open source og tilgængelig fra github. Mens de, som hedder ”other systems”, i princippet godt kan være proprietære systemer, kunne de f.eks. køre under en anden proces og evt. med meget færre rettigheder. F.eks. uden mulighed for at lave software opdateringer. Disse detaljer er endnu ikke færdig debatterede.

Vores system kræver selvfølgelig noget specielfremstillet hardware, som gør det væsentligt dyrere end det, vi finder i konsumerelektronikindustrien. Men det vil stadig være meget billigere end alt det specielle hardware, man finder i kontrolrum i traditionelle atomkraftværker.

Copenhagen Atomics er p.t. i dialog med nogle meget dygtige softwarefolk om udviklingen af dette VERY SECURE OPERATING SYSTEM.

Planen er at gøre designet mere færdigt og samtidig begynde at implementere det. Dernæst vil vi lave en officiel Request for Comments (RfC), som skal indsendes til IETF eller en anden relevant organisation. Dette må forventes at give anledning til noget feedback og nogle rettelser, hvorefter det er tid til at lave den første MVP (Minimum Viable Product) til test og frigivelse på Github. Næste skridt derefter ville nok være artikler i akademiske tidskrifter eller præsentation på konferencer.

Vi vil dog fortsat gerne i kontakt med personer med unikke kompetencer inden for dette felt (OS / hardware / test / sikkerhed), som kan hjælpe os med at lave verdens mest sikre OS-platform.

Som en del af ovenstående så vil vi også implementere kontrolsystemet til Copenhagen Atomics Waste Burner, så vi kan se, at det virker i praksis. Det skulle gerne være klar om ca. 2 år, når vi forventer at have vores første none-fission prototype klar. Selve operativsystemet bliver ikke særlig kompliceret, men der bliver dele af de underliggende systemer, som har godt med kød på sig. Det er dem, som er betegnet som ”other systems” på figuren ovenfor. Senere vil der også komme en blog om nogle af disse dele, men jeg vil her blot give en meget kort forklaring på, hvordan denne del kommer til at virke.

Internt i kontrolsystemet har vi en vektor med over 1000 parametre. I mange af disse parametre er temperatur og tryk forskellige steder i vores reaktor, men mange af parametrene viser også mængden af de forskellige isotoper i vores fuel- og off gassystem. Når man har styr på disse isotoper, så har man nemlig også styr på, hvor meget varme og stråling, der udvikles, og hvor meget fri fluor der er i systeme, og det er meget vigtigt for en optimal og sikker drift.

Hvis denne vektor kommer uden for et på forhånd veldefineret sikkert driftsområde, så vil det omgående give anledning til, at kontrolsystemet skifter til et shutdown state, og reaktoren lukker ned. Umiddelbart vil der formentlig være mindst følgende 10 states på det øverste kontrolniveau i CCU’en:

  • Not running
  • Emergency shutdown
  • Normal shutdown state
  • Startup state
  • Power ramp up
  • Power ramp down
  • Stady state power
  • Software update
  • Melt salt state
  • Pressure test state

Formentlig vil det også være muligt at læse den lange vektor med over 1000 værdier fra Read controlleren mindst en gang i minuttet. Nogle af tallene måske endnu oftere. Stopknappen, som vi omtalte i del 1 af denne

Thomas JamPedersen
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Hej Steen.

Du skriver altid meget negativt om os og vores waste burner. Det skal du selvfølgelig have lov til og vi vil altid meget gerne have konstruktivt kritik.
I dit seneste udbrud har jeg kun et kort svar. Jeg går ud fra at du er enig i at stor grad af kompleksitet ikke i sig selv sikre et højere niveau af sikkerhed. Måske endda tvært imod.

Der er desværre folk som arbejder med udvikling af software til den gamle nuclear industri som har et ønske om stor grad af kompleksitet. Et af de dokumenter du linker til er netop et udtryk for dette.

  • 6
  • 2

Når systemet har modtaget 2 pakker, som er ens, så giver VSOS besked til fabrikanten og evt. andre ”myndigheder” om, at den vil opdatere om 24 timer. Grunden til at vi ønsker, der skal gå 24 timer før opdateringen bliver installeret, er for at give tid til at opdage, hvis noget er galt og sende en update abort command.

Det betyder så også at hvis man opdager at der er noget forkert/hacket/farligt/katastrofalt software der er blevet distribueret (og det er kun et spørgsmål om tid), så er der mindst 24 timer til at man kan rette fejlen/problemet - og altså 24 timer før man kan forhindre problemer i at opstå...

HC

  • 1
  • 0

så er der mindst 24 timer til at man kan rette fejlen/problemet - og altså 24 timer før man kan forhindre problemer i at opstå...

Var også umiddelbart min tanke, tænker lidt at det bør være muligt at tvinge en "roll back" til tidligere version af OS i en periode efter at den nye version er gået i luften. Eventuelt som en walk away safe mekanisme der kræver at nogen aktivt bekræfter at alt er vel i det nye system x antal gange over de efterfølgende 48 timers drift.

  • 0
  • 0

Undskyld jeg siger det men denne artikel virker fuldstændig naiv og uden begreb om state of the art og diverse eksisterende standarder.

Tværtimod! Jeg synes, at det lyder særdeles interessant og er noget professionel automation har ventet på i årevis, selvom sikkerhedsoperativsystemer som f.eks. SafeRTOS og det ekstremt dyre Integrity 178B har været på markedet i årevis. Jeg tror stadig, at man kan skabe den 99.99 % virus- og hackerfrie computer; men det vil aldrig ske med traditionelle systemer og tankegang, hvor programmørerne for længst har opgivet og nu bare overlader alle problemer til brugeren (kan være gamle fru Olsen) og til 3. part i form af antivirusløsninger.

Det vil også være interessant for firmaer, hvor en del af softwaren skal legalt godkendes. I sådanne systemer kan man normalt ikke rette så meget som et komma, uden at skulle igennem godkendelsesproceduren én gang til, og man skal måske bryde plumber; men med et sikkerhedsoperativsystem kan de godkendte dele lægges i én task, og man kan så frit ændre i andre dele.

Jeg har dog lige et par kommentarer:

  • Dublerede CPU'er findes allerede i form af de såkaldte lockstep CPU'er som f.eks. Texas Instruments Herkules ARM serie http://www.ti.com/lsds/ti/microcontrollers... og NXP's (tidligere Freescale) e200 Power arkitektur http://www.nxp.com/products/microcontrolle... . I en lockstep CPU sammenlignes de to CPU'er konstant af hardware, og de er tidsforskudt, så en fejl forårsaget af f.eks. ladede partikler fra verdensrummet eller i jeres tilfælde fra reaktoren selv (single event upset) ikke rammer samme instruktion i begge CPU'er samtidig. Disse CPU'er er beregnet til software op til IEC 61508 SIL 3 (død af 1-3 personer), som er det højeste niveau, man kan opnå i software alene. Traditionel atomkraft skal op på SIL 4 (mulig massedød), som kræver én eller anden supplerende hardwareløsning; men med "walk-away-safety" og "priminister safety" kan det krav muligvis sænkes eller gøres lettere at overholde i jeres tilfælde?

  • En state-action maskine er håbløs til proceskontrol. Jeg vil i stedet anbefale et system baseret på enkeltstyringer (neuroner), som blot skal have information om naboelementerne plus en overordnet styrekommando, som i princippet bare er start eller stop. Når først enkeltstyringerne/neuronerne er lavet, kan programmeringen foretages direkte ud fra flowdiagrammet af anlægget og kan i princippet gøres fuldautomatisk. På denne måde har jeg bl.a. styret en foderstoffabrik med over 400 automatisk styrede enheder og med transportveje flettet ind mellem hinanden som sporene på Københavns hovedbanegård og sat hele systemet i drift på få dage - uden forudgående afprøvning! Problemet med state-action maskiner og stepprogrammer er, at kompleksiteren vokser med en høj potens af antallet af elementer, og det er håbløst at håndtere fejlsituationer og nødstop og sikre sig, at man efter en fejl, hvor mange elementer måske er blevet stoppet, kan genstarte fra det sted, hvor man var. Med neuronprogrammering er det ikke sværere at styre et stort anlæg end et lille, men tager selvfølgelig længere tid, og man opnår en form for kunstig intelligens (dog uden at systemet er selvlærende), så det opfører sig fornuftigt - også i de talrige situationer, som man ikke har haft mulighed for at teste på forhånd (man kan umuligt teste samtlige kombinationsmuligheder, der hurtigt bliver astronomisk).

Kontakt mig evt. på ck hos innovatic i danmark.

  • 4
  • 1

neuronprogrammering


Er det et udtryk du selv har opfundet? Jeg kan ikke lige google mig til det...
Det lugter lidt af fuzzy-logic, der var meget populært for nogle år tilbage.

Iøvrigt er jeg enig i at state-maskiner er en farlig vej at vælge. Kompleksiteten har det med at vokse eksponentielt i den slags systemer.

Den snak med software opdatering, to ens pakker fra forskellige vpn adresser osv.. det lyder lidt langt ude i hampen i mine ører, men nu er secure software opdatering også lige præcis mit arbejdsområde.
Nu om dage foregår den slags normalvis med public-key cryptografy. Så er det kun et spørgsmål om hvem der skal have adgang til master private key'en - den skal helst fysisk adskilles fra internettet så det i det mindste kræver social engineering (eller en bulldozer) at 'hacke' den del.
Evt. kan man bruge en multi-signature, hvor der genereres flere private-keys som alle (eller f.eks. 4-af-5) kræves før en software release kan godkendes.
Alle parter, som skal sige god for en software release, skal så hver især godkende og signe softwaren med deres egen private nøgle før den endelige release vil blive godkendt af systemet.

  • 4
  • 0

"Der findes en række systemer i verden, hvor der er brugt for MEGET sikker computer/software. Nogle af dem er:
- Nuclear Power Plants"
Min indsigt i a-kraft er begrænset, jeg har dog set et westinghouse A-kraft værk, der blev styret af et Emmerson Ovation DCS system.

Ud fra din liste virker A-kraft værker som det simpleste at implementere sikkerheds styrings funktionen til (Functional safety). Det er godtnok et 'fail operational' system, men den 'operational' kontrol funktion der skal udføres er simpel.

I min naivitet er styrings funktionen som jeg fik det beskrevet:
Overvåg en række parametre i reaktoren, kølevands stand, temperatur, tryk, neutron flux, og SCRAM hvis de overskrides.
Dette foretages i et sikkerheds system der er adskilt fra DCS systemet, med adskille parallelle kanaler, der hver kan åbne nogle SCRAM relæer.
Kontrolstavene er drevet af en linær motor der har den egenskab at hvis spændingen afbrydes, så falder kontrolstavene ned i reaktoren:
http://pbadupws.nrc.gov/docs/ML0403/ML0403...

kølesystemet er mere kompliceret, men hoved princippet er at hvis man er i tvivl så start rigeligt med disel generatorer, og kølepumper. Selve kølepumperne styres normalt af et DCS system der ikke SIL rated.
http://www.nrc.gov/reading-rm/basic-ref/st...

Det største problem er at sikre at der ikke er common course mellem systemerne.

  • 0
  • 0

Naivt lyder unuanceret - unoedvendigt og urealistiskt ambitioest klinger bedre.

Hvis projektet med at vise verden hvordan man bygger rentable og absolut sikre A-kraftvaerker haenger paa at man foerst skal laere verden at lave sikre og fejlfrie computere, operativsystemer og programoerer hvorfor saa ikke tage munden fuld og skabe fred i mellemoesten, kurere kraeft og redde naesehornet.

Hvis man skal tage jer alvorligt, saa design jeres anlaeg saa computerne ikke behoever vaere ufejlbarlige og saa brug dele der allerede er paa markedet hvor det kan lade sig goere.

Undlad at involvere software overhovedet i styring og regulering - makaniske loesninger og dedikeret hardware paa alle kritiske steder og saa begraens brugen af software til registrering og udskrivning af elregninger.

  • 3
  • 1

neuronprogrammering

Er det et udtryk du selv har opfundet? Jeg kan ikke lige google mig til det...
Det lugter lidt af fuzzy-logic, der var meget populært for nogle år tilbage.

Ja, det er delvis selvopfundet; men det er den bedste betegnelse, jeg har kunnet finde, som beskriver systemets opbygning. Til ekstremt pålidelige systemer har jeg også arbejdet med en struktur, hvor hver neuron ikke bare var programmeret, men bestod af en simpel FPGA, som i modsætning til en mikrocomputer ikke kan "gå ned". Helt tilbage i 80'erne var der også noget, der hed en transputer, som arbejdede lidt på samme måde - se https://en.wikipedia.org/wiki/Transputer

Det har absolut intet med fuzzy-logik at gøre, som ganske rigtigt var meget populært for mange år siden; men vist aldrig rigtig førte til brugbare systemer.

  • 0
  • 2

Hej Thomas,

Som altid en meget spændende blog! Og tillykke med TEDxCopenhagen-invutationen.

Et spørgsmål, du har før nævnt begrebet "priminister-safety". Jeg kan ikke finde begrebet på Google; skal der i stedet stå "prime-minister-safety"? Beklager hvis det blot er et spørgsmål om manglende Google-Fu fra min side ;-)

VH Troels

  • 1
  • 0

Thomas skrev:

Hej Steen.

Du skriver altid meget negativt om os og vores waste burner. Det skal du selvfølgelig have lov til og vi vil altid meget gerne have konstruktivt kritik.


Det beklager jeg, for jeg er meget positiv overfor jeres projekt og thoriumenergi generelt. Husk at man ofte har brug for en god ven der siger tingene som de er.

I dit seneste udbrud har jeg kun et kort svar. Jeg går ud fra at du er enig i at stor grad af kompleksitet ikke i sig selv sikre et højere niveau af sikkerhed. Måske endda tvært imod.

Enig!

Der er desværre folk som arbejder med udvikling af software til den gamle nuclear industri som har et ønske om stor grad af kompleksitet. Et af de dokumenter du linker til er netop et udtryk for dette.

Jeg kender noget lignende - for nogle år siden begyndte jeg at arbejde med software i automobilindustrien. Nu da jeg endelig kender reglerne kan jeg begynde at bøje dem lidt.

At bygge en Thoriumreaktor, er som du helt sikkert ved, et meget ambitiøst projekt. Jeg er bange for at hvis i også beslutter jer for at bruge tid og energi på 1) at skabe et nyt sikkert operativsystem, 2) tilsidesætte/genopfinde alle eksisterende standarder for functional safety software i akraftbranchen OG 3) ændre de forskellige myndigheders opfattelse af disse - så vil i fejle. Jeg synes det er naivt at tro på at dette kan gøres af en organisation som jeres.

I bliver nødt til at alliere jer med nogle partnere der allerede har styr på det. Når i engang har forstået hvordan det virker og lavet jeres første system er tiden måske kommet til at lave et revolutionerende nyt design.

Jeg har arbejdet mange år med IT sikkerhed og har set mange udviklere som forkaster det eksisterende for at udvikle et eller andet "100% sikkert". Det fejler næste altid fordi det er meget svært at lave noget som er sikrere end et eksisterende system der allerede har været i ilden - det ny system vil have ny ukendte sårbarheder og problemer som man ikke skal undervudere! Ja faktisk er disse hjemmelavede "100% sikre" elementer ofte den største kilde til fejl og sårbarheder. (Jeres tegning ser ud forresten ud til at blande VPN sammen med digital signatur som er den bedste mådre at sikre software integritet på.)

Vær opmærksom på at sikkerhed ikke starter med at diskutere kontroller inkl. tekniske løsninger. Først skal man forstå risikoen, truslerne, sårbarhederne (teoretiske og dem som er set i virkeligheden), lovgivernes og ledelsens krav inkl. risko appetit. Først derefter kan man begynde at designe sikkerhedskontroller. Husk også at sikkerhedskontroller kan have bivirkninger som kan skabe ny problemer - f.eks. Lufthansa piloten som kunne crashe flyet takket været cockpitets sikkerhedsdør. Her tænker jeg på jeres 24 timers regel som ikke virker særlig gennemtænkt og som nedsætter systemes agility og muligheden for hurtige fejlløsninger.

Undskyld hvis jeg virker negativ. Men jeg tror virkelig at i skal koncentrere jer om jeres Core business: thorium reaktoren for at få success. Udenomssnak som sikre operativsystemer og ny paradigmer for sotware functional safety kan dræbe jeres fremskrifdt IMHO.

Fortsat held og lykke med jeres projekt!

Mvh
Steen

  • 3
  • 0