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
This commit is contained in:
parent
ba1de5f08a
commit
3521afad7f
@ -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 {subsection}{\numberline {2.1}Control Theory and Hybrid Systems}{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}{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 {subsection}{\numberline {3.1}\((Procedures \wedge FRET) \rightarrow Temporal Specifications\)}{7}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}\((TemporalLogic \wedge ReactiveSynthesis) \rightarrow DiscreteAutomata\) }{8}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {3}Research Approach}{6}{}\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}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 }
|
||||
\gdef \@abspage@last{10}
|
||||
\@writefile{toc}{\contentsline {section}{References}{10}{}\protected@file@percent }
|
||||
\gdef \@abspage@last{11}
|
||||
|
||||
@ -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.bbl" 1758312160.33144 3170 7f578afdcd1e73f308616474dc5a4003 "bibtex main"
|
||||
"main.tex" 1758141512.11022 266 5fc203b73100922882e1cd826c363466 ""
|
||||
"research-approach/v1.tex" 1758314274.50071 5266 252283504e899e4cb4e770ecfcd29e42 ""
|
||||
"sabo-quad-chart.pdf" 1757962977.69814 133742 e107b1b92665ad28257256b818191f52 ""
|
||||
"main.aux" 1758557140.19536 2118 a57066142aea7c36ef70d6820a019284 "pdflatex"
|
||||
"main.bbl" 1758557112.57993 3170 7f578afdcd1e73f308616474dc5a4003 "bibtex main"
|
||||
"main.tex" 1758556517.96287 224 bb88520482f757f8a407a04cda51ec23 ""
|
||||
"research-approach/v2.tex" 1758557109.9037 13747 97ad683c7942f87218a074a6187782d1 ""
|
||||
"state-of-the-art/v2.tex" 1757962977.69875 10918 a65147e24336b6a318bf18223339313e ""
|
||||
(generated)
|
||||
"main.aux"
|
||||
|
||||
@ -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/v1.tex
|
||||
INPUT ./research-approach/v1.tex
|
||||
INPUT ./research-approach/v1.tex
|
||||
INPUT research-approach/v1.tex
|
||||
INPUT ./research-approach/v2.tex
|
||||
INPUT ./research-approach/v2.tex
|
||||
INPUT ./research-approach/v2.tex
|
||||
INPUT ./research-approach/v2.tex
|
||||
INPUT research-approach/v2.tex
|
||||
INPUT ./main.bbl
|
||||
INPUT ./main.bbl
|
||||
INPUT main.bbl
|
||||
|
||||
@ -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}]
|
||||
|
||||
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
|
||||
{/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
|
||||
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
|
||||
Overfull \hbox (2.08794pt too wide) in paragraph at lines 49--63
|
||||
[]\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
|
||||
)) [5] (./research-approach/v2.tex
|
||||
Overfull \hbox (1.34416pt too wide) in paragraph at lines 44--48
|
||||
[]\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
|
||||
528320 string characters out of 5795595
|
||||
25417 strings out of 476182
|
||||
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)
|
||||
79 compressed objects within 1 object stream
|
||||
108 PDF objects out of 1000 (max. 8388607)
|
||||
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)
|
||||
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@ -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}
|
||||
|
||||
@ -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
|
||||
states \(q\).
|
||||
systems are finite in size, where each node represents a unique discrete state.
|
||||
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
|
||||
% what do the transitions mean
|
||||
% How're we going to use reactive synthesis to do this for us
|
||||
% what are some state of the art tools to use
|
||||
% What's the output
|
||||
% Explain how the transitions are the edges in the state space, and we're
|
||||
% basically creating hybrid automata without actually specifying the dynamics
|
||||
% underneath
|
||||
% we're going to figure out the continuous dynamics in the next section. Then,
|
||||
% for the continuous section, basically talk about how now that we have the
|
||||
% discrete modes, we just need to build controllers that satisfy all the
|
||||
% transitions and operational goals for each mode. We've broken up the control
|
||||
% system into several smaller pieces that are more manageable. Include how
|
||||
% reachability becomes a part of that. What does it mean to have input and
|
||||
% output guarantees based on the allowable transitions?
|
||||
We will use discrete automata to represent the switching behavior of our hybrid
|
||||
system. From this automata we can extract an important proof. Because this
|
||||
discrete automata has been synthesized entirely through automated tools from
|
||||
design requirements and operating procedures, we can prove that the discrete
|
||||
automata, and therein our hybrid switching behavior, is correct by construction.
|
||||
Correctness of the switching controller is paramount to this work. The switching
|
||||
between continuous modes is the primary responsibility of human operators in
|
||||
control rooms today. Human operators have the benefit of judgement--if a human
|
||||
operator makes a mistake, they are able to correct for it in real time with
|
||||
fidelity beyond operating procedures. Autonomous control will not have this
|
||||
advantage. Instead, we must ensure that an autonomous controller replacing a
|
||||
human operator will not make mistakes when switching between continuous modes.
|
||||
By synthesizing these controllers from logical specifications with assurance of
|
||||
their correctness, we guarantee they will not err.
|
||||
|
||||
%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.
|
||||
|
||||
239
Writing/ERLM/research-approach/v2.tex
Normal file
239
Writing/ERLM/research-approach/v2.tex
Normal file
@ -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.
|
||||
BIN
Writing/ERLM/sabo_research_approach.pdf
Normal file
BIN
Writing/ERLM/sabo_research_approach.pdf
Normal file
Binary file not shown.
Loading…
x
Reference in New Issue
Block a user