Auto sync: 2025-09-22 15:48:10 (10 files changed)

M  Writing/ERLM/main.aux

M  Writing/ERLM/main.fdb_latexmk

M  Writing/ERLM/main.fls

M  Writing/ERLM/main.log

M  Writing/ERLM/main.pdf

M  Writing/ERLM/main.synctex.gz

M  Writing/ERLM/main.tex

M  Writing/ERLM/research-approach/v1.tex

Writing/ERLM/main.aux

@@ -1,23 +1,24 @@
 \relax 
 \bibstyle{unsrt}
 \providecommand \oddpage@label [2]{}
-\@writefile{toc}{\contentsline {section}{\numberline {1}Goals and Outcomes}{2}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {1}Goals and Outcomes}{1}{}\protected@file@percent }
 \citation{geromel2006stability}
 \citation{branicky1998multiple,liberzon2003switching}
 \citation{mitchell2005time}
-\@writefile{toc}{\contentsline {section}{\numberline {2}State of the Art and Limits of Current Practice}{4}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2}State of the Art and Limits of Current Practice}{3}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Control Theory and Hybrid Systems}{4}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Control Theory and Hybrid Systems}{3}{}\protected@file@percent }
 \citation{yang2024learning}
 \citation{alur1993hybrid}
 \citation{alur1995algorithmic}
 \citation{giannakopoulou2022fret}
 \citation{meyer2018strix,jacobs2017syntcomp}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Formal Methods and Reactive Synthesis}{5}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Formal Methods and Reactive Synthesis}{4}{}\protected@file@percent }
 \citation{platzer2008differential,platzer2017complete}
 \citation{fulton2015keymaera}
-\@writefile{toc}{\contentsline {section}{\numberline {3}Research Approach}{7}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3}Research Approach}{6}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}\((Procedures \wedge FRET) \rightarrow Temporal Specifications\)}{7}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Requirements: $(Procedures \wedge FRET) \rightarrow Temporal Specifications$}{6}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}\((TemporalLogic \wedge ReactiveSynthesis) \rightarrow DiscreteAutomata\) }{8}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Discrete Synthesis: $(TemporalLogic \wedge ReactiveSynthesis) \rightarrow DiscreteAutomata$}{7}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}$(DiscreteAutomata \wedge ControlTheory \wedge Reachability) \rightarrow ContinuousModes$}{7}{}\protected@file@percent }
 \bibdata{references}
 \bibcite{geromel2006stability}{1}
 \bibcite{branicky1998multiple}{2}
@@ -32,5 +33,5 @@
 \bibcite{platzer2008differential}{11}
 \bibcite{platzer2017complete}{12}
 \bibcite{fulton2015keymaera}{13}
-\@writefile{toc}{\contentsline {section}{References}{9}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{References}{10}{}\protected@file@percent }
-\gdef \@abspage@last{10}
+\gdef \@abspage@last{11}

Writing/ERLM/main.fdb_latexmk

@@ -1,13 +1,13 @@
 # Fdb version 4
-["bibtex main"] 1758312160.31587 "main.aux" "main.bbl" "main" 1758314275.44164 0
+["bibtex main"] 1758557112.56091 "main.aux" "main.bbl" "main" 1758557140.32895 0
   "./references.bib" 1757962977.69814 9415 fb740c67337f78e30e95f745a7cf3dae ""
   "/usr/share/texlive/texmf-dist/bibtex/bst/base/unsrt.bst" 1292289607 18030 1376b4b231b50c66211e47e42eda2875 ""
-  "main.aux" 1758314275.3067 1906 b2985f48fe3452882877d4466e7ee0d0 "pdflatex"
+  "main.aux" 1758557140.19536 2118 a57066142aea7c36ef70d6820a019284 "pdflatex"
   (generated)
   "main.bbl"
   "main.blg"
   (rewritten before read)
-["pdflatex"] 1758314274.62168 "main.tex" "main.pdf" "main" 1758314275.44186 0
+["pdflatex"] 1758557139.47267 "main.tex" "main.pdf" "main" 1758557140.32921 0
   "/etc/texmf/web2c/texmf.cnf" 1722610814.59577 475 c0e671620eb5563b2130f56340a5fde8 ""
   "/usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc" 1165713224 4850 80dc9bab7f31fb78a000ccfed0e27cab ""
   "/usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map" 1577235249 3524 cb3e574dea2d1052e39280babc910dc8 ""
@@ -235,11 +235,10 @@
   "/var/lib/texmf/web2c/pdftex/pdflatex.fmt" 1726005817 6800784 2b63e5a224c5ad740802d8f9921962c1 ""
   "dane_proposal_format.cls" 1757904657.11823 2553 3bbf169a90a50515ed103fe388c111f0 ""
   "goals-and-outcomes/v4.tex" 1757896122.20856 5764 a67e489f9ea8343564010d217ae37ec2 ""
-  "main.aux" 1758314275.3067 1906 b2985f48fe3452882877d4466e7ee0d0 "pdflatex"
+  "main.aux" 1758557140.19536 2118 a57066142aea7c36ef70d6820a019284 "pdflatex"
-  "main.bbl" 1758312160.33144 3170 7f578afdcd1e73f308616474dc5a4003 "bibtex main"
+  "main.bbl" 1758557112.57993 3170 7f578afdcd1e73f308616474dc5a4003 "bibtex main"
-  "main.tex" 1758141512.11022 266 5fc203b73100922882e1cd826c363466 ""
+  "main.tex" 1758556517.96287 224 bb88520482f757f8a407a04cda51ec23 ""
-  "research-approach/v1.tex" 1758314274.50071 5266 252283504e899e4cb4e770ecfcd29e42 ""
+  "research-approach/v2.tex" 1758557109.9037 13747 97ad683c7942f87218a074a6187782d1 ""
-  "sabo-quad-chart.pdf" 1757962977.69814 133742 e107b1b92665ad28257256b818191f52 ""
   "state-of-the-art/v2.tex" 1757962977.69875 10918 a65147e24336b6a318bf18223339313e ""
   (generated)
   "main.aux"

Writing/ERLM/main.fls

@@ -401,19 +401,6 @@ INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/times/ptmr7t.vf
 INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
 INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/times/ptmr7t.vf
 INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
-INPUT ./sabo-quad-chart.pdf
 INPUT ./goals-and-outcomes/v4.tex
 INPUT ./goals-and-outcomes/v4.tex
 INPUT ./goals-and-outcomes/v4.tex
@@ -475,11 +462,11 @@ INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ts1ptm.fd
 INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ts1ptm.fd
 INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/times/ptmr8c.tfm
 INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/times/ptmr8c.vf
-INPUT ./research-approach/v1.tex
+INPUT ./research-approach/v2.tex
-INPUT ./research-approach/v1.tex
+INPUT ./research-approach/v2.tex
-INPUT ./research-approach/v1.tex
+INPUT ./research-approach/v2.tex
-INPUT ./research-approach/v1.tex
+INPUT ./research-approach/v2.tex
-INPUT research-approach/v1.tex
+INPUT research-approach/v2.tex
 INPUT ./main.bbl
 INPUT ./main.bbl
 INPUT main.bbl

Writing/ERLM/main.log

@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex 2024.9.10)  19 SEP 2025 16:37
+This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex 2024.9.10)  22 SEP 2025 12:05
 entering extended mode
  restricted \write18 enabled.
  file:line:error style messages enabled.
@@ -876,85 +876,41 @@ LaTeX Font Info:    Font shape `OT1/ptm/bx/n' in size <8> not available
 (Font)              Font shape `OT1/ptm/b/n' tried instead on input line 5.
  [1
 
-{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc}]
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc}] (./goals-and-outcomes/v4.tex [1]) [2] (./state-of-the-art/v2.tex
-
-pdfTeX warning: pdflatex (file ./sabo-quad-chart.pdf): PDF inclusion: found PDF version <1.7>, but at most version <1.5> allowed
-<sabo-quad-chart.pdf, id=34, 722.7pt x 542.025pt>
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf>
-Package pdftex.def Info: sabo-quad-chart.pdf  used on input line 6.
-(pdftex.def)             Requested size: 722.69823pt x 542.02367pt.
-
-
-pdfTeX warning: pdflatex (file ./sabo-quad-chart.pdf): PDF inclusion: found PDF version <1.7>, but at most version <1.5> allowed
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf>
-Package pdftex.def Info: sabo-quad-chart.pdf  used on input line 6.
-(pdftex.def)             Requested size: 722.69823pt x 542.02367pt.
-
-
-pdfTeX warning: pdflatex (file ./sabo-quad-chart.pdf): PDF inclusion: found PDF version <1.7>, but at most version <1.5> allowed
-
-
-pdfTeX warning: pdflatex (file ./sabo-quad-chart.pdf): PDF inclusion: found PDF version <1.7>, but at most version <1.5> allowed
-<sabo-quad-chart.pdf, id=37, page=1, 722.7pt x 542.025pt>
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf, page 1>
-Package pdftex.def Info: sabo-quad-chart.pdf , page1 used on input line 6.
-(pdftex.def)             Requested size: 722.69823pt x 542.02367pt.
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf, page 1>
-Package pdftex.def Info: sabo-quad-chart.pdf , page1 used on input line 6.
-(pdftex.def)             Requested size: 614.88235pt x 461.16176pt.
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf, page 1>
-Package pdftex.def Info: sabo-quad-chart.pdf , page1 used on input line 6.
-(pdftex.def)             Requested size: 614.88235pt x 461.16176pt.
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf, page 1>
-Package pdftex.def Info: sabo-quad-chart.pdf , page1 used on input line 6.
-(pdftex.def)             Requested size: 614.88235pt x 461.16176pt.
-File: sabo-quad-chart.pdf Graphic file (type pdf)
-<use sabo-quad-chart.pdf, page 1>
-Package pdftex.def Info: sabo-quad-chart.pdf , page1 used on input line 6.
-(pdftex.def)             Requested size: 614.88235pt x 461.16176pt.
-[1
-
- <./sabo-quad-chart.pdf>] (./goals-and-outcomes/v4.tex [2]) [3] (./state-of-the-art/v2.tex
 LaTeX Font Info:    Font shape `OT1/ptm/bx/n' in size <12> not available
 (Font)              Font shape `OT1/ptm/b/n' tried instead on input line 15.
 LaTeX Font Info:    Font shape `OT1/ptm/bx/n' in size <9> not available
 (Font)              Font shape `OT1/ptm/b/n' tried instead on input line 15.
 LaTeX Font Info:    Font shape `OT1/ptm/bx/n' in size <7> not available
 (Font)              Font shape `OT1/ptm/b/n' tried instead on input line 15.
- [4] [5]
+ [3] [4]
 LaTeX Font Info:    Trying to load font information for TS1+ptm on input line 168.
  (/usr/share/texlive/texmf-dist/tex/latex/psnfss/ts1ptm.fd
 File: ts1ptm.fd 2001/06/04 font definitions for TS1/ptm.
-)) [6] (./research-approach/v1.tex
+)) [5] (./research-approach/v2.tex
-Overfull \hbox (2.08794pt too wide) in paragraph at lines 49--63
+Overfull \hbox (1.34416pt too wide) in paragraph at lines 44--48
-[]\OT1/ptm/m/n/12 FRET pro-vides func-tion-al-ity to check the \OT1/ptm/m/it/12 re-al-iz-abil-ity \OT1/ptm/m/n/12 of a sys-tem. Re-al-iz-abil-ity checks whether
+[]\OT1/ptm/m/n/12 FRET em-ploys a spe-cial-ized re-quire-ments lan-guage sim-i-lar to nat-u-ral lan-guage called FRETish.
  []
 
-[7]) [8] (./main.bbl) [9] (./main.aux)
+[6] [7]) [8] [9] (./main.bbl) [10] (./main.aux)
  ***********
 LaTeX2e <2023-11-01> patch level 1
 L3 programming layer <2024-01-22>
  ***********
  ) 
 Here is how much of TeX's memory you used:
- 25430 strings out of 476182
+ 25417 strings out of 476182
- 528320 string characters out of 5795595
+ 527946 string characters out of 5795595
  1934975 words of memory out of 5000000
- 46875 multiletter control sequences out of 15000+600000
+ 46863 multiletter control sequences out of 15000+600000
  590786 words of font info for 108 fonts, out of 8000000 for 9000
  14 hyphenation exceptions out of 8191
- 110i,17n,107p,1008b,531s stack positions out of 10000i,1000n,20000p,200000b,200000s
+ 110i,9n,107p,1008b,285s stack positions out of 10000i,1000n,20000p,200000b,200000s
 </usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmss12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/symbol/usyr.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/times/utmb8a.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/times/utmri8a.pfb>
-Output written on main.pdf (10 pages, 238007 bytes).
+Output written on main.pdf (11 pages, 119324 bytes).
 PDF statistics:
- 134 PDF objects out of 1000 (max. 8388607)
+ 108 PDF objects out of 1000 (max. 8388607)
- 79 compressed objects within 1 object stream
+ 62 compressed objects within 1 object stream
  0 named destinations out of 1000 (max. 500000)
- 129 words of extra memory for PDF output out of 10000 (max. 10000000)
+ 109 words of extra memory for PDF output out of 10000 (max. 10000000)
 

Writing/ERLM/main.tex

@@ -3,13 +3,11 @@
 \begin{document}
 
 \maketitle
-\includepdf{sabo-quad-chart.pdf}
-\newpage
 \input{goals-and-outcomes/v4}
 \newpage
 \input{state-of-the-art/v2}
 \newpage
-\input{research-approach/v1}
+\input{research-approach/v2}
 
 \newpage
 \bibliography{references}

Writing/ERLM/research-approach/v1.tex

@@ -81,23 +81,116 @@ advance hybrid system autonomy.
 Reactive synthesis is an active field in computer science that focuses on the
 synthesis of discrete controllers created from temporal logic specifications.
 Reactive defines that the system responds to inputs to create outputs. These
-systems are finite in size, where each node represents a unique set of discrete
+systems are finite in size, where each node represents a unique discrete state.
-states \(q\). 
+The connections between nodes are called \textit{state transitions}, and
+describe under what conditions the discrete controller moves from state to
+state. This mapping of all the possible states and transitions for the discrete
+controller is known as a discrete automata. From a graph of the automata, it
+is possible to completely describe the dynamics of a finite discrete system and
+develop an intuitive understanding of how the system will behave. Once the
+automata is constructed, it is straight forward to implement in a text-based
+programming language using basic control flow tools.
 
-% what does it mean to be a single discrete state
+We will use discrete automata to represent the switching behavior of our hybrid
-% what do the transitions mean
+system. From this automata we can extract an important proof. Because this
-% How're we going to use reactive synthesis to do this for us
+discrete automata has been synthesized entirely through automated tools from
-% what are some state of the art tools to use
+design requirements and operating procedures, we can prove that the discrete
-% What's the output
+automata, and therein our hybrid switching behavior, is correct by construction.
-% Explain how the transitions are the edges in the state space, and we're
+Correctness of the switching controller is paramount to this work. The switching
-% basically creating hybrid automata without actually specifying the dynamics
+between continuous modes is the primary responsibility of human operators in
-% underneath
+control rooms today. Human operators have the benefit of judgement--if a human
-% we're going to figure out the continuous dynamics in the next section. Then,
+operator makes a mistake, they are able to correct for it in real time with
-% for the continuous section, basically talk about how now that we have the
+fidelity beyond operating procedures. Autonomous control will not have this
-% discrete modes, we just need to build controllers that satisfy all the
+advantage. Instead, we must ensure that an autonomous controller replacing a
-% transitions and operational goals for each mode. We've broken up the control
+human operator will not make mistakes when switching between continuous modes.
-% system into several smaller pieces that are more manageable. Include how
+By synthesizing these controllers from logical specifications with assurance of
-% reachability becomes a part of that. What does it mean to have input and
+their correctness, we guarantee they will not err.
-% output guarantees based on the allowable transitions?
 
-%write tasks in here maybe. Or the main thrusts.
+\subsection{\((DiscreteAutomata \wedge ControlTheory \wedge Reachability)
+\rightarrow ContinuousModes\)}
+
+While the discrete components of our system will be synthesized with assurance
+of correctness, that is only half of the story. Autonomous controllers like the
+ones we are building have continuous dynamics underneath the discrete states. In
+this section, we describe how we will build out the continuous control modes,
+will verify their correctness, and the unique challenges of hybrid systems that
+we will overcome with this work.
+
+First and foremost, lets discuss the glaring problem left unaddressed in the last
+section. From the requirements and specifications, we described a way to produce
+discrete automata. These automata are physics agnostic, and are only half of
+the picture of a hybrid autonomous controller. They alone do not define the
+complete behavior of the control systems that we are trying to build. The
+continuous modes of the controller will be developed after the discrete automata
+is produced, as we are going to lever the structure of the automata and it's
+transitions to build out several smaller continuous controllers. 
+
+The transitions of the discrete automata are the key to the supervisory behavior
+of the autonomous controller. These transitions mark decision points to switch
+between continuous control modes, and their strategic objectives. We will define
+three types of high-level continuous controller goals based on the transitions
+between discrete modes:
+
+\begin{enumerate}
+  \item \textbf{Stabilizing:} A stabilizing control mode in our hybrid system is
+    a continuous control mode with one primary objective. It issues continuous
+    control inputs keep the hybrid system in the current mode. This is analogous
+    to an steady-state normal operating mode, such as full power load following
+    conrtoller in a nuclear power plant. Stabilizing modes can be identified
+    from discrete automata as nodes that only have transitions pointing towards
+    them. 
+    
+  \item \textbf{Transitory:} A transitory control mode is a continuous mode with
+    a primary goal of transitioning the hybrid system from one discrete state to
+    another. In a nuclear context, this can represent a continuous mode such as
+    a controlled warm-up procedure. The transitory mode ultimately wants to move
+    the control system to a stabilizing steady-state mode. Transitory modes may
+    have secondary control goals within one discrete state, such as maintaining a
+    specific rate of temperature increase before reaching full-power operation. 
+
+  \item \textbf{Expulsory:} An expulsory mode is a type of transitory mode that
+    has special restrictions. Expulsory modes are continuous control modes that
+    are designed to ensure the system is directed to a safe stabilizing mode in
+    case of a failure. For example, if a transitory mode fails to deliver the
+    system to the correct next mode, the expulsory mode is designed to be
+    activated and immediately and irrevocably steward the system towards a
+    globally safe state. A straightforward example of an expulsory continuous
+    mode is a reactor SCRAM. At any point that a SCRAM is initiated, it should
+    be possible to kill the reaction and direct the reactor towards a
+    stabilizing decay heat removal mode.
+
+\end{enumerate}
+
+The benefit of building continuous modes after constructing the discrete
+automata is that we can build local controllers to satisfy the discrete
+transitions. The most common problems when verifying hybrid systems is the
+challenge of assuring global stability conditions over transitions. Current
+techniques make this a difficult problem because discontinuities in the dynamics
+are not conducive to easy verification. This work helps alieviate these problems
+by specifically building continuous controllers with the transitions in mind. By
+breaking down continuous modes into their required behavior at the transition
+points, we do not need to solve trajectories through the entire hybrid system,
+but instead can use information about the local behavior of continuous modes at
+the transition barrier. 
+
+To ensure that continuous modes satisfy their requirements, we will use three
+main techniques: reachability analysis, assume-guarantee contracts, and barrier
+certificates. Reachability analysis is used to obtain the reachable set of
+states for a given input set of states for a system. For linear continous
+systems, reachability is trivial, but recent advances have expanded reachability
+to complex nonlinear systems. We will use reachability to define the continuous
+range of states at discrete transition barriers, or when a range of continuous
+states is prescribed by a requirement, ensure that the requirement is satisfied
+for the continuous mode. We will use assume-guarantee contracts for when
+continuous states borders are not defined. Essentially, this means that for a
+given mode, the input range to use with reachability is defined by the output
+ranges of the discrete modes that transition to it. This ensures that each
+continuous controller is prepared for the possible input range it may receive,
+and that reachability analysis can then be used. Finally, we will use barrier
+certificates to prove that transitions between modes are satisfied. Barrier
+certificates ensure that along a transition the continuous modes on either side
+do not behave adversely. For example, a barrier certificate can ensure that a
+transitory mode handing off to a stabilizing mode will always move away from the
+transition border, rather than leave the stabilizing mode. Combining these three
+techniques will allow us to prove the continuous components of our hybrid
+controller satisfy the discrete requirements.

Writing/ERLM/research-approach/v2.tex

@@ -0,0 +1,239 @@
+\section{Research Approach}
+
+This research will overcome the limitations of current practice to build 
+high-assurance hybrid control systems for critical infrastructure. To achieve 
+this goal, we must accomplish three main thrusts:
+
+\begin{enumerate}
+  \item Translate operating procedures and requirements into temporal logic
+    formulae
+    
+  \item Create the discrete half of a hybrid controller using reactive synthesis
+
+  \item Develop continuous controllers to operate between modes, and verify
+    their correctness using reachability analysis, barrier certificates, and
+    assume-guarantee contracts
+
+\end{enumerate}
+
+The following sections discuss how these thrusts will be accomplished.
+
+\subsection{Requirements: $(Procedures \wedge FRET) \rightarrow Temporal Specifications$}
+
+% COMMENT: Consider strengthening this opening with specific examples or 
+% statistics about nuclear plant automation levels vs other industries
+
+The motivation behind this work stems from the fact that commercial nuclear 
+power operations remain manually controlled by human operators, despite 
+significant advances in control systems sophistication. The key insight is that 
+procedures performed by human operators are highly prescriptive and 
+well-documented. This suggests that human operators in nuclear power plants 
+may not be entirely necessary given today's available technology.
+
+Written procedures and requirements in nuclear power are sufficiently detailed 
+that we may be able to translate them into logical formulae with minimal 
+effort. If successful, this approach would enable automation of existing 
+procedures without requiring system reengineering—a significant advantage for 
+deployment in existing facilities. The most efficient path to accomplish this 
+translation is through automated tools such as NASA's Formal Requirement
+Elicitation Tool (FRET).
+
+% COMMENT: Consider adding a brief example of a nuclear procedure that would 
+% benefit from this approach
+
+FRET employs a specialized requirements language similar to natural language
+called FRETish. FRETish restricts requirements to easily understood components
+while eliminating ambiguity. FRET enforces this structure by requiring all
+requirements to contain six components: %CITE FRET MANUAL
+
+\begin{enumerate}
+  \item Scope: \textit{What modes does this requirement apply to?}
+  \item Condition: \textit{Scope plus additional specificity}
+  \item Component: \textit{What system element does this requirement affect?}
+  \item Shall
+  \item Timing: \textit{When does the response occur?}
+  \item Response: \textit{What action should be taken?}
+\end{enumerate}
+
+% COMMENT: The realizability discussion could be clearer - consider defining
+% "realizable" more precisely upfront
+
+FRET provides functionality to check the \textit{realizability} of a system. 
+Realizability analysis determines whether written requirements are complete by 
+examining the six structural components. Complete requirements are those that 
+neither conflict with one another nor leave any behavior undefined. Systems 
+that are not realizable from their procedure definitions and design 
+requirements present problems beyond autonomous control implementation. Such 
+systems contain behavioral inconsistencies that represent the physical 
+equivalent of software bugs. Using FRET during autonomous controller 
+development allows us to identify and resolve these errors systematically.
+
+The second category of realizability issues involves undefined behaviors that 
+are typically left to human judgment during control operations. This 
+ambiguity is undesirable for high-assurance systems, since even well-trained 
+humans remain prone to errors. By addressing these specification gaps in FRET 
+during autonomous controller development, we can deliver controllers free from 
+these vulnerabilities.
+
+% COMMENT: This transition could be smoother - consider adding a sentence about
+% how the temporal logic output connects to the next section
+
+FRET also provides the capability to export requirements in temporal logic 
+format. This export functionality enables progression to the next step of our 
+approach: synthesizing discrete mode switching behavior from the formalized 
+requirements.
+
+\subsection{Discrete Synthesis: $(TemporalLogic \wedge ReactiveSynthesis) \rightarrow 
+DiscreteAutomata$}
+
+This section describes how the discrete component of the hybrid system will be 
+constructed. The formal specifications created in FRET will be processed by 
+reactive synthesis tools to generate mode switching components. These 
+components effectively automate the human decision-making elements of reactor 
+operation by implementing the logic typically specified in written procedures. 
+By eliminating the human component from control decisions, we remove the 
+possibility of human error and advance hybrid system autonomy.
+
+Reactive synthesis is an active research field in computer science focused on 
+generating discrete controllers from temporal logic specifications. The term 
+"reactive" indicates that the system responds to environmental inputs to 
+produce control outputs. These synthesized systems are finite in size, where 
+each node represents a unique discrete state. The connections between nodes, 
+called \textit{state transitions}, specify the conditions under which the 
+discrete controller moves from state to state. This complete mapping of 
+possible states and transitions constitutes a \textit{discrete automaton}. 
+From the automaton graph, it becomes possible to fully describe the dynamics 
+of the discrete system and develop intuitive understanding of system behavior. 
+Once constructed, the automaton can be straightforwardly implemented using 
+standard programming control flow constructs.
+
+% COMMENT: The "correct by construction" concept is important - consider 
+% expanding this explanation slightly
+
+We will use discrete automata to represent the switching behavior of our hybrid 
+system. This approach yields an important theoretical guarantee: because the 
+discrete automaton is synthesized entirely through automated tools from design 
+requirements and operating procedures, we can prove that the automaton—and 
+therefore our hybrid switching behavior—is correct by construction. 
+
+Correctness of the switching controller is paramount to this work. Mode 
+switching represents the primary responsibility of human operators in control 
+rooms today. Human operators possess the advantage of real-time judgment—when 
+mistakes occur, they can correct them dynamically with capabilities that 
+extend beyond written procedures. Autonomous control lacks this adaptive 
+advantage. Instead, we must ensure that autonomous controllers replacing human 
+operators will not make switching errors between continuous modes. By 
+synthesizing controllers from logical specifications with guaranteed 
+correctness, we eliminate the possibility of switching errors.
+
+\subsection{$(DiscreteAutomata \wedge ControlTheory \wedge Reachability) 
+\rightarrow ContinuousModes$}
+
+While discrete system components will be synthesized with correctness 
+guarantees, they represent only half of the complete system. Autonomous 
+controllers like those we are developing exhibit continuous dynamics within 
+discrete states. This section describes how we will develop continuous control 
+modes, verify their correctness, and address the unique verification 
+challenges of hybrid systems.
+
+% COMMENT: This "glaring problem" phrasing is a bit dramatic - consider toning
+% down while maintaining the technical point
+
+First, we must address the limitation left unresolved in the previous section. 
+The approach described for producing discrete automata yields physics-agnostic 
+specifications that represent only half of a complete hybrid autonomous 
+controller. These automata alone cannot define the full behavior of the 
+control systems we aim to construct. The continuous modes will be developed 
+after discrete automaton construction, leveraging the automaton structure and 
+transitions to design multiple smaller, specialized continuous controllers.
+
+The discrete automaton transitions are key to the supervisory behavior of the 
+autonomous controller. These transitions mark decision points for switching 
+between continuous control modes and define their strategic objectives. We 
+will classify three types of high-level continuous controller objectives based 
+on discrete mode transitions:
+
+\begin{enumerate}
+  \item \textbf{Stabilizing:} A stabilizing control mode has one primary 
+    objective: maintaining the hybrid system within its current discrete mode. 
+    This corresponds to steady-state normal operating modes, such as a 
+    full-power load-following controller in a nuclear power plant. Stabilizing 
+    modes can be identified from discrete automata as nodes with only incoming 
+    transitions.
+    
+  \item \textbf{Transitory:} A transitory control mode has the primary goal of 
+    transitioning the hybrid system from one discrete state to another. In 
+    nuclear applications, this might represent a controlled warm-up procedure. 
+    Transitory modes ultimately drive the system toward a stabilizing 
+    steady-state mode. These modes may have secondary objectives within a 
+    discrete state, such as maintaining specific temperature ramp rates before 
+    reaching full-power operation.
+
+  \item \textbf{Expulsory:} An expulsory mode is a specialized transitory mode 
+    with additional safety constraints. Expulsory modes ensure the system is 
+    directed to a safe stabilizing mode during failure conditions. For example, 
+    if a transitory mode fails to achieve its intended transition, the 
+    expulsory mode activates to immediately and irreversibly guide the system 
+    toward a globally safe state. A reactor SCRAM exemplifies an expulsory 
+    continuous mode: when initiated, it must reliably terminate the nuclear 
+    reaction and direct the reactor toward stabilizing decay heat removal.
+
+\end{enumerate}
+
+% COMMENT: This paragraph has some word choice issues ("alieviate" -> 
+% "alleviate") - fixed in revision
+
+Building continuous modes after constructing discrete automata enables local 
+controller design focused on satisfying discrete transitions. The primary 
+challenge in hybrid system verification is ensuring global stability across 
+transitions. Current techniques struggle with this problem because dynamic 
+discontinuities complicate verification. This work alleviates these problems 
+by designing continuous controllers specifically with transitions in mind. By 
+decomposing continuous modes according to their required behavior at 
+transition points, we avoid solving trajectories through the entire hybrid 
+system. Instead, we can use local behavior information at transition 
+boundaries.
+
+To ensure continuous modes satisfy their requirements, we will employ three 
+main techniques: reachability analysis, assume-guarantee contracts, and 
+barrier certificates. Reachability analysis computes the reachable set of 
+states for a given input set. While trivial for linear continuous systems, 
+recent advances have extended reachability to complex nonlinear systems. We 
+will use reachability to define continuous state ranges at discrete transition 
+boundaries and verify that requirements are satisfied within continuous modes. 
+Assume-guarantee contracts will be employed when continuous state boundaries 
+are not explicitly defined. For any given mode, the input range for 
+reachability analysis is defined by the output ranges of discrete modes that 
+transition to it. This ensures each continuous controller is prepared for its 
+possible input range, enabling subsequent reachability analysis. Finally, we 
+will use barrier certificates to prove that mode transitions are satisfied. 
+Barrier certificates ensure that continuous modes on either side of a 
+transition behave appropriately. For example, a barrier certificate can 
+guarantee that a transitory mode transferring control to a stabilizing mode 
+will always move away from the transition boundary, rather than destabilizing 
+the target mode. Combining these three techniques will enable us to prove that 
+continuous components of our hybrid controller satisfy discrete requirements.
+
+% COMMENTS FOR FUTURE REVISION:
+% 1. Add concrete examples throughout (specific nuclear procedures, requirements)
+% 2. Include a figure showing the overall workflow/methodology
+% 3. Consider adding a subsection on validation approach
+% 4. Strengthen the connections between subsections
+% 5. Add discussion of limitations and assumptions
+% 6. Consider reorganizing the continuous modes classification earlier
+
+This unified approach addresses a fundamental gap in hybrid system design by 
+bridging formal methods and control theory through a systematic, tool-supported 
+methodology. By translating existing nuclear procedures into temporal logic, 
+synthesizing provably correct discrete switching logic, and developing 
+verified continuous controllers, we create a complete framework for 
+autonomous hybrid control with mathematical guarantees. The result is an 
+autonomous controller that not only replicates human operator decision-making 
+but does so with formal assurance that switching logic is correct by 
+construction and continuous behavior satisfies safety requirements. This 
+methodology transforms nuclear reactor control from a manually intensive 
+operation requiring constant human oversight into a fully autonomous system 
+with higher reliability than human-operated alternatives. More broadly, this 
+approach establishes a replicable framework for developing high-assurance 
+autonomous controllers in any domain where operating procedures are 
+well-documented and safety is paramount.