diff --git a/1-goals-and-outcomes/goals.tex b/1-goals-and-outcomes/goals.tex index b9c5500..e94d028 100644 --- a/1-goals-and-outcomes/goals.tex +++ b/1-goals-and-outcomes/goals.tex @@ -1,76 +1,53 @@ \section{Goals and Outcomes} -\dasinline{Research statement is very similar to GO -because that's what I had when I prepared it. -If it's going to be an executive summary, it -should talk more about the other sections rather -than just being a slightly different GO section.} % GOAL PARAGRAPH The goal of this research is to develop a methodology for creating autonomous hybrid control systems with mathematical guarantees of safe and correct -behavior.\splitnote{Clear thesis statement. Gets right to it.} +behavior. % INTRODUCTORY PARAGRAPH Hook Nuclear power plants require the highest levels of control system reliability, -where failures can result in significant economic losses, service -interruptions, or radiological -release.\splitnote{Stakes established immediately — good hook.} +where failures can result in significant economic losses, service interruptions, +or radiological release. % Known information -Currently, nuclear plant operations rely on extensively trained human -operators who follow detailed written procedures and strict regulatory -requirements to manage reactor control. These operators make critical -decisions about when to switch between different control modes based on their -interpretation of plant conditions and procedural guidance. +Currently, nuclear plant operations rely on extensively trained human operators +who follow detailed written procedures and strict regulatory requirements to +manage reactor control. These operators make critical decisions about when to +switch between different control modes based on their interpretation of plant +conditions and procedural guidance. % Gap -\oldt{This reliance on human operators prevents autonomous control -capabilities and creates a fundamental economic challenge for next-generation -reactor designs.} \newt{This reliance on human operators prevents autonomous -control and creates a fundamental economic barrier for next-generation -reactor designs.} Small modular reactors face per-megawatt staffing costs -far exceeding those of conventional plants, threatening their economic -viability. +This reliance on human operators prevents autonomous control and creates a +fundamental economic barrier for next-generation reactor designs. Small modular +reactors face per-megawatt staffing costs far exceeding those of conventional +plants, threatening their economic viability. % Critical Need -\oldt{What is needed is a method to create autonomous control systems that -safely manage complex operational sequences with the same assurance as -human-operated systems, but without constant human supervision.} -\newt{Autonomous control systems must safely manage complex operational -sequences with the same assurance as human-operated systems, but without -constant human supervision.} +What is needed is a method to create autonomous control systems that safely +manage complex operational sequences with the same assurance as human-operated +systems, but without constant human supervision. % APPROACH PARAGRAPH Solution To address this need, we will combine formal methods with control theory to build hybrid control systems that are correct by construction. % Rationale Hybrid systems use discrete logic to switch between continuous control modes, -mirroring how operators change control strategies. Existing formal methods -can generate provably correct switching logic from written requirements, but -they cannot handle the continuous dynamics that occur during transitions -between modes. Meanwhile, traditional control theory can verify continuous -behavior but lacks tools for proving correctness of discrete switching -decisions.\splitnote{Excellent setup of the gap — shows why neither approach -alone is sufficient.} +mirroring how operators change control strategies. Existing formal methods can +generate provably correct switching logic from written requirements, but they +cannot handle the continuous dynamics that occur during transitions between +modes. Meanwhile, traditional control theory can verify continuous behavior but +lacks tools for proving correctness of discrete switching decisions. % Hypothesis By synthesizing discrete mode transitions directly from written operating -procedures and verifying continuous behavior between transitions, we can -create hybrid control systems with end-to-end correctness guarantees. If -existing procedures can be formalized into logical specifications and -continuous dynamics verified against transition requirements, then autonomous -controllers can be built that are provably free from design -defects.\splitnote{Hypothesis is clear and testable.} +procedures and verifying continuous behavior between transitions, we can create +hybrid control systems with end-to-end correctness guarantees. If existing +procedures can be formalized into logical specifications and continuous dynamics +verified against transition requirements, then autonomous controllers can be +built that are provably free from design defects. % Pay-off -\oldt{This approach will enable autonomous control in nuclear power plants -while maintaining the high safety standards required by the industry. - -% Qualifications -This work is conducted within the University of Pittsburgh Cyber Energy -Center, which provides access to industry collaboration and Emerson control -hardware, ensuring that developed solutions align with practical -implementation requirements.} \newt{This approach will enable autonomous -control in nuclear power plants while maintaining the high safety standards -required by the industry. The University of Pittsburgh Cyber Energy Center's -partnership with Emerson provides access to industry-standard control -hardware, ensuring that developed solutions align with practical -implementation requirements from the outset.} +This approach will enable autonomous control in nuclear power plants while +maintaining the high safety standards required by the industry. The University +of Pittsburgh Cyber Energy Center's partnership with Emerson provides access to +industry-standard control hardware, ensuring that developed solutions align with +practical implementation requirements from the outset. % OUTCOMES PARAGRAPHS If this research is successful, we will be able to do the following: @@ -81,18 +58,14 @@ If this research is successful, we will be able to do the following: \item \textbf{Translate written procedures into verified control logic.} % Strategy We will develop a methodology for converting existing written operating - procedures into formal specifications that can be automatically - synthesized into discrete control logic. This process will use structured - intermediate representations to bridge natural language procedures and - mathematical logic. + procedures into formal specifications that can be automatically synthesized + into discrete control logic. This process will use structured intermediate + representations to bridge natural language procedures and mathematical + logic. % Outcome - \oldt{Control system engineers will generate verified mode-switching - controllers directly from regulatory procedures without formal methods - expertise, lowering the barrier to high-assurance control systems.} - \newt{This will lower the barrier to high-assurance control systems by - generating verified mode-switching controllers directly from regulatory - procedures.}\dasinline{Same comment as in executive summary. Might not be - true and is not the point.} + Control system engineers will generate verified mode-switching controllers + directly from regulatory procedures, lowering the barrier to high-assurance + control systems. % OUTCOME 2 Title \item \textbf{Verify continuous control behavior across mode transitions.} @@ -116,8 +89,7 @@ If this research is successful, we will be able to do the following: reactor simulation using industry-standard control hardware. This demonstration will prove correctness across multiple coordinated control modes from cold shutdown through criticality to power - operation.\splitnote{``cold shutdown through criticality to power - operation'' — concrete and impressive scope.} + operation. % Outcome We will demonstrate that autonomous hybrid control can be realized in the nuclear industry with current equipment, establishing a path toward @@ -127,21 +99,11 @@ If this research is successful, we will be able to do the following: % IMPACT PARAGRAPH Innovation The innovation in this work is unifying discrete synthesis with continuous -verification to enable end-to-end correctness guarantees for hybrid -systems.\splitnote{Clear ``what's new'' statement.} +verification to enable end-to-end correctness guarantees for hybrid systems. % Outcome Impact If successful, control engineers will create autonomous controllers from -existing procedures with mathematical proof of correct behavior. -High-assurance autonomous control will become practical for safety-critical -applications. +existing procedures with mathematical proof of correct behavior. High-assurance +autonomous control will become practical for safety-critical applications. % Impact/Pay-off -\oldt{This capability is essential for the economic viability of -next-generation nuclear power. Small modular reactors offer a promising -solution to growing energy demands, but their success depends on reducing -per-megawatt operating costs through increased autonomy. This research will -provide the tools to achieve that autonomy while maintaining the exceptional -safety record the nuclear industry requires.} \newt{This research will -provide the tools to achieve that autonomy while maintaining the exceptional -safety record the nuclear industry -requires.}\dasinline{This paragraph is literally the same as the rest of the -GO. Does not belong here and feels very redundant.} +This research will provide the tools to achieve that autonomy while maintaining +the exceptional safety record the nuclear industry requires. diff --git a/1-goals-and-outcomes/research-statement.tex b/1-goals-and-outcomes/research-statement.tex index feb0c29..9ae7f3e 100644 --- a/1-goals-and-outcomes/research-statement.tex +++ b/1-goals-and-outcomes/research-statement.tex @@ -1,78 +1,56 @@ +\dasnote{Research statement is very similar to GO because that's what I had +when I prepared it. If it's going to be an executive summary, it should talk +more about the other sections rather than just being a slightly different GO +section.} % GOAL PARAGRAPH The goal of this research is to develop a methodology for creating autonomous -\oldt{control systems with event-driven control laws that have guarantees of -safe and correct behavior.} \newt{hybrid control systems with mathematical -guarantees of safe and correct behavior.}\splitnote{Strong, direct opening. -Sets scope immediately.} -\dasinline{Title needs updated to High Assurance Hybrid -Control Systems. Maybe removal of `formal'?} +hybrid control systems with mathematical guarantees of safe and correct +behavior. % INTRODUCTORY PARAGRAPH Hook Nuclear power relies on extensively trained operators who follow detailed written procedures to manage reactor control. Based on these procedures and -\oldt{operators'} \newt{their} interpretation of plant conditions, -\oldt{operators} \newt{they} make critical decisions about when to switch -between control objectives. +their interpretation of plant conditions, they make critical decisions about +when to switch between control objectives. % Gap -\oldt{But, reliance} \newt{This reliance} on human operators has created an -economic challenge for next-generation nuclear power plants. Small modular -reactors face significantly higher per-megawatt staffing costs than -conventional plants.\dasinline{Obvious but source required.} Autonomous -control systems \oldt{are needed that can} \newt{must} safely manage complex -operational sequences with the same assurance as human-operated systems, but -without constant supervision. +This reliance on human operators has created an economic challenge for +next-generation nuclear power plants. Small modular reactors face significantly +higher per-megawatt staffing costs than conventional plants. Autonomous control +systems are needed that can safely manage complex operational sequences with the +same assurance as human-operated systems, but without constant supervision. % APPROACH PARAGRAPH Solution To address this need, we will combine formal methods from computer science -with control theory \oldt{to build hybrid control systems that are correct by -construction.} \newt{to build hybrid control systems that are correct by +with control theory to build hybrid control systems that are correct by construction, leveraging the extensive domain knowledge already embedded in -existing operating procedures and safety analyses.} +existing operating procedures and safety analyses. % Rationale Hybrid systems use discrete logic to switch between continuous control modes, similar to how operators change control strategies. Existing formal methods generate provably correct switching logic but cannot handle continuous dynamics during transitions, while traditional control theory verifies continuous behavior but lacks tools for proving discrete switching -correctness.\splitnote{Nice parallel structure showing the gap.} +correctness. % Hypothesis and Technical Approach We will bridge this gap through a three-stage methodology. First, we will -translate written operating procedures into temporal logic specifications -using NASA's Formal Requirements Elicitation Tool (FRET). \oldt{which -structures requirements into scope, condition, component, timing, and -response elements. This structured approach enables realizability checking to -identify conflicts and ambiguities in procedures before implementation.} -\newt{FRET structures requirements into scope, condition, component, timing, -and response elements, enabling realizability checking that identifies -conflicts and ambiguities in procedures before implementation.} -\dasinline{Had to read this twice.} -Second, we will synthesize discrete mode switching logic using reactive -synthesis \oldt{to generate deterministic automata that are provably correct -by construction.} \newt{to produce deterministic automata that are correct by -construction.}\dasinline{Also had to read this twice. A lot of -jargon. Check topic stress.} -Third, we will develop continuous controllers for each discrete mode using -standard control theory and reachability analysis. We will classify -continuous modes based on their transition objectives \oldt{, and then employ -assume-guarantee contracts and barrier certificates to prove that mode -transitions occur safely and as defined by the deterministic automata.} -\newt{and verify safe mode transitions using barrier certificates and -reachability analysis.}\dasinline{I don't think I ever mention this phrase -again specifically. Might be a dogwhistle to other work unintentionally. Must -be careful.} - +translate written operating procedures into temporal logic specifications using +NASA's Formal Requirements Elicitation Tool (FRET). FRET structures requirements +into scope, condition, component, timing, and response elements. This approach +enables realizability checking that identifies conflicts and ambiguities in +procedures before implementation. Second, we will synthesize discrete mode +switching logic using reactive synthesis to produce deterministic automata that +are correct by construction. Third, we will develop continuous controllers for +each discrete mode using standard control theory and reachability analysis. We +will classify continuous modes based on their transition objectives and verify +safe mode transitions using barrier certificates and reachability analysis. This compositional approach enables local verification of continuous modes without requiring global trajectory analysis across the entire hybrid system. -\oldt{We will demonstrate this on an Emerson Ovation control system.} -\newt{We will validate this methodology through hardware-in-the-loop testing +We will validate this methodology through hardware-in-the-loop testing on an Emerson Ovation distributed control system, made possible through the -University of Pittsburgh Cyber Energy Center's industry partnership.} -\dasinline{Where did this come from? Needs context.} - +University of Pittsburgh Cyber Energy Center's industry partnership. % Pay-off -This approach \oldt{will demonstrate autonomous control can be used for} -\newt{enables autonomous management of} complex nuclear power operations +This approach enables autonomous management of complex nuclear power operations while maintaining safety guarantees. % OUTCOMES PARAGRAPHS @@ -85,12 +63,8 @@ If this research is successful, we will be able to do the following: into formal specifications. These specifications will be synthesized into discrete control logic using reactive synthesis tools. % Outcome - \oldt{Control engineers will be able to generate mode-switching - controllers from regulatory procedures with little formal methods - expertise, reducing barriers to high-assurance control systems.} - \newt{This will reduce barriers to high-assurance control systems by - generating verified mode-switching controllers directly from regulatory - procedures.}\dasinline{This may not be true, and perhaps does not belong.} + Control engineers will be able to generate mode-switching + controllers from regulatory procedures, reducing barriers to high-assurance control systems. % OUTCOME 2 Title \item \textit{Verify continuous control behavior across mode transitions.} @@ -109,13 +83,8 @@ If this research is successful, we will be able to do the following: We will implement this methodology on a small modular reactor simulation using industry-standard control hardware. % Outcome - \oldt{Control engineers will be able to achieve autonomy without - retraining costs or developing new equipment by implementing - high-assurance autonomous controls on industrial platforms they already - use.} \newt{Without retraining costs or new equipment, control engineers + Without retraining costs or new equipment, control engineers will be able to implement high-assurance autonomous controls on industrial - platforms they already use.}\dasinline{Flip the clauses. Put retraining - and new equipment before the comma, end with building HAHACs with control - hardware they already use. That's the more important part.} + hardware they already use. \end{enumerate} diff --git a/2-state-of-the-art/state-of-art.tex b/2-state-of-the-art/state-of-art.tex index 810224d..3b0d3fd 100644 --- a/2-state-of-the-art/state-of-art.tex +++ b/2-state-of-the-art/state-of-art.tex @@ -1,66 +1,33 @@ \section{State of the Art and Limits of Current Practice} The principal aim of this research is to create autonomous reactor control -systems that are tractably safe. \oldt{To understand what is being automated, -we must first understand how nuclear reactors are operated today. This section -examines reactor operators and the operating procedures we aim to leverage, -then investigates limitations of human-based operation, and concludes with -current formal methods approaches to reactor control systems.} -\newt{Understanding what is being automated requires understanding how -nuclear reactors are operated today. This section examines reactor operating -procedures, investigates limitations of human-based operation, and reviews -current formal methods approaches to reactor control -systems.}\dasinline{Don't like ``we'' here. Sounds like ``we're going on an -adventure!'' and feels jocular. Maybe: ``To motivate this proposal, the -state of the art of nuclear reactor control, blah, and blah, are discussed -in this section.''} +systems that are tractably safe. Understanding what is being automated requires +understanding how nuclear reactors are operated today. This section examines +reactor operating procedures, investigates limitations of human-based operation, +and reviews current formal methods approaches to reactor control systems. \subsection{Current Reactor Procedures and Operation} -\oldt{Nuclear plant procedures exist in a hierarchy: normal operating -procedures for routine operations, abnormal operating procedures for -off-normal conditions, Emergency Operating Procedures (EOPs) for -design-basis accidents, Severe Accident Management Guidelines (SAMGs) for -beyond-design-basis events, and Extensive Damage Mitigation Guidelines -(EDMGs) for catastrophic damage scenarios.} \newt{Nuclear plant operations -are governed by a hierarchy of written procedures, ranging from normal -operating procedures for routine operations to Emergency Operating -Procedures (EOPs) for design-basis accidents and Severe Accident Management -Guidelines (SAMGs) for beyond-design-basis events. These procedures exist -because reactor operation requires deterministic responses to a wide range -of plant conditions, from routine power changes to catastrophic -failures.}\dasinline{This sentence is MASSIVE. Why is there 6 lines -describing different types of procedures? WHO CARES? Need a sentence after -saying why we have these procedures.} These procedures must comply with 10 -CFR 50.34(b)(6)(ii) and are developed using guidance from -NUREG-0899~\cite{NUREG-0899, 10CFR50.34}, but their development relies -fundamentally on expert judgment and simulator validation rather than formal -verification. - -Procedures undergo technical evaluation, simulator validation testing, and -biennial review as part of operator requalification under 10 CFR -55.59~\cite{10CFR55.59}. Despite this rigor, procedures fundamentally lack -\oldt{formal verification of key safety properties.} \newt{exhaustive -verification of key safety properties.}\dasinline{Does the audience know -what formal verification is at this point? Probably, but should say -differently. Maybe `exhaustive' or `definitive'.} No mathematical proof -exists that procedures cover all possible plant states, that required actions -can be completed within available timeframes, or that transitions between -procedure sets maintain safety invariants. +Nuclear plant operations are governed by a hierarchy of written procedures, +ranging from normal operating procedures for routine operations to Emergency +Operating Procedures (EOPs) for design-basis accidents and Severe Accident +Management Guidelines (SAMGs) for beyond-design-basis events. These procedures +exist because reactor operation requires deterministic responses to a wide range +of plant conditions, from routine power changes to catastrophic failures. These +procedures must comply with 10 CFR 50.34(b)(6)(ii) and are developed using +guidance from NUREG-0899~\cite{NUREG-0899, 10CFR50.34}. Procedures undergo +technical evaluation, simulator validation testing, and biennial review as part +of operator requalification under 10 CFR 55.59~\cite{10CFR55.59}. Despite this +rigor, procedures fundamentally lack exhaustive verification of key safety +properties. \textbf{LIMITATION:} \textit{Procedures lack exhaustive verification of -correctness and completeness.} \oldt{Current procedure development relies on -expert judgment and simulator validation. No mathematical proof exists that -procedures cover all possible plant states, that required actions can be -completed within available timeframes, or that transitions between procedure -sets maintain safety invariants. Paper-based procedures cannot ensure correct -application, and even computer-based procedure systems lack the formal -guarantees that automated reasoning could provide.} \newt{Paper-based -procedures cannot ensure correct application, and even computer-based -procedure systems lack the guarantees that automated reasoning could -provide.}\splitpolish{This repeats the ``No mathematical proof exists...'' -sentence almost verbatim from the paragraph above. Either cut it from the -paragraph or from the LIMITATION box.} +correctness and completeness.} No mathematical proof exists that procedures +cover all possible plant states, that required actions can be completed within +available timeframes, or that transitions between procedure sets maintain safety +invariants. Paper-based procedures cannot ensure correct application, and even +computer-based procedure systems lack the formal guarantees that automated +reasoning could provide. Nuclear plants operate with multiple control modes: automatic control, where the reactor control system maintains target parameters through continuous @@ -74,71 +41,38 @@ safety signals with millisecond response times, and engineered safety features actuate automatically on accident signals without operator action required. -\oldt{The division between automated and human-controlled functions reveals -the fundamental challenge of hybrid control. Highly automated systems handle -reactor protection---automatic trips on safety parameters, emergency core -cooling actuation, containment isolation, and basic process -control~\cite{WRPS.Description, gentillon_westinghouse_1999}. Human -operators, however, retain control of strategic decision-making: power level -changes, startup/shutdown sequences, mode transitions, and procedure -implementation.} \newt{This division between automated and human-controlled +This division between automated and human-controlled functions is itself the hybrid control problem. Automated systems handle reactor protection: trips on safety parameters, emergency core cooling actuation, containment isolation, and basic process control~\cite{WRPS.Description, gentillon_westinghouse_1999}. Human operators retain control of everything else: power level changes, startup/shutdown sequences, mode transitions, and procedure -implementation.}\dasinline{After reading the next sentence, ``key safety'' -can honestly just be a semicolon.}\dasinline{Not sure what the challenge -actually is as this paragraph is written. What's the -point?}\splitnote{This is the key insight — the hybrid nature is already -there, just not formally verified.} +implementation. -\subsection{Human Factors in Nuclear Accidents} - -\oldt{Current-generation nuclear power plants employ over 3,600 active -NRC-licensed reactor operators in the United -States~\cite{operator_statistics}. These operators divide into Reactor -Operators (ROs), who manipulate reactor controls, and Senior Reactor -Operators (SROs), who direct plant operations and serve as shift -supervisors~\cite{10CFR55}. Staffing typically requires at least two ROs and -one SRO for current-generation units~\cite{10CFR50.54}. Becoming a reactor -operator requires several years of training.} \newt{Nuclear plant staffing -requires at least two Reactor Operators (ROs) and one Senior Reactor -Operator (SRO) per unit~\cite{10CFR50.54}, with operators requiring several -years of training and NRC licensing under 10 CFR Part -55~\cite{10CFR55}.}\dasinline{Why is this here? Should this be in broader -impacts about running out of ROs? As it is here I have no idea why this is -here.} - -The persistent role of human error in nuclear safety incidents---despite -decades of improvements in training and procedures---provides the most -compelling motivation for formal automated control with mathematical safety -guarantees.\splitnote{Strong thesis for this subsection.} Operators hold -legal authority under 10 CFR Part 55 to make critical -decisions~\cite{10CFR55},\dasinline{Cite.} including departing from normal -regulations during emergencies. \oldt{The Three Mile Island (TMI) accident} -\newt{This authority itself introduces risk. The Three Mile Island (TMI) -accident}\dasinline{Needs a connector here. Like ``But this can in and of -itself prime plants for an accident.'' Then continue.} demonstrated how a -combination of personnel error, design deficiencies, and component failures -led to partial meltdown when operators misread confusing and contradictory -readings and shut off the emergency water system~\cite{Kemeny1979}. The -President's Commission on TMI identified a fundamental ambiguity: placing -responsibility for safe power plant operations on the licensee without -formal verification that operators can fulfill this responsibility does not -guarantee safety. This tension between operational flexibility and safety -assurance remains unresolved: the person responsible for reactor safety is -often the root cause of failures.\splitnote{``the person responsible for -reactor safety is often the root cause of failures'' — devastating summary. -Very effective.} +The persistent role of human error in nuclear safety incidents---despite decades +of improvements in training and procedures---provides the most compelling +motivation for formal automated control with mathematical safety guarantees. +Operators hold legal authority under 10 CFR Part 55 to make critical +decisions~\cite{10CFR55}, including departing from normal regulations during +emergencies. This authority itself introduces risk. The Three Mile Island (TMI) +accident demonstrated how a combination of personnel error, design deficiencies, +and component failures led to partial meltdown when operators misread confusing +and contradictory readings and shut off the emergency water +system~\cite{Kemeny1979}. The President's Commission on TMI identified a +fundamental ambiguity: placing responsibility for safe power plant operations on +the licensee without formal verification that operators can fulfill this +responsibility does not guarantee safety. This tension between operational +flexibility and safety assurance remains unresolved: the person responsible for +reactor safety is often the root cause of failures.\splitnote{``the person + responsible for reactor safety is often the root cause of failures'' — +devastating summary. Very effective.} Multiple independent analyses converge on a striking statistic: 70--80\% of nuclear power plant events are attributed to human error, versus approximately 20\% to equipment failures~\cite{WNA2020}. More significantly, the root cause of all severe accidents at nuclear power plants---Three Mile -Island, Chernobyl, and Fukushima Daiichi---has been identified as poor -safety management and safety culture: primarily human +Island, Chernobyl, and Fukushima Daiichi---has been identified as primarily human factors~\cite{hogberg_root_2013}. A detailed analysis of 190 events at Chinese nuclear power plants from 2007--2020~\cite{zhang_analysis_2025} found that 53\% of events involved @@ -159,29 +93,20 @@ drives it home.} \subsubsection{HARDENS} The High Assurance Rigorous Digital Engineering for Nuclear Safety (HARDENS) -project represents the most advanced application of formal methods to -nuclear reactor control systems to date~\cite{Kiniry2024}. +project represents the most advanced application of formal methods to nuclear +reactor control systems to date~\cite{Kiniry2024}. HARDENS aimed to address a +fundamental dilemma: existing U.S. nuclear control rooms rely on analog +technologies from the 1950s--60s. This technology is obsolete compared to modern +control systems and incurs significant risk and cost. A U.S. Nuclear Regulatory +Commission report demonstrated that model-based systems engineering and formal +methods could design, verify, and implement a complex protection system meeting +regulatory criteria. The project delivered a Reactor Trip System (RTS) +implementation with traceability from regulatory requirements to verified +software through formal architecture specifications. -HARDENS aimed to address a fundamental dilemma: existing U.S. nuclear -control rooms rely on analog technologies from the -1950s--60s.\dasinline{Source?} This technology is obsolete compared to -modern control systems and incurs significant risk and cost. The NRC -contracted Galois, a formal methods firm, to demonstrate that Model-Based -Systems Engineering and formal methods could design, verify, and implement a -complex protection system meeting regulatory criteria at a fraction of -typical cost. The project delivered a Reactor Trip System (RTS) -implementation with full traceability from \oldt{NRC Request for Proposals -and IEEE standards through formal architecture specifications to verified -software.} \newt{regulatory requirements through formal architecture -specifications to verified software.}\dasinline{Wordsmith this to remove the -RFP and IEEE standards language. Should just say requirements.} - -\oldt{HARDENS employed formal methods tools and techniques across the -verification hierarchy.} \newt{HARDENS employed formal methods tools at +HARDENS employed formal methods tools at every level of system development, from high-level requirements through -executable models to generated code.}\dasinline{Zero discussion about what -the verification hierarchy is. What is a specification or a requirement to -someone who hasn't heard of one before?} High-level specifications used +executable models to generated code. High-level specifications used Lando, SysMLv2, and FRET (NASA Formal Requirements Elicitation Tool) to capture stakeholder requirements, domain engineering, certification requirements, and safety requirements. Requirements were analyzed for @@ -192,29 +117,16 @@ models of sensors, actuators, and compute infrastructure. Automatic code synthesis generated verifiable C implementations and SystemVerilog hardware implementations directly from Cryptol models---eliminating the traditional gap between specification and implementation where errors commonly -arise.\splitnote{Good technical depth on HARDENS toolchain.} +arise. -\oldt{Despite its accomplishments, HARDENS has a fundamental limitation -directly relevant to hybrid control synthesis: the project addressed only -discrete digital control logic without modeling or verifying continuous -reactor dynamics. The Reactor Trip System specification and verification -covered discrete state transitions (trip/no-trip decisions), digital sensor -input processing through discrete logic, and discrete actuation outputs -(reactor trip commands). The project did not address continuous dynamics of -nuclear reactor physics. Real reactor safety depends on the interaction -between continuous processes---temperature, pressure, neutron flux---evolving -in response to discrete control decisions. HARDENS verified the discrete -controller in isolation but not the closed-loop hybrid system behavior.} -\newt{Despite these accomplishments, HARDENS addressed only discrete digital +Despite these accomplishments, HARDENS addressed only discrete digital control logic. The Reactor Trip System verification covered discrete state transitions, digital sensor processing, and discrete actuation outputs. It did not model or verify continuous reactor dynamics. Real reactor safety depends on the interaction between continuous processes---temperature, pressure, neutron flux---evolving in response to discrete control decisions. -HARDENS verified the discrete controller in isolation but not the -closed-loop hybrid system behavior.}\dasinline{Edit these to more clearly -separate the context from the limit. The limitation should be in the -limitation.}\splitnote{Clear articulation of the gap your work fills.} +HARDENS verified the discrete controller in isolation but not a +closed-loop hybrid system behavior. \textbf{LIMITATION:} \textit{HARDENS addressed discrete control logic without continuous dynamics or hybrid system verification.} Verifying @@ -223,66 +135,49 @@ system exhibits desired continuous behavior such as stability, convergence to setpoints, or maintained safety margins. HARDENS produced a demonstrator system at Technology Readiness Level 2--3 -(analytical proof of concept with laboratory breadboard validation) rather -than a deployment-ready system validated through extended operational -testing. The NRC Final Report explicitly notes~\cite{Kiniry2024} that all -material is considered in development, not a finalized product, and that -``The demonstration of its technical soundness was to be at a level -consistent with satisfaction of the current regulatory criteria, although -with no explicit demonstration of how regulatory requirements are -met.''\dasinline{Check this quote. Absolutely damning for HARDENS if true -and hilarious Galois said this.} The project did not include deployment in -actual nuclear facilities, testing with real reactor systems under -operational conditions, side-by-side validation with operational analog RTS -systems, systematic failure mode testing, NRC licensing review, or human -factors validation with licensed operators in realistic control room -scenarios. +(analytical proof of concept with laboratory breadboard validation) rather than +a deployment-ready system validated through extended operational testing. The +NRC Final Report explicitly notes~\cite{Kiniry2024} that all material is +considered in development, not a finalized product, and that ``The demonstration +of its technical soundness was to be at a level consistent with satisfaction of +the current regulatory criteria, although with no explicit demonstration of how +regulatory requirements are met.'' The project did not include deployment in +%DAS 3/16/26. I double checked this quote. It's on page 4 of the HARDENS report +actual nuclear facilities, testing with real reactor systems under operational +conditions, side-by-side validation with operational analog RTS systems, +systematic failure mode testing, NRC licensing review, or human factors +validation with licensed operators in realistic control room scenarios. \textbf{LIMITATION:} \textit{HARDENS achieved TRL 2--3 without experimental -validation.} \oldt{While formal verification provides mathematical -correctness guarantees for the implemented discrete logic, the gap between -formal verification and actual system deployment involves myriad practical -considerations: integration with legacy systems, long-term reliability under -harsh environments, human-system interaction in realistic operational -contexts, and regulatory acceptance of formal methods as primary assurance -evidence.} \newt{The gap between formal verification and actual system -deployment remains wide: integration with legacy systems, long-term -reliability under harsh environments, human-system interaction, and -regulatory acceptance of formal methods as primary assurance -evidence.}\dasinline{Same as before. Separate limit from context better.} +validation.} While formal verification provides mathematical correctness +guarantees for the implemented discrete logic, the gap between formal +verification and actual system deployment involves myriad practical +considerations: integration with legacy systems, human-system interaction in +realistic operational contexts, and regulatory acceptance of formal methods as +primary assurance evidence remain as significant challenges. \subsubsection{Sequent Calculus and Differential Dynamic Logic} -\oldt{There has been additional work to do verification of hybrid systems by -extending the temporal logics directly.} \newt{A separate line of work +A separate line of work extends temporal logics to verify hybrid systems -directly.}\dasinline{Need to introduce temporal logic and FRET here first.} -The result has been the field of differential dynamic logic (dL). dL +directly. The result has been the field of differential dynamic logic (dL). dL introduces two additional operators into temporal logic: the box operator and the diamond operator. The box operator \([\alpha]\phi\) states that for some region \(\phi\), the hybrid system \(\alpha\) always remains within that -region. In this way, it is a safety \oldt{ivariant} \newt{invariant} being -enforced for the system.\splitfix{Typo: ``ivariant'' should be -``invariant''} The second operator, the diamond operator +region. In this way, it is a safety invariant being +enforced for the system. The second operator, the diamond operator \(<\alpha>\phi\) says that for the region \(\phi\), there is at least one trajectory of \(\alpha\) that enters that region. This is a declaration of a liveness property. -%source: https://symbolaris.com/logic/dL.html -While dL allows for the specification of these liveness and safety -properties, actually proving them for a given hybrid system is quite -difficult. Automated proof assistants such as KeYmaera X exist to help -develop proofs of systems using dL, but so far have been insufficient for -reasonably complex hybrid systems. The main issue behind creating system -proofs using dL is state space explosion and non-terminating solutions. -%Source: that one satellite tracking paper that has the problem with the -%gyroscopes overloding and needing to dump speed all the time -Approaches have been made to alleviate these issues for nuclear power -contexts using contract and decomposition based methods, \oldt{but are far -from a complete methodology to design systems with.} \newt{but do not yet -constitute a complete design methodology.}\splitpolish{``but are far from a -complete methodology to design systems with'' — awkward ending preposition.} -%source: Manyu's thesis. +While dL allows for the specification of these liveness and safety properties, +actually proving them for a given hybrid system is quite difficult. Automated +proof assistants such as KeYmaera X exist to help develop proofs of systems +using dL, but so far have been insufficient for reasonably complex hybrid +systems. The main issue behind creating system proofs using dL is +non-terminating solutions. Approaches have been made to alleviate these issues +for nuclear power contexts using contract and decomposition based methods, but +do not yet constitute a complete design methodology \cite{kapuria_using_2025}. Instead, these approaches have been used on systems that have been designed a priori, and require expert knowledge to create the system proofs. @@ -296,8 +191,4 @@ post-hoc analysis of existing systems, not for the constructive design of autonomous controllers.} Current dL-based approaches verify systems that have already been designed, requiring expert knowledge to construct proofs. They have not been applied to the synthesis of new controllers from -operational requirements.\splitinline{Your comment here is spot-on. You -should add a LIMITATION box: \textit{Differential dynamic logic has been -used for post-hoc analysis of existing systems, not for the constructive -design of autonomous controllers.} This is exactly the gap you're filling — -you're doing synthesis, not just verification.} +operational requirements. diff --git a/20260314_reading.pdf b/20260314_reading.pdf new file mode 100644 index 0000000..d4aea48 Binary files /dev/null and b/20260314_reading.pdf differ diff --git a/3-research-approach/approach.tex b/3-research-approach/approach.tex index 08a1c86..72f17fd 100644 --- a/3-research-approach/approach.tex +++ b/3-research-approach/approach.tex @@ -1,54 +1,5 @@ \section{Research Approach} -% ============================================================================ -% STRUCTURE (maps to Thesis.RA tasks): -% 1. Introduction + Hybrid Systems Definition (Task 34) -% 2. System Requirements and Specifications (Task 35) -% 3. Discrete Controller Synthesis (Task 36) -% 4. Continuous Controllers Overview (Task 37) -% 4.1 Transitory Modes (Task 38) -% 4.2 Stabilizing Modes (Task 39) -% 4.3 Expulsory Modes (Task 40) -% 5. Industrial Implementation (Task 41) -% ============================================================================ - -% ---------------------------------------------------------------------------- -% 1. INTRODUCTION AND HYBRID SYSTEMS DEFINITION -% ---------------------------------------------------------------------------- -\oldt{Previous approaches to autonomous control have verified discrete -switching logic or continuous control behavior, but not both simultaneously. -Validation of continuous controllers today consists of extensive simulation -trials. Discrete switching logic for routine operation has been driven by -human operators, whose evaluation includes simulated control room testing and -human factors research. Neither method, despite being extremely resource -intensive, provides rigorous guarantees of control system behavior. HAHACS -bridges this gap by composing formal methods from computer science with -control-theoretic verification, formalizing reactor operations using the -framework of hybrid automata.} \newt{HAHACS bridges the gap between discrete -and continuous verification by composing formal methods from computer science -with control-theoretic verification, formalizing reactor operations using the -framework of hybrid automata.}\dasinline{Honestly just get rid of this whole -paragraph.} - -The challenge of hybrid system verification lies in the interaction between -discrete and continuous dynamics. Discrete transitions change the -\oldt{governing} \newt{active}\dasinline{Governing what? People? Whos in -Whoville?} vector field, creating discontinuities in the system's behavior. -Traditional verification techniques designed for purely discrete or purely -continuous systems cannot handle this interaction -directly.\splitpolish{Missing space before ``Our}\dasinline{This whole -paragraph should just be after the definition of the tuple. First sentence -can stay, but all this explanation should move.} Our methodology addresses -this challenge through decomposition. We verify discrete switching logic and -continuous mode behavior separately, then compose these guarantees to reason -about the complete hybrid system.\splitsuggest{Compositional verification -claim needs citation. See assume-guarantee literature (Henzinger, Alur). -None of the NEEDS\_REVIEWED papers directly prove this composition is sound -for your specific approach.} This two-layer approach mirrors the structure of -reactor operations themselves: discrete supervisory logic determines which -control mode is active, while continuous controllers govern plant behavior -within each mode. - To build a high-assurance hybrid autonomous control system (HAHACS), we must first establish a mathematical description of the system. This work draws on automata theory, temporal logic, and control theory. A hybrid system is a @@ -58,7 +9,7 @@ system. This means that the system does not have external input and that continuous states do not change instantaneously when discrete states change. For our systems of interest, the continuous states are physical quantities that are always Lipschitz continuous. This nomenclature is borrowed from the -Handbook on Hybrid Systems Control \cite{HANDBOOK ON HYBRID SYSTEMS}, but is +Handbook on Hybrid Systems Control \cite{lunz_handbook_2009}, but is redefined here for convenience: \begin{equation} @@ -85,18 +36,33 @@ where: \item $Inv$: safety invariants on the continuous dynamics \end{itemize} +HAHACS bridges the gap between discrete and continuous verification by composing +formal methods from computer science with control-theoretic verification, +formalizing reactor operations using the framework of hybrid automata. The +challenge of hybrid system verification lies in the interaction between discrete +and continuous dynamics. Discrete transitions change the active continuous +vector field, creating discontinuities in the system's behavior. Traditional +verification techniques designed for purely discrete or purely continuous +systems cannot handle this interaction directly. Our methodology addresses this +challenge through decomposition. We verify discrete switching logic and +continuous mode behavior separately, then compose these guarantees to reason +about the complete hybrid system.\splitsuggest{Compositional verification claim + needs citation. See assume-guarantee literature (Henzinger, Alur). None of the + NEEDS\_REVIEWED papers directly prove tHANDBOOK ON HYBRID SYSTEMShis composition is sound for your +specific approach.} This two-layer approach mirrors the structure of reactor +operations themselves: discrete supervisory logic determines which control mode +is active, while continuous controllers govern plant behavior within each mode. + The creation of a HAHACS amounts to the construction of such a tuple together with proof artifacts demonstrating that the intended behavior of the control system is satisfied by its actual -implementation.\oldt{}\newt{ In concrete terms, this means producing a +implementation. In concrete terms, this means producing a discrete automaton whose transitions are provably correct, continuous controllers whose behavior is verified against transition requirements, and -formal evidence linking the two.}\dasinline{Add a sentence explaining what -this actually means.} This approach is tractable now because the +formal evidence linking the two. This approach is tractable now because the infrastructure for each component has matured. The novelty is not in the individual pieces, but in the architecture that connects -them.\splitnote{This is your key insight --- the novelty is compositional, -not component-level.} By defining entry, exit, and safety conditions at the +them. By defining entry, exit, and safety conditions at the discrete level first, we transform the intractable problem of global hybrid verification into a collection of local verification problems with clear interfaces. Verification is performed per mode rather than on the full @@ -153,8 +119,6 @@ operations. \node[dynamics] at (5,-4.9) {$\dot{x} = f_3(x)$}; \end{tikzpicture} -\dasinline{Figure dynamics show control inputs u, but these systems are -autonomous. What's up with that?} \caption{Simplified hybrid automaton for reactor startup. Each discrete state $q_i$ has associated continuous dynamics $f_i$. Guard conditions on transitions (e.g., $T_{avg} > T_{min}$) are predicates over @@ -164,15 +128,8 @@ autonomous. What's up with that?} mode.} \label{fig:hybrid_automaton} \end{figure} - -%%% NOTES (Section 1): -% - May want to clarify the "no external input" claim with a footnote about -% strategic inputs (e.g., remote start/stop commands) -% - The reset map R is often identity for physical systems; clarify if needed - -% ---------------------------------------------------------------------------- -% 2. SYSTEM REQUIREMENTS AND SPECIFICATIONS -% ---------------------------------------------------------------------------- +\dasnote{There's no reference of this figure in the prose. Perhaps some +explanation could be done in a paragraph to explain the thought process.} \subsection{System Requirements, Specifications, and Discrete Controllers} Human control of nuclear power can be divided into three different scopes: @@ -186,28 +143,20 @@ chemistry. Tactical control has already been somewhat automated in nuclear power plants today, and is generally considered ``automatic control'' when autonomous. These controls are almost always continuous systems with a direct impact on the physical state of the -plant.\dasinline{This should be written to be clear this isn't an exhaustive -list.} Tactical control objectives include\oldt{}\newt{, but are not limited -to,} maintaining pressurizer level, maintaining core temperature, or +plant. Tactical control objectives include, but are not limited +to, maintaining pressurizer level, maintaining core temperature, or adjusting reactivity with a chemical shim. -The level of control \oldt{linking} \newt{linking -these two extremes of}\dasinline{Linking of these two extremes. Don't even -say control here.} \oldt{these two extremes is the} operational control +The level of control linking these two extremes is the operational control scope. Operational control is the primary responsibility of human operators -today. Operational control takes the current strategic objective and -implements tactical control objectives to drive the plant towards strategic -goals. In this way, it bridges high-level and low-level goals. A strategic -goal may be to perform refueling at a certain time, while the tactical level -of the plant is currently focused on maintaining a certain core temperature. -The operational level issues the shutdown procedure, using several smaller -tactical goals along the way to achieve this \oldt{objective.} -\newt{strategic objective.}\dasinline{This STRATEGIC objective.} Thus, the -combination of the operational and tactical levels fundamentally forms a -hybrid controller. The tactical level is the continuous evolution of the -plant according to the control input and control law, while the operational -level is a discrete state evolution that determines which tactical control -law to apply. +today. Operational control takes the current strategic objective and implements +tactical control objectives to drive the plant towards strategic goals. In this +way, it bridges high-level and low-level goals. A strategic goal may be to +perform refueling at a certain time, while the tactical level of the plant is +currently focused on maintaining a certain core temperature. The operational +level issues the shutdown procedure, using several smaller tactical goals along +the way to achieve this strategic +objective. %Say something about autonomous control systems near here? @@ -253,43 +202,34 @@ law to apply. \end{figure} -\oldt{This operational control level is the main reason for the requirement -of human operators in nuclear control today. The hybrid nature of this -control system makes it difficult to prove that a controller will perform -according to strategic requirements, as unified infrastructure for building -and verifying hybrid systems does not currently exist. Humans have been used -for this layer because their general intelligence has been relied upon as a -safe way to manage the hybrid nature of this system.} \newt{The hybrid -nature of this control problem is the reason human operators remain -essential. Because unified infrastructure for building and verifying hybrid -systems does not currently exist, the operational layer has relied on human -general intelligence to manage the interaction between discrete decisions and -continuous dynamics.}\dasinline{This operational control level is the main -reason\ldots Add a sentence why. Because the hybrid dynamics have previously -been `unknowable', it's been assumed that a human operator could figure it -out on the fly. Or similar.} \oldt{But these operators use prescriptive -operating manuals to perform their control with strict procedures on what -control to implement at a given time.} \newt{However, human factors research -has sought to minimize the need for general human reasoning by creating -extremely prescriptive operating manuals with strict procedures dictating -what control to implement at a given time.}\dasinline{Say but human factors -has been seeking to eliminate the need for general human behavior by creating -extremely prescriptive operating manuals. This is our leverage.} These -procedures are the key to the operational control scope. +This operational control level is the main reason for the requirement of human +operators in nuclear control today. The hybrid nature of this control system +makes it difficult to prove what the behavior of the combined hybrid system will +do across the entire state-space, so human operators have been used as a +stop-gap for safety. Humans have been used for this layer because their general +intelligence has been relied upon as a safe way to manage the hybrid nature of +this system---if a failure occured, it has been assumed a human operator can +figure out a solution to maintain plant performance and safety without +exhaustive knowledge of plant behavior. However, human factors research has +sought to minimize the need for general human reasoning by creating extremely +prescriptive operating manuals with strict procedures dictating what control to +implement at a given time. These operating manuals have minimized the role of +human operators today, are the key to the automating the operational control +scope. The method of constructing a HAHACS in this proposal leverages two key observations about current practice. First, the operational scope control is -effectively discrete control. Second, the rules for implementing this -control are described prior to their implementation in operating procedures. -Before constructing a HAHACS, we must completely describe its intended -behavior. The behavior of any control system originates in requirements: -statements about what the system must do, must not do, and under what -conditions. For nuclear systems, these requirements derive from multiple -sources including regulatory mandates, design basis analyses, and operating -procedures. The challenge is formalizing these requirements with sufficient -precision that they can serve as the foundation for autonomous control system -synthesis and verification. We can build these requirements using temporal -logic.\dasinline{We definitely need some temporal logic juice in the SOTA.} +effectively discrete control. Second, the rules for implementing this control +are described in operating procedures prior to their implementation. Instead of +implementing these procudures with a human controller, we rigorize the +instructions as a set of formal requirements. The behavior of any control system +originates in requirements: statements about what the system must do, must not +do, and under what conditions. For nuclear systems, these requirements derive +from multiple sources including regulatory mandates, design basis analyses, and +aforementioned operating procedures. The challenge is formalizing these requirements with +sufficient precision that they can serve as the foundation for autonomous +control system synthesis and verification. We can build these requirements using +temporal logic. Temporal logic is a powerful set of semantics for building systems with complex but deterministic behavior. Temporal logic extends classical @@ -302,27 +242,26 @@ also be expressed as temporal logic statements. These specifications form the basis of any proofs about a HAHACS and constitute the fundamental truth statements about what the behavior of the system is designed to be. -Discrete mode transitions include predicates that are Boolean functions over -the continuous state space: $p_i: \mathcal{X} \rightarrow \{\text{true}, +Discrete mode transitions include predicates that are Boolean functions over the +continuous state space: $p_i: \mathcal{X} \rightarrow \{\text{true}, \text{false}\}$. These predicates formalize conditions like ``coolant -temperature exceeds 315\textdegree{}C'' or ``pressurizer level is between -30\% and 60\%.'' Critically, we do not impose this discrete abstraction -artificially. Operating procedures for nuclear systems already define -go/no-go conditions as discrete predicates. These thresholds come from -design basis safety analysis and have been validated over decades of -operational experience. Our methodology assumes this domain knowledge exists -and provides a framework to formalize it. This is why the approach is -feasible for nuclear applications specifically: the hard work of defining -safe operating boundaries has already been done by generations of nuclear -engineers. +temperature exceeds 315\textdegree{}C'' or ``pressurizer level is between 30\% +and 60\%.'' Critically, we do not impose this discrete abstraction artificially. +Operating procedures for nuclear systems already define go/no-go conditions as +discrete predicates, but do so in natural language. These thresholds come from +design basis safety analysis and have been validated over decades of operational +experience. Our methodology assumes this domain knowledge exists and provides a +framework to formalize it. This is why the approach is feasible for nuclear +applications specifically: the work of defining safe operating boundaries has +already been done by generations of nuclear engineers. The work of translating +these requirements from interpretable natural language to a formal requirement is +what remains to be done. -Linear temporal logic (LTL) is particularly well-suited -for\dasinline{Some of this could be in SOTA vs here. Examples in nuclear -space should be in RA, but the general idea of temporal logic and where it -came from in the context of computers could be in SOTA.} specifying reactive +Linear temporal logic (LTL) is particularly well-suited for specifying reactive systems. LTL formulas are built from atomic propositions (our discrete -predicates) using Boolean connectives and temporal operators. The key -temporal operators are: +predicates) using Boolean connectives and temporal operators. The key temporal +operators are: + \begin{itemize} \item $\mathbf{X}\phi$ (next): $\phi$ holds in the next state \item $\mathbf{G}\phi$ (globally): $\phi$ holds in all future states @@ -330,6 +269,7 @@ temporal operators are: \item $\phi \mathbf{U} \psi$ (until): $\phi$ holds until $\psi$ becomes true \end{itemize} + These operators allow us to express safety properties (``the reactor never enters an unsafe configuration''), liveness properties (``the system eventually reaches operating temperature''), and response properties (``if @@ -339,19 +279,19 @@ time'').% checking does NOT support liveness properties. Your ``eventually reaches operating temperature'' example may need alternative verification approach.} - To build these temporal logic statements, an intermediary tool called FRET is -planned to be used. FRET stands for Formal Requirements Elicitation Tool, -and was developed by NASA to build high-assurance timed systems. FRET is an +planned to be used. FRET stands for Formal Requirements Elicitation Tool, and +was developed by NASA to build high-assurance timed systems. FRET is an intermediate language between temporal logic and natural language that allows for rigid definitions of temporal behavior while using a syntax accessible to -engineers without formal methods expertise. This benefit is crucial for the -feasibility of this methodology in industry. By reducing the expert knowledge -required to use these tools, their adoption with the current workforce -becomes easier. +engineers without formal methods expertise\cite{katis_realizability_2022}. This +benefit is crucial for the feasibility of this methodology in industry. By +reducing the expert knowledge required to use these tools, their adoption with +the current workforce becomes easier. A key feature of FRET is the ability to start with logically imprecise -statements and consecutively refine them into well-posed specifications. We +statements and consecutively refine them into well-posed +specifications\cite{katis_realizibility_2022, pressburger_using_2023}. We can use this to our advantage by directly importing operating procedures and design requirements into FRET in natural language, then iteratively refining them into specifications for a HAHACS. This has two distinct benefits. @@ -359,82 +299,44 @@ First, it allows us to draw a direct link from design documentation to digital system implementation. Second, it clearly demonstrates where natural language documents are insufficient. These procedures may still be used by human operators, so any room for interpretation is a weakness that must be -addressed.\splitnote{FRET has been validated: Katis 2022 (pp.1-2, Section -0.3) demonstrates FRET's FRETish template system with 160 distinct patterns; -Pressburger 2023 (pp.17, Section 1) shows successful application to -Lift+Cruise case study with 53 requirements formalized and iteratively -refined---strong evidence your approach is feasible.} +addressed. -(Some examples of where FRET has been used and why it will be successful -here) -%%% NOTES (Section 2): -% - Add concrete FRET example showing requirement $\rightarrow$ FRETish -% $\rightarrow$ LTL -% - Discuss hysteresis and how to prevent mode chattering near boundaries -% - Address sensor noise and measurement uncertainty in threshold definitions -% - Consider numerical precision issues when creating discrete automata - -% ---------------------------------------------------------------------------- -% 3. DISCRETE CONTROLLER SYNTHESIS -% ---------------------------------------------------------------------------- +\dasinline{Maybe add more details about FRET case studies here. This would be +Pressburger and Katis.} Once system requirements are defined as temporal logic specifications, we use them to build the discrete control system. To do this, reactive synthesis tools are employed. Reactive synthesis is a field in computer science that deals with the automated creation of reactive programs from temporal logic specifications. A reactive program is one that, for a given state, takes an -input and produces an output. Our systems fit exactly this mold: the current +input and produces an output\cite{jacobs_reactive_2024}. Our systems fit exactly this mold: the current discrete state and status of guard conditions are the input, while the output is the next discrete state. -Reactive synthesis solves the following problem: given an LTL formula -$\varphi$ that specifies desired system behavior, automatically construct a -finite-state machine (strategy) that produces outputs in response to -environment inputs such that all resulting execution traces satisfy -$\varphi$. If such a strategy exists, the specification is called -\emph{realizable}. The synthesis algorithm either produces a -correct-by-construction controller or reports that no such controller can -exist. This realizability check is itself valuable: an unrealizable -specification indicates conflicting or impossible requirements in the -original procedures.\splitnote{Realizability is proven valuable: Katis 2022 -(pp.7-10) shows FRET diagnosis found 8 minimal unrealizable cores in -infusion pump case; Pressburger 2023 (pp.19-21) shows unrealizability -revealed under-specification (missing stay requirements in LPC aircraft), -driving iterative refinement---this suggests your synthesis approach will -help engineers catch requirement errors early.} +Reactive synthesis solves the following problem: given an LTL formula $\varphi$ +that specifies desired system behavior, automatically construct a finite-state +machine (strategy) that produces outputs in response to environment inputs such +that all resulting execution traces satisfy $\varphi$. If such a strategy +exists, the specification is called \emph{realizable}. The synthesis algorithm +either produces a correct-by-construction controller or reports that no such +controller can exist. This realizability check is itself valuable: an +unrealizable specification indicates conflicting or impossible requirements in +the original procedures. The current implementation and one of the main uses of +FRET today is for exactly this purpose---multiple case studies have used FRET +for the refinement of unrealizable specifications into realizable systems +\cite{katis_realizability_2022, pressburger_using_2023}. -The main advantage of reactive synthesis is that at no point in the -production of the discrete automaton is human engineering of the -implementation required. The resultant automaton is correct by construction. -This method of construction eliminates the possibility of human error at the -implementation stage entirely. \oldt{Instead, the effort on the human -designer is directed at the specification of system behavior itself. This has -two critical implications. First, it makes the creation of the discrete -controller tractable. The reasons the controller changes between modes can be -traced back to the specification and thus to any requirements, which provides -a trace for liability and justification of system behavior. Second, discrete -control decisions made by humans are reliant on the human operator operating -correctly. Humans are intrinsically probabilistic creatures who cannot -eliminate human error. By defining the behavior of this system using temporal -logics and synthesizing the controller using deterministic algorithms, we are -assured that strategic decisions will always be made according to operating -procedures.} \newt{The effort shifts entirely to specifying correct behavior -rather than implementing it. This has two critical implications. First, every -mode transition can be traced back through the specification to its +The main advantage of reactive synthesis is that at no point in the production +of the discrete automaton is human engineering of the implementation required. +The resultant automaton is correct to the specification by construction. This +method of construction eliminates the possibility of human error at the +implementation stage entirely. The effort shifts entirely to specifying correct +behavior rather than implementing it. This has two critical implications. First, +every mode transition can be traced back through the specification to its originating requirement, providing a clear liability and justification chain. Second, by defining system behavior in temporal logic and synthesizing the controller using deterministic algorithms, discrete control decisions become -provably consistent with operating -procedures.}\dasinline{Some goofy issue-point stuff going on in this -paragraph.}\splitnote{Strix (Luttenberger 2020, pp.1-3) is a practical -reactive synthesis tool winning SYNTCOMP competitions; handles LTL specs for -systems with large state spaces. Strix uses parity games and -forward-explorative construction (pp.7-8) to -scale---recommend as your synthesis backend for nuclear -procedures.}\splitsuggest{Consider discussing scalability: Strix handles -large alphabets better (v19.07 update, p.30), but still struggles with very -large specifications. Document expected spec size for SmAHTR startup -procedures to set expectations.} +provably consistent with operating procedures. (Talk about how one would go from a discrete automaton to actual code)\splitnote{GR(1) fragment (Maoz \& Ringert 2015, pp.1-4) is tractable @@ -450,34 +352,22 @@ LTL specs fit GR(1) or full LTL needed---if full LTL required, computational cost grows but Strix may handle it (confirm scalability claim with specific spec size estimates for startup/shutdown procedures).} -%%% NOTES (Section 3): -% - Mention computational complexity of synthesis (doubly exponential worst -% case) -% - Discuss how specification structure affects synthesis tractability -% - Reference GR(1) fragment as a tractable subset commonly used in practice -% - May want to include an example automaton figure - -% ---------------------------------------------------------------------------- -% 4. CONTINUOUS CONTROLLERS -% ---------------------------------------------------------------------------- - \subsection{Continuous Control Modes} The synthesis of the discrete operational controller is only half of an -autonomous controller. These control systems are hybrid, with both discrete -and continuous components. This section describes the continuous control -modes that execute within each discrete state, and how we verify that they -satisfy the requirements imposed by the discrete layer. It is important to -clarify the scope of this methodology with respect to continuous controller -design. This work \oldt{verifies} \newt{will -verify}\dasinline{Verb tense: ``will verify''.} continuous controllers; it -does not synthesize them. The distinction parallels model checking in -software verification: model checking does not tell engineers how to write -correct software, but it verifies whether a given implementation satisfies -its specification. Similarly, we assume that continuous controllers can be -designed using standard control theory techniques. Our contribution is a -verification framework that confirms candidate controllers compose correctly -with the discrete layer to produce a safe hybrid system. +autonomous controller. These control systems are hybrid, with both discrete and +continuous components. This section describes the continuous control modes that +execute within each discrete state, and how we verify that they satisfy the +requirements imposed by the discrete layer. It is important to clarify the scope +of this methodology with respect to continuous controller design. This work will +verify continuous controllers; it does not synthesize them. The distinction +parallels model checking in software verification: model checking does not tell +engineers how to write correct software, but it verifies whether a given +implementation satisfies its specification. Similarly, we assume that continuous +controllers can be designed using standard control theory techniques, and to +that end, are not prohibitive to create. Our contribution is a verification +framework that confirms candidate controllers compose correctly with the +discrete layer to produce a safe hybrid system. The operational control scope defines go/no-go decisions that determine what kind of continuous control to implement. The entry or exit conditions of a @@ -485,12 +375,12 @@ discrete state are themselves the guard conditions $\mathcal{G}$ that define the boundaries for each continuous controller's allowed state-space region. These continuous controllers all share a common state space, but each individual continuous control mode operates within its own partition defined -by the discrete state $q_i$ and the associated guards. This partitioning of -the continuous state space among several discrete vector fields has +by the discrete state $q_i$ and the associated guard conditions. This partitioning of +the continuous state space among several distinct vector fields has traditionally been a difficult problem for validation and verification. The discontinuity of the vector fields at discrete state interfaces makes reachability analysis computationally expensive, and analytic solutions often -become intractable \cite{MANYUS THESIS}. +become intractable \cite{kapuria_using_2025, lang_formal_2021}. We circumvent these issues by designing our hybrid system from the bottom up with verification in mind. Each continuous control mode has an input set and @@ -509,7 +399,7 @@ continuous controller design: These are derived from invariants \(Inv\). \end{enumerate} These sets come directly from the discrete controller synthesis and define -precise objectives for continuous control.\dasinline{This SOUNDS like +precise objectives for continuous control.\dasnote{This SOUNDS like assume-guarantee stuff. Maybe make that connection formal and cite it?} The continuous controller for mode $q_i$ must drive the system from any state in $\mathcal{X}_{entry,i}$ to some state in $\mathcal{X}_{exit,i}$ while @@ -522,34 +412,29 @@ verifying 6 components in isolation then system---your three-mode structure maps perfectly to this decomposition, reducing verification complexity from curse of dimensionality.} -We classify continuous controllers into three types based on their -objectives: transitory, stabilizing, and expulsory.\splitnote{This -three-mode taxonomy is elegant --- maps verification tools to control -objectives cleanly.} Each type has distinct verification requirements that -determine which formal methods tools are appropriate. +We classify continuous controllers into three types based on their objectives: +transitory, stabilizing, and expulsory. Each type has distinct verification +requirements that determine which formal methods tools are appropriate. -%%% NOTES (Section 4): -% - Add figure showing the relationship between entry/exit/safety sets -% - Discuss how standard control techniques (LQR, MPC, PID) fit into this -% framework -% - Mention assume-guarantee reasoning for compositional verification - -% ---------------------------------------------------------------------------- -% 4.1 TRANSITORY MODES -% ---------------------------------------------------------------------------- +\dasinline{ + \begin{itemize} + \item Add figure showing the relationship between entry/exit/safety sets + \item Mention assume guarantee compositional stuff and how that fits in here + \end{itemize} +} \subsubsection{Transitory Modes} -Transitory modes are continuous controllers designed to move the plant from -one discrete operating condition to another. Their purpose is to execute -transitions: starting from entry conditions, reach exit conditions, and -maintain safety invariants throughout. Examples include power ramp-up -sequences, cooldown procedures, and load-following maneuvers. +Transitory modes are continuous controllers designed to move the plant from one +discrete operating condition to another. Their purpose is to execute +transitions: starting from entry conditions, reach exit conditions, and maintain +safety invariants throughout. Examples include but are not limited to power +ramp-up sequences, cooldown procedures, and load-following maneuvers. The control objective for a transitory mode can be stated formally. Given entry conditions $\mathcal{X}_{entry}$, exit conditions $\mathcal{X}_{exit}$, safety invariant $\mathcal{X}_{safe}$, and -closed-loop dynamics $\dot{x} = f(x, u(x))$, the controller must satisfy: +closed-loop dynamics $\dot{x} = f(x)$, the controller must satisfy: \[ \forall x_0 \in \mathcal{X}_{entry}: \exists T > 0: x(T) \in \mathcal{X}_{exit} \land \forall t \in [0,T]: x(t) \in \mathcal{X}_{safe} @@ -557,9 +442,9 @@ closed-loop dynamics $\dot{x} = f(x, u(x))$, the controller must satisfy: That is, from any valid entry state, the trajectory must eventually reach the exit condition without ever leaving the safe region. -Verification of transitory modes uses reachability analysis. Reachability +Verification of transitory modes will use reachability analysis. Reachability analysis computes the set of all states reachable from a given initial set -under the system dynamics. For a transitory mode to be valid, the reachable +under the system dynamics\dasnote{cite reachability tools here}. For a transitory mode to be valid, the reachable set from $\mathcal{X}_{entry}$ must satisfy two conditions: \begin{enumerate} \item The reachable set eventually intersects $\mathcal{X}_{exit}$ (the @@ -575,12 +460,12 @@ states reachable within time horizon $T$: \mathcal{X}_{exit} \neq \emptyset \] -\textcolor{blue}{Because the discrete controller defines clear boundaries in +Because the discrete controller defines clear boundaries in continuous state space, the verification problem for each transitory mode is well-posed. We know the possible initial conditions, we know the target conditions, and we know the safety envelope. The verification task is to confirm that the candidate continuous controller achieves the objective from -all possible starting points.} +all possible starting points. Several tools exist for computing reachable sets of hybrid systems, including CORA, Flow*, SpaceEx, and JuliaReach. The choice of tool depends on the @@ -608,21 +493,17 @@ verification, reducing complexity from monolithic analysis.} % - Mention that the Mealy machine perspective unifies this: continuous system % IS the transition, entry/exit conditions are the discrete states -% ---------------------------------------------------------------------------- -% 4.2 STABILIZING MODES -% ---------------------------------------------------------------------------- - \subsubsection{Stabilizing Modes} Stabilizing modes are continuous controllers with an objective of maintaining a particular discrete state indefinitely. Rather than driving the system -toward an exit \oldt{condition,} \newt{state,}\dasinline{``mode'' --- -``condition'' here sounds goofy.} they keep the system within a safe +toward an exit state, they keep the system within a safe operating region. Examples include steady-state power operation, hot standby, and load-following at constant power level. Reachability analysis for stabilizing modes may not be a suitable approach to validation. Instead, we plan to use barrier certificates. Barrier certificates analyze the dynamics -of the system to determine whether flux across a given boundary exists. They +of the system to determine whether flux across a given boundary +exists\dasnote{cite barrier certificate stuff here}. In other words, they evaluate whether any trajectory leaves a given boundary. This definition is exactly what defines the validity of a stabilizing continuous control mode. @@ -646,16 +527,16 @@ this condition holds, no trajectory starting inside $\mathcal{C}$ can ever leave. Because the design of the discrete controller defines careful boundaries in -continuous state space, the barrier is known prior to designing the -continuous controller. This eliminates the search for an appropriate barrier -and minimizes complication in validating stabilizing continuous control -modes. The discrete specifications tell us what region must be invariant; the -barrier certificate confirms that the candidate controller achieves this -invariance. +continuous state space, the barrier \(\mathcal{C}\) is known prior to designing +the continuous controller. This eliminates the search for an appropriate barrier +and minimizes complication in validating stabilizing continuous control modes. +The discrete specifications tell us what region must be invariant; the barrier +certificate confirms that the candidate controller achieves this invariance. Finding barrier certificates can be formulated as a sum-of-squares (SOS) optimization problem for polynomial systems, or solved using satisfiability -modulo theories (SMT) solvers for broader classes of dynamics. The key +modulo theories (SMT) solvers for broader classes of dynamics\dasnote{cite these +here}. The key advantage is that the verification is independent of how the controller was designed. Standard control techniques can be used to build continuous controllers, and barrier certificates provide a separate check that the @@ -693,26 +574,20 @@ potentially anywhere in the state space, under degraded or uncertain dynamics. Examples include emergency core cooling, reactor SCRAM sequences, and controlled depressurization procedures. -We can detect that physical failures exist because our physical controllers -have been previously proven correct by reachability and barrier certificates. -We know our controller cannot be incorrect for the nominal plant model, so -if an invariant is violated, we know the plant dynamics have -changed. \oldt{The HAHACS can identify that a fault occurred because a -discrete boundary condition was violated by the continuous physical -controller.} \newt{}\dasinline{This says the same thing as the sentence -right before it.} This is a direct consequence of having verified the -nominal continuous control modes: unexpected behavior implies off-nominal -conditions. +We can detect that physical failures exist because our physical controllers have +been previously proven correct by reachability and barrier certificates. We know +our controller cannot be incorrect for the nominal plant model, so if an +invariant is violated, we know the plant dynamics have changed. The mathematical +formulation for expulsory mode verification differs from transitory modes in two +key ways. First, the entry conditions may be the entire state space (or a large, +conservatively bounded region) rather than a well-defined entry set. The failure +may occur at any point during operation. Second, the dynamics include parametric +uncertainty representing failure modes: -The mathematical formulation for expulsory mode verification differs from -transitory modes in two key ways. First, the entry conditions may be the -entire state space (or a large, conservatively bounded region) rather than a -well-defined entry set. The failure may occur at any point during operation. -Second, the dynamics include parametric uncertainty representing failure -modes: \[ \dot{x} = f(x, u, \theta), \quad \theta \in \Theta_{failure} \] + where $\Theta_{failure}$ captures the range of possible degraded plant% \splitsuggest{GAP: None of the NEEDS\_REVIEWED papers directly address reachability with parametric uncertainty for failure mode analysis. SpaceEx @@ -778,28 +653,16 @@ reliability requirements. The discrete automaton produced by reactive synthesis will be compiled to run on Ovation controllers, with verification that the implemented behavior matches the synthesized specification exactly. -For the continuous dynamics, we will use a small modular reactor -simulation.\dasinline{Are we REALLY going to do this? Maybe not.} The SmAHTR -(Small modular Advanced High Temperature Reactor) model provides a relevant -testbed for startup and shutdown procedures. The ARCADE (Advanced Reactor -Control Architecture Development Environment) interface will establish -communication between the Emerson Ovation hardware and the reactor -simulation, enabling hardware-in-the-loop testing of the complete hybrid -controller. +For the continuous dynamics, we will use a small modular reactor simulation. The +SmAHTR (Small modular Advanced High Temperature Reactor) model provides a +relevant testbed for startup and shutdown procedures. The ARCADE (Advanced +Reactor Control Architecture Development Environment) interface will establish +communication between the Emerson Ovation hardware and the reactor simulation, +enabling hardware-in-the-loop testing of the complete hybrid controller. -\oldt{Working with Emerson on such an implementation is an incredible -advantage for the success and impact of this work. We will directly address -the gap of verification and validation methods for these systems and industry -adoption by forming a two-way exchange of knowledge between the laboratory -and commercial environments. This work stands to be successful with Emerson -implementation because we will have access to system experts at Emerson to -help with the fine details of using the Ovation system. At the same time, we -will have the benefit of transferring technology directly to industry with a -direct collaboration in this research, while getting an excellent perspective -of how our research outcomes can align best with customer needs.} -\newt{The Emerson collaboration strengthens this work in two ways. Access to +The Emerson collaboration strengthens this work in two ways. Access to system experts at Emerson ensures that implementation details of the Ovation -platform are handled correctly. Direct industry collaboration provides an +platform are handled correctly. Direct industry collaboration also provides an immediate pathway for technology transfer and alignment with practical deployment requirements.}\splitnote{Kapuria 2025 validates hybrid control on SmAHTR: formal verification (d$\mathcal{L}$ + reachability, pp.37-70) proved diff --git a/4-metrics-of-success/metrics.tex b/4-metrics-of-success/metrics.tex index a91d709..e8c23a5 100644 --- a/4-metrics-of-success/metrics.tex +++ b/4-metrics-of-success/metrics.tex @@ -1,41 +1,17 @@ \section{Metrics for Success} This research will be measured by advancement through Technology Readiness -Levels, progressing from fundamental concepts to validated prototype -demonstration. This work begins at TRL 2--3 and aims to reach TRL 5, where -system components operate successfully in a relevant laboratory -environment.\splitnote{TRL as primary metric is smart — speaks industry -language.} -This section explains why TRL advancement provides the most appropriate -success metric and defines the specific criteria required to achieve TRL 5. - -\oldt{Technology Readiness Levels provide the ideal success metric because -they explicitly measure the gap between academic proof-of-concept and -practical deployment---precisely what this work aims to bridge. Academic -metrics like papers published or theorems proved cannot capture practical -feasibility. Empirical metrics like simulation accuracy or computational -speed cannot demonstrate theoretical rigor. TRLs measure both dimensions -simultaneously.} \newt{TRLs measure the gap between academic -proof-of-concept and practical deployment, which is precisely what this work -aims to bridge. Academic metrics alone cannot capture practical feasibility, -and empirical metrics alone cannot demonstrate theoretical rigor. TRLs -measure both simultaneously.}\dasinline{Chop. No likey.}\splitnote{Good -framing — explains why other metrics are insufficient.} Advancing from TRL 3 -to TRL 5 requires maintaining theoretical rigor while progressively -demonstrating practical feasibility. Formal verification must remain valid as -the system moves from individual components to integrated hardware testing. - -The nuclear industry requires extremely high assurance before deploying new -control technologies. Demonstrating theoretical correctness alone is -insufficient for adoption; conversely, showing empirical performance without -formal guarantees fails to meet regulatory requirements. TRLs capture this -dual requirement naturally. Each level represents both increased practical -maturity and sustained theoretical validity. Furthermore, TRL assessment -forces explicit identification of remaining barriers to deployment. The -nuclear industry already uses TRLs for technology assessment, making this -metric directly relevant to potential adopters. Reaching TRL 5 provides a -clear answer to industry questions about feasibility and maturity that -academic publications alone cannot. +Levels (TRL), progressing from fundamental concepts to validated prototype +demonstration. TRLs measure the gap between academic proof-of-concept and +practical deployment, which is precisely what this work aims to bridge. Academic +metrics alone cannot capture practical feasibility, and empirical metrics alone +cannot demonstrate theoretical rigor. TRLs measure both simultaneously. This +work begins at TRL 2--3 and aims to reach TRL 5, where system components operate +successfully in a relevant laboratory environment. This section explains why TRL +advancement provides the most appropriate success metric and defines the +specific criteria required to achieve TRL 5. Reaching TRL 5 provides a clear +answer to industry questions about feasibility and maturity that academic +publications alone cannot. Moving from current state to target requires achieving three intermediate levels, each representing a distinct validation milestone: @@ -66,26 +42,23 @@ be maintained throughout system integration. \paragraph{TRL 5 \textit{Laboratory Testing in Relevant Environment}} For this research, TRL 5 means demonstrating the verified controller on -industrial control hardware through hardware-in-the-loop testing. The -discrete automaton must be implemented on the Emerson Ovation control system -and verified to match synthesized specifications exactly. Continuous -controllers must execute at required rates. The ARCADE interface must -establish stable real-time communication between the Emerson Ovation hardware -and SmAHTR simulation. Complete autonomous startup sequences must execute via -hardware-in-the-loop across the full operational envelope. The controller -must handle off-nominal scenarios to validate that expulsory modes function -correctly. For example, simulated sensor failures must trigger appropriate -fault detection and mode transitions, and loss-of-cooling scenarios must -activate SCRAM procedures as specified. Graded responses to minor -disturbances are outside this work's scope\oldt{.}\newt{, as they require -runtime optimization under uncertainty that extends beyond the -correct-by-construction verification framework presented -here.}\splitsuggest{Consider noting why graded responses are out of scope — -is it time, complexity, or scope creep? Brief justification helps.} Formal +industrial control hardware through hardware-in-the-loop testing. The discrete +automaton must be implemented on the Emerson Ovation control system and verified +to match synthesized specifications exactly. Continuous controllers must execute +at required rates. The ARCADE interface must establish stable real-time +communication between the Emerson Ovation hardware and SmAHTR simulation. +Complete autonomous startup sequences must execute via hardware-in-the-loop +across the full operational envelope. The controller must handle off-nominal +scenarios to validate that expulsory modes function correctly. For example, +simulated sensor failures must trigger appropriate fault detection and mode +transitions, and loss-of-cooling scenarios must activate SCRAM procedures as +specified. Graded responses to minor disturbances are outside this work's scope, +as they require runtime optimization under uncertainty that extends beyond the +correct-by-construction verification framework presented here. Formal verification results must remain valid, with discrete behavior matching specifications and continuous trajectories remaining within verified bounds. -This proves that the methodology produces verified controllers implementable -on industrial hardware. +This proves that the methodology produces verified controllers implementable on +industrial hardware. Progress will be assessed quarterly through collection of specific data comparing actual results against TRL advancement criteria. Specification @@ -99,5 +72,4 @@ operating on industrial control hardware through hardware-in-the-loop testing in a relevant laboratory environment. This establishes both theoretical validity and practical feasibility, proving that the methodology produces verified controllers and that implementation is achievable with -current technology.\splitnote{Clear success criteria. Committee will know -exactly what ``done'' looks like.} +current technology. diff --git a/5-risks-and-contingencies/risks.tex b/5-risks-and-contingencies/risks.tex index 2a40d46..a92cd19 100644 --- a/5-risks-and-contingencies/risks.tex +++ b/5-risks-and-contingencies/risks.tex @@ -2,8 +2,7 @@ This research relies on several critical assumptions that, if invalidated, would require scope adjustment or methodological -revision.\splitnote{Honest acknowledgment of risks with clear contingencies -— committee will appreciate this.} The primary risks to successful +revision. The primary risks to successful completion fall into four categories: computational tractability of synthesis and verification, complexity of the discrete-continuous interface, completeness of procedure formalization, and hardware-in-the-loop integration @@ -31,9 +30,8 @@ problems. Synthesis times exceeding 24 hours for simplified procedure subsets would suggest complete procedures are intractable. Generated automata containing more than 1,000 discrete states would indicate the discrete state space is too large for efficient verification. Specifications flagged as -unrealizable by \oldt{FRET or Strix} \newt{realizability checking -tools}\dasinline{Strix may not be the reactive synth tool anymore. Be more -general.} would reveal fundamental conflicts in the formalized procedures. +unrealizable by realizability checking +tools would reveal fundamental conflicts in the formalized procedures. Reachability analysis failing to converge within reasonable time bounds would show that continuous mode verification cannot be completed with available computational resources. @@ -51,22 +49,19 @@ as a constraint rather than a failure. \subsection{Discrete-Continuous Interface Formalization} The second critical assumption concerns the mapping between boolean guard -conditions in temporal logic and continuous state boundaries required for -mode transitions. This interface represents the fundamental challenge of -hybrid systems: relating discrete switching logic to continuous dynamics. -Temporal logic operates on boolean predicates, while continuous control -requires reasoning about differential equations and reachable sets. -\oldt{Guard conditions requiring complex nonlinear predicates may resist -boolean abstraction, making synthesis intractable.} \newt{Some guard -conditions may require complex nonlinear predicates that cannot be cleanly -expressed as boolean combinations of simple threshold checks, making -synthesis intractable.}\dasinline{What does this mean?} Continuous safety -regions that cannot be expressed as conjunctions of verifiable constraints -would similarly create insurmountable verification challenges. The risk -extends beyond static interface definition to dynamic behavior across -transitions: barrier certificates may fail to exist for proposed transitions, -or continuous modes may be unable to guarantee convergence to discrete -transition boundaries. +conditions in temporal logic and continuous state boundaries required for mode +transitions. This interface represents the fundamental challenge of hybrid +systems: relating discrete switching logic to continuous dynamics. Temporal +logic operates on boolean predicates, while continuous control requires +reasoning about differential equations and reachable sets. Some guard conditions +may require complex nonlinear predicates that cannot be cleanly expressed as +boolean combinations of simple threshold checks, making synthesis intractable. +Continuous safety regions that cannot be expressed as conjunctions of verifiable +constraints would similarly create insurmountable verification challenges. The +risk extends beyond static interface definition to dynamic behavior across +transitions: barrier certificates may fail to exist for proposed transitions, or +continuous modes may be unable to guarantee convergence to discrete transition +boundaries. Early indicators of interface formalization problems would appear during both synthesis and verification phases. Guard conditions requiring complex diff --git a/6-broader-impacts/impacts.tex b/6-broader-impacts/impacts.tex index 4f3f097..c534b08 100644 --- a/6-broader-impacts/impacts.tex +++ b/6-broader-impacts/impacts.tex @@ -76,6 +76,5 @@ control, aerospace systems, and autonomous transportation, where similar economic and safety considerations favor increased autonomy with provable correctness guarantees. Demonstrating this approach in nuclear power---one of the most regulated and safety-critical -domains\splitnote{``If it works here, it works anywhere — strong closing -argument.}---will establish both the technical feasibility and regulatory +domains---will establish both the technical feasibility and regulatory pathway for broader adoption across critical infrastructure. diff --git a/dane_proposal_format.cls b/dane_proposal_format.cls index a25a243..0af36be 100644 --- a/dane_proposal_format.cls +++ b/dane_proposal_format.cls @@ -102,7 +102,8 @@ \newcommand{\bb}[1]{\mathbb{#1}} % blackboard bold (ℝ, ℚ, etc.) % Default document metadata (can be overridden) -\title{From Cold Start to Critical:\\ Formal Synthesis of Autonomous Hybrid Controllers} +\title{From Cold Start to Critical:\\ Synthesis of High Assurance Hybrid +Autonomous Control Systems} \author{% PI: Dane A. Sabo\\ dane.sabo@pitt.edu\\