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 System (del 3)

Denne artikel vil formentlig få meget kritik, fordi den er lavet under tidspres og målet kun er en brain-storm om, hvor simpelt man kan lave den første version af vores kontrolsystem og den tilhørende waste burner emulator.

Vi har altså desværre ikke nået at færdigøre implementeringen af dette endnu. Vi er stadig midt i vores interne dialog om, hvordan vi ønsker at bygge den første meget simple muckup, og nu har vi så, i bedste reality stil, valgt at inddrage læseren i denne proces. Vi vil selvfølgelig lave fejl, når vi skriver om arbejdet, samtidig med, at det udvikler sig imellem hænderne på os. Men vi har også oplevet, at især den seneste blog har givet os noget meget værdifuldt feedback, som har givet værdi i vores interne proces. Vi vover derfor pelsen endnu engang og skriver om noget, som næsten kun er på tankestadiet.

Er hastværk og tidspres ikke blot lastværk? Jo til dels, men vi arbejder med disse ting i vores fritid, og vores personlige situationer gør, at vi er flere, som må drosle ned med arbejdet den næste månedstid. Derfor mener vi, at det er nu det skal ud, mens vores tanker er friske, så de kan ”arbejde” ude på nettet, mens vi ligger underdrejet og forhåbentlig samle momentum og få konstruktivt feedback.

Lad mig være helt konkret: Målet med vores arbejde er at bygge den første meget simple Waste Burner Emulator (WBE) og det tilhørende Very Secure Operating System (VSOS) som blev beskrevet i del 2 af denne blogserie. Målet med denne del 3 er at give læsere på ing.dk et simpelt billede af, hvordan vi gør dette. Altså først en forsimpling af produktet (alpha version) og så en yderligere forsimpling af beskrivelsen her for at holde det under 1500 ord. Kom til vores møder, hvis du vil have flere detaljer.

I første alphaversion bygger vi det hele i software og uden et sikkerhedslag. C# for at være præcis. Altså ikke noget hardware. Vi simulerer de forskellige hardwarekomponenter ved at implementere et antal selvstændige micro web-servere bygget på .NET Core. Jeg kommer tilbage til indholdet af ReadController senere. I det virkelige system vil kommunikationen imellem ReadControlleren og CCU’en måske ske i et meget hardware- nært master/slave lag, hvor CCU’en er master. Men for at lave alting meget simpelt og let at debugge i vores MVP, så lader vi CCU’en kalde en simpel REST webservice på ReadControlleren og aflevere en kopi af den interne state vector ca. en gang i sekundet. Kort fortalt, så kan man ud fra state vektoren alene danne sig et klart billede af, hvad der p.t. præcist sker inde i reaktoren.

Vores alpha version state vector består p.t. af følgende ca. 2400 floatværdier:

  • Den totale mængde (mol) af hver af 1328 isotoper, som findes i fuel salten.
  • Den totale mængde (mol) af hver af 512 isotoper, som findes i ”fission product trap”.
  • Den totale mængde (mol) af hver af 512 isotoper, som findes på gasform i reaktoren.
  • Tryk og temperatur og flow 7 steder i fuel salt loopet.
  • Tryk og temperatur og flow 6 steder i off gas loopet.
  • Tryk og temperatur hvor secondary coolent salt flyder ud og ind af Waste Burner containeren.
  • Tryk og temperatur og flow og væskestand af det tunge vand.
  • Primary pumps combined flow speed.
  • Secondary pumps combined flow speed.

I den virkelige version kommer state vectoren til at indeholde en del mere end ovenstående f.eks. redox værdier og nogle andre ting, som endnu ikke er fastlagte. Derfor holder jeg mig til den nævnte ovenfor i resten af artiklen.

Nu er opgaven for vores Waste Burner Emulator program (WBE) jo så, at ændre denne 2400 lange vektor på en semi-realistisk måde over tid, så vi kan lade, som om disse var rigtige måleværdier fra en rigtig reaktor. Her er det lige på sin plads at sige, at selv i en rigtig reaktor, forventer vi ikke at måle alle disse isotopmængder hvert sekund. Der kommer en blog om dette senere, men ved at kombinere LIBS og andre måleteknologier og radioaktiv henfalds-simuleringer, kan vi få en rigtig god model, som opdateres hvert sekund og viser, hvilke isotoper og redoxpotential vi har i fuelsalten hele tiden. Vores WBE har et sæt konfigurationsfiler, som afgør, hvordan fysikmodulet af emulatoren ændrer disse vektorer over tid. Det første fysikmodul vil selvfølgelig være ret simpelt, og det vil give en fejlagtig udvikling af isotopvektoren over tid og især transient response. Det vigtige er ikke nøjagtigheden, men at vi starter med en alphaversion, som er let at forstå og let at forbedre over tid.

Så du skal altså forestille dig, at vi har et selvstændigt Waste Burner Emulator program (WBE) som blot har denne interne vector på 2400 floatværdier, som den hele tiden stepper et sekund af gangen og beregner de nye værdier af vektoren. Samtidig har vi vores Copenhagen Atomics Waste Burner control software (CAWBCS), som kører oven på VSOS og med jævne mellemrum kalder (WBE) og henter, hvad den tror er måleværdier fra en rigtig reaktor. På baggrund af disse måleværdier som CAWBCS henter ud, skal den beslutte, hvilket top level state den skal være i. Som jeg skrev i sidste blog post, så vil den omgående skifte til emergancy shutdown state, hvis nogle af disse værdier kommer ud i det røde område. Så længe den er i det ”grønne” område og i normal drift, skal den blot sikre at temperatuen holdes på et konstant niveau, og det gøres ved et simpelt reguleringsloop, som skruer op og ned for pumpen og dermed for fuel salt flowrate.

Vores WBE skal selvfølgelig også tage nogle input. Disse er fuel-salt pump speed, secondary salt pump speed, trykket i dumptanken og trykket i vacuumtanken. I virkeligheden vil disse værdier blive sendt til nogle controllere, som styrer ventiler og pumper i den rigtige reaktor.Men i vores WBE sender vi dem blot til WBE- programmet, som bruger disse til at udregne, hvordan den 2400 lange vektor skal opdateres.

Den vakse læser vil allerede have opdaget, at forskellige softwareudviklere kan udvikle forskellige versioner af WBE og prøve dem af imod de øvrige komponenter i systemet. Disse kan være open source eller ej, det vigtige er blot, at alle er enige om de forskellige interfaces, når programmerne kalder hinanden. Disse interfaces vil selvfølgelig også udvikle sig over tid, som i så mange andre softwareprodukter.

Illustration: Thomas Jam Pedersen

Tegningen ovenfor viser de 5 helt basale programmer i første alphaversion og deres interfaces:

  • Waste Burner Emulator
  • Copenhagen Atomics Waste Burner Control software
  • Very Secure Operating System
  • Read Controller
  • Graphical Representation of Reactor State

Den eneste, jeg endnu ikke har omtalt, er den grafiske repræsentation af reaktorens state. Som mennesker vil vi jo gerne have nogle grafer og tal, som beskriver, hvordan reaktoren har det. Det ville også være fint med en grafisk tegning, som viser væskestanden i tungtvandstanken og fuel salt i dumptank og væskestanden foran fuel salt-pumpen, etc.

Jeg ønsker at lave en simpel grafik til den første alphaversion, hvor jeg blot laver følgende tegning, så man kan se over tid, hvordan væsken stiger op i de forskellige rør og tanke samt indikatorer, som viser temperatur og tryk i de forskellige målepunkter.

Illustration: Thomas Jem Pedersen

Den første version af VSOS bliver ikke en rigtig version, men bliver blot en muckup som gør det muligt at teste den øvrige del af systemet. Vi har overvejet at udlade den, men hvis vi skal være mange om at udvikle dette, så tror jeg, at det er vigtigt at få en simpel version af de forskellige komponenter på plads fra starten. Jeg tror, at det gør det meget lettere at få en konstruktiv debat om systemet og dets udvikling.

Personligt glæder jeg mig rigtig meget til det tidspunkt, hvor vi har implementeret et antal forskellige WBE- komponenter og nemt kan teste dem af op imod forskellige test-case-scenarier og se de forskellige outputs. Især ser jeg frem til at deltage i den dialog, som vil opstå imellem udviklerne og fysikerne på baggrund af disse tests. Vi er også ved at planlægge et større risk-analysis-review af vores præliminære reaktordesign, og jeg forventer mig et antal spændende aha oplevelser i den forbindelse. Skriv gerne i kommentarerne nedenfor, hvad du synes kunne være spændende at høre om i de næste blog indlæg.

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

Ud fra din beskrivelse er det svært for mig at forstå hvad der er kontrol og hvad der er simulator.
F.eks. er din statevektor af isotoper genereret ud fra et instrument, eller ud fra en observer der ud fra anlægets drifts historie udregner mængden af de forskellige isotoper.
Hvordan er reparations filosofien ? Kan elektrisk udstyr som sensorere og akturatore udskiftes, eller skal de virke i hele systemets levetid ?

Når systemet skal implementeres rigtigt kunne tænke mig at se et kontrol hierarki/funktions træ.
Dette kontrol hierarki skal implementere hvordan den øverste kontrol state, giver kommandoer som ripler ned gennem de forskellige kontrol lag, og hvordan (fejl) tilstande går den anden vej op gennem systemet.
Topologien af dette kontrol hierarki/funktions træ afhænger af hvad der skal styre underliggende funktioner, og hvad disse underliggende funktioner afhænger af.

  • 0
  • 0

Jeres simulering er et nyttigt og nødvendigt værktøj, men... digitaliserede systemer er ekstremt svære at få godkendt til reaktorbrug. Den opgave er ikke indenfor rækkevide for en amatørforening der roder med eksperimentelle reaktordesigns. Har I overvejet at købe et af de godkendte produkter på markedet?

  • 0
  • 0

Måske skulle i overveje at bygge jeres simuleringsmodel i Modelica sproget, og simulere det i Dymola eller tilsvarende. Til hverdag arbejder jeg med modellering og kontrol af komplekse termodynamiske systemer, og her synes jeg Dymola har vist sig at være den bedste måde at få et realistisk simuleret system af nærmest arbitrær orden. Hvis man implementerer direkte i kode, så går det hurtigt i starten, men det begynder at blive som at vade i sirup til sidst. Det er nemlig svært at bevare fleksibiliteten når det hele bliver mere og mere komplekst. Man bliver hele tiden klogere når man bygger sådan en model, og det er 100% sikkert at modellen skal ændres. Det er forholdsmæssigt besværligt i kode, men ikke i Modelica. Dernæst ligger der et problem i at i sikkert skal beskrive fysiske processer med meget forskellige tidskonstanter, som interagerer. Der er sikkert diskontinuiteter og events alle mulige steder, og de vil give jer grå hår - jeg garanterer. Det kræver altså en ordenlig solver at løse sådan noget. Hvis det endelig lykkes jer at løse det hvor diverse masse balancer er overholdt på trods af "læk" pga. numeriske fejl, så vil det være svært at overskue om i rent faktisk har implementeret modellen rigtigt. Hvordan vurderer man f.eks. om en eller anden transient ikke er påvirket af diskretisereingen? Det kan man godt i et 3-4 ordens LTI model. Men hvad med en 1000 ordens PDE?

Det integrerer fint med simulink, hvor Dymola modellen blot er en black box komponent. Konceptet går ud på at man beskriver hver komponent i sit system med et sæt partielle differentialligninger. Man kan så forbinde komponenterne, og så regner programmet det samlede sæt ligninger for hele systemet ud, og foretager nogle meget markante forsimplinger. Det minder en anelse om Simulink, men der er en markant forskel. Simulink (og jeres kode) tager hver komponents input og regner et output, som så er input til næste komponent. Problemet er når det bliver cirkulært, og det bliver det. Det kan Dymola håndtere. Hverken Dymola eller Simulink er jo gratis - mildest talt - men der findes open source alternativer til begge.

Jeg foreslår derfor at jeres WBE er en kombiation af Dymola og Simulink. Dymola til det rent fysiske, og Simulink til low level control, og så måske et eller anden form for link til jeres software. Min vurdering er, at hvis man startede to teams, hvor det ene går i gang med at lave modellen i software, og det andet går i gang med Dymola, så vil software teamet været hurtigst i starten, men Dymola holdet vil komme forbi med et overlydsbrag efter ca 1 måned, og software holdet vil have mistet gejsten totalt når et eller andet skal ændres, og dymola holdet gør det på 2 minutter.

Anyway - food for thought.

  • 0
  • 0

Jeg er lidt i tvivl. Er Copenhagen Atomics og Seaborg Technologies to forkellige firmaer/grupper af personer?

Har vi to organisationer af personer i DK der arbejder på netop det samme, nemlig at lave en Molten salt reactor der kan bruge atomaffald som brændsel?

  • 0
  • 0