M .task/backlog.data M .task/completed.data M .task/pending.data M .task/undo.data A PLAN_OF_STUDY_111225.pdf R Writing/202510270-Emerson-Pres/SaboOneSlide.pdf -> Presentations/202510270-Emerson-Pres/SaboOneSlide.pdf R Writing/202510270-Emerson-Pres/beamerthemedane.sty -> Presentations/202510270-Emerson-Pres/beamerthemedane.sty R Writing/202510270-Emerson-Pres/beamerthemedane_native.sty -> Presentations/202510270-Emerson-Pres/beamerthemedane_native.sty
371 lines
14 KiB
Markdown
371 lines
14 KiB
Markdown
# Presentation Outline: Formally Verified Autonomous Hybrid Control for Nuclear Reactors
|
||
|
||
**Audience:** Engineering PhDs (not necessarily control, nuclear, or formal methods experts)
|
||
|
||
**Presentation Style:** Assertion-Evidence
|
||
|
||
---
|
||
|
||
## 1. Title Slide
|
||
**Assertion:** Autonomous Hybrid Control with Formal Safety Guarantees Enables Economic Viability of Next-Generation Nuclear Power
|
||
|
||
**Content:**
|
||
- Your name, affiliation
|
||
- Brief subtitle about bridging formal methods and control theory
|
||
|
||
---
|
||
|
||
## 2. The Economic Challenge
|
||
**Assertion:** Small modular reactors face an unsustainable staffing cost problem that threatens their economic viability
|
||
|
||
**Evidence:**
|
||
- Comparison chart: staffing costs per MW for conventional vs SMR
|
||
- Current requirement: 2+ ROs + 1 SRO per reactor
|
||
- Training timeline: up to 6 years to become a reactor operator
|
||
- Cost breakdown showing O&M as 23-30% of levelized cost
|
||
- Projected datacenter demand reaching 1,050 TWh by 2030 = $21-28B annually in O&M
|
||
|
||
**Key Message:** Automation is not optional—it's economically essential
|
||
|
||
---
|
||
|
||
## 3. The Safety Imperative
|
||
**Assertion:** Human operators are the root cause of 70-80% of nuclear incidents despite decades of training improvements
|
||
|
||
**Evidence:**
|
||
- Bar chart: 70-80% human error vs 20% equipment failure
|
||
- IAEA statement: "Human error was the root cause of all severe accidents"
|
||
- TMI case study visualization:
|
||
- 100+ simultaneous alarms
|
||
- 44% core meltdown
|
||
- 500-fold underestimation of risk
|
||
- Human Error Probability table showing degradation under stress:
|
||
- Optimal: 0.001-0.01
|
||
- Under accident conditions: 0.1-1.0 (essentially guaranteed failure)
|
||
|
||
**Key Message:** Training alone cannot overcome fundamental cognitive limitations
|
||
|
||
---
|
||
|
||
## 4. The Paradox
|
||
**Assertion:** Nuclear control faces a fundamental tension—human operators are both essential for flexibility and the primary source of failure
|
||
|
||
**Evidence:**
|
||
- Two-column comparison:
|
||
- LEFT: "Why we need humans" (judgment, adaptability, procedure interpretation)
|
||
- RIGHT: "Why humans fail" (cognitive limits, stress, 7±2 working memory, response time: seconds vs milliseconds)
|
||
- Current division of labor diagram:
|
||
- Automated: Emergency protection (trip systems, ECCS)
|
||
- Manual: Strategic operations (startup, mode transitions, power changes)
|
||
- Quote from TMI Commission about "ambiguity in responsibility"
|
||
|
||
**Key Message:** We need the reliability of automation with the sophistication of human decision-making
|
||
|
||
---
|
||
|
||
## 5. What Are Hybrid Control Systems?
|
||
**Assertion:** Hybrid systems combine continuous dynamics with discrete mode switching—exactly how nuclear plants operate
|
||
|
||
**Evidence:**
|
||
- Simple equations showing hybrid dynamics:
|
||
- Continuous: ẋ(t) = f(x(t), q(t), u(t))
|
||
- Discrete: q(k+1) = ν(x(k), q(k), u(k))
|
||
- Intuitive example diagram: Nuclear reactor startup
|
||
- Mode 1 (Cold Shutdown): Temperature control
|
||
- Transition condition: T > 400°F
|
||
- Mode 2 (Heatup): Ramp rate control
|
||
- Transition condition: Approach criticality
|
||
- Mode 3 (Low Power): Neutron flux control
|
||
- Contrast with pure continuous (traditional control) and pure discrete (software)
|
||
|
||
**Key Message:** Nuclear operations are inherently hybrid—continuous physics with discrete strategic decisions
|
||
|
||
---
|
||
|
||
## 6. The Gap in Current Approaches
|
||
**Assertion:** Existing methods can handle either continuous dynamics or discrete logic, but not both with formal guarantees
|
||
|
||
**Evidence:**
|
||
- Venn diagram showing the gap:
|
||
- Circle 1: Formal Methods (HARDENS) → Discrete logic verification ✓, Continuous dynamics ✗
|
||
- Circle 2: Control Theory → Continuous stability ✓, Discrete transitions ✗
|
||
- Gap in middle: Hybrid system verification
|
||
- HARDENS achievement summary:
|
||
- Complete RTS verification in 9 months
|
||
- Requirements → verified binaries
|
||
- BUT: No continuous dynamics, no closed-loop verification
|
||
- TRL 3-4, no experimental validation
|
||
|
||
**Key Message:** We can verify half the system with existing tools—we need to bridge the gap
|
||
|
||
---
|
||
|
||
## 7. Our Three-Thrust Approach
|
||
**Assertion:** Unifying discrete synthesis and continuous verification enables end-to-end correctness guarantees for hybrid systems
|
||
|
||
**Evidence:**
|
||
- Pipeline diagram with three stages:
|
||
|
||
**Thrust 1:** Procedures → Temporal Logic (FRET)
|
||
- Input: Written procedures
|
||
- Tool: NASA FRET (FRETish language)
|
||
- Output: LTL specifications
|
||
- Key feature: Realizability checking
|
||
|
||
**Thrust 2:** Temporal Logic → Discrete Automaton (Reactive Synthesis)
|
||
- Input: LTL specifications
|
||
- Tool: Strix (reactive synthesis)
|
||
- Output: Discrete state machine
|
||
- Key feature: Correct by construction
|
||
|
||
**Thrust 3:** Continuous Controllers + Verification
|
||
- Input: Discrete automaton + plant model
|
||
- Tools: Reachability analysis, barrier certificates
|
||
- Output: Verified continuous modes
|
||
- Key feature: Compositional verification
|
||
|
||
**Key Message:** Each piece uses state-of-the-art tools; innovation is in the integration
|
||
|
||
---
|
||
|
||
## 8. Thrust 1: From Procedures to Logic
|
||
**Assertion:** NASA's FRET tool systematically translates written procedures into unambiguous temporal logic specifications
|
||
|
||
**Evidence:**
|
||
- Side-by-side example:
|
||
- LEFT: Natural language: "If a high temperature alarm triggers, control rods must immediately insert and remain inserted until operator reset"
|
||
- RIGHT: Temporal logic: G(HighTemp → X(RodsInserted ∧ (¬RodsWithdrawn U OperatorReset)))
|
||
- FRETish structure diagram showing 6 required components:
|
||
- Scope | Condition | Component | Shall | Timing | Response
|
||
- Realizability checking benefits:
|
||
- Detects conflicting requirements
|
||
- Identifies undefined behaviors
|
||
- Finds "bugs" in procedures before implementation
|
||
|
||
**Key Message:** FRET bridges human-readable procedures and machine-verifiable specifications
|
||
|
||
---
|
||
|
||
## 9. Thrust 2: Synthesizing Discrete Controllers
|
||
**Assertion:** Reactive synthesis automatically generates provably correct discrete switching logic from temporal specifications
|
||
|
||
**Evidence:**
|
||
- What is reactive synthesis? Simple explanation:
|
||
- Input: Temporal logic formula (what should happen)
|
||
- Output: State machine (how to make it happen)
|
||
- Guarantee: If a solution exists, it is correct by construction
|
||
- Example automaton visualization for reactor mode transitions
|
||
- Nodes: Cold Shutdown, Heatup, Low Power, Full Power, SCRAM
|
||
- Edges: Transition conditions
|
||
- Highlight: This is the "operator's decision-making" automated
|
||
- Strix tool performance (SYNTCOMP winner)
|
||
|
||
**Key Message:** The discrete controller is mathematically guaranteed to follow procedures—no switching errors possible
|
||
|
||
---
|
||
|
||
## 10. Thrust 3: Continuous Mode Verification
|
||
**Assertion:** Continuous controllers are verified using three complementary techniques that avoid global trajectory analysis
|
||
|
||
**Evidence:**
|
||
- Three types of continuous modes based on transition objectives:
|
||
- **Stabilizing:** Stay in current mode (e.g., full-power operation)
|
||
- **Transitory:** Drive toward next mode (e.g., startup heatup)
|
||
- **Expulsory:** Force to safe mode (e.g., SCRAM)
|
||
- Three verification techniques:
|
||
|
||
1. **Reachability Analysis:**
|
||
- Computes reachable state sets
|
||
- Verifies boundary conditions are met
|
||
- Recent advances: Neural Hamilton-Jacobi for high dimensions
|
||
|
||
2. **Assume-Guarantee Contracts:**
|
||
- Each mode verified with input/output bounds
|
||
- Compositional: local verification, global guarantees
|
||
|
||
3. **Barrier Certificates:**
|
||
- Proves safe set forward invariance
|
||
- Guarantees transitions occur correctly
|
||
- Ensures stability across mode switches
|
||
|
||
**Key Message:** Local verification of each mode is tractable; composition ensures global correctness
|
||
|
||
---
|
||
|
||
## 11. Why This Works: The Key Insight
|
||
**Assertion:** Designing continuous controllers after synthesizing the discrete automaton enables local verification instead of intractable global analysis
|
||
|
||
**Evidence:**
|
||
- Problem with traditional approach:
|
||
- Design everything at once
|
||
- Verify entire trajectory through all modes
|
||
- Computationally intractable for complex systems
|
||
- Our approach:
|
||
- Discrete automaton defines transition boundaries
|
||
- Design each continuous mode to satisfy its local transitions
|
||
- Use assume-guarantee to chain modes together
|
||
- Barrier certificates prove transitions are safe
|
||
- Diagram showing modular verification:
|
||
- Each mode verified independently
|
||
- Interface contracts guarantee composition
|
||
- Total system correctness follows from local proofs
|
||
|
||
**Key Message:** Decomposition is the key to tractable verification
|
||
|
||
---
|
||
|
||
## 12. Demonstration: SmAHTR Startup
|
||
**Assertion:** Autonomous startup of a Small Modular Advanced High Temperature Reactor provides a rigorous test case spanning multiple coordinated modes
|
||
|
||
**Evidence:**
|
||
- Why SmAHTR?
|
||
- Well-documented startup procedures
|
||
- Multiple distinct operational modes
|
||
- Complex thermal-hydraulics + neutron kinetics
|
||
- Representative of next-gen reactor designs
|
||
- Startup sequence complexity:
|
||
- Cold conditions → Controlled heating → Approach criticality → Low-power physics → Full power
|
||
- Multiple coordinated subsystems
|
||
- Strict timing and temperature constraints
|
||
- Implementation platform:
|
||
- High-fidelity Simulink model (thermal-hydraulics + neutron kinetics)
|
||
- Emerson Ovation control hardware (industry standard)
|
||
- ARCADE integration (hardware-in-the-loop)
|
||
- Real-time performance validation
|
||
|
||
**Key Message:** This is not a toy problem—it's representative of actual deployment challenges
|
||
|
||
---
|
||
|
||
## 13. Expected Outcomes
|
||
**Assertion:** Success will be measured by progression to TRL 5, demonstrating practical feasibility beyond theoretical proof
|
||
|
||
**Evidence:**
|
||
- TRL progression chart:
|
||
- Starting point: TRL 2-3 (basic concepts, HARDENS as precedent)
|
||
- Target: TRL 5 (validated prototype in relevant environment)
|
||
- Gap: Experimental validation with continuous dynamics
|
||
- Three concrete deliverables:
|
||
|
||
**Outcome 1:** Procedure translation methodology
|
||
- Engineers can generate verified controllers from regulatory procedures
|
||
- No formal methods expertise required
|
||
|
||
**Outcome 2:** Continuous verification framework
|
||
- Standard control design + iterative verification
|
||
- Proof of safe mode transitions
|
||
|
||
**Outcome 3:** SmAHTR demonstration
|
||
- Autonomous startup on industrial hardware
|
||
- Hardware-in-the-loop validation
|
||
- Path to deployment
|
||
|
||
**Key Message:** TRL 5 proves both theoretical validity and practical implementability
|
||
|
||
---
|
||
|
||
## 14. Broader Impact: Beyond Nuclear
|
||
**Assertion:** This methodology generalizes to any safety-critical hybrid system with documented operational procedures
|
||
|
||
**Evidence:**
|
||
- Common pattern across domains:
|
||
- Written procedures exist
|
||
- Continuous dynamics + discrete decisions
|
||
- Safety is paramount
|
||
- Autonomy has economic benefits
|
||
- Application domains table:
|
||
- Chemical process control (batch processes, safety interlocks)
|
||
- Aerospace (flight phases, emergency procedures)
|
||
- Autonomous transportation (driving modes, emergency maneuvers)
|
||
- Medical devices (therapy modes, patient monitoring)
|
||
- Economic multiplier:
|
||
- Nuclear O&M: $21-28B annually (projected datacenter demand alone)
|
||
- Broader safety-critical infrastructure: Much larger
|
||
- Regulatory pathway:
|
||
- Proving concept in nuclear (highest safety bar)
|
||
- Establishes precedent for other industries
|
||
- Mathematical proof as regulatory evidence
|
||
|
||
**Key Message:** Nuclear is the proving ground; impact extends far beyond
|
||
|
||
---
|
||
|
||
## 15. Innovation Summary
|
||
**Assertion:** The innovation is not in individual techniques but in their systematic integration to bridge a fundamental gap in cyber-physical systems
|
||
|
||
**Evidence:**
|
||
- What's NOT new (but state-of-the-art):
|
||
- Temporal logic and reactive synthesis (computer science)
|
||
- Reachability analysis and barrier certificates (control theory)
|
||
- Hardware-in-the-loop validation (industry practice)
|
||
- What IS new:
|
||
- **Integration:** Unifying discrete and continuous verification
|
||
- **Methodology:** Systematic tool-supported workflow from procedures to verified controller
|
||
- **Decomposition:** Local verification with compositional guarantees
|
||
- **Practical:** Targets existing industrial hardware (Emerson Ovation)
|
||
- Comparison to HARDENS:
|
||
- HARDENS: Discrete only, TRL 3-4, no continuous dynamics
|
||
- This work: Full hybrid system, TRL 5, hardware-in-the-loop
|
||
- Key enabling insight:
|
||
- Automaton-first design enables tractable continuous verification
|
||
|
||
**Key Message:** Standing on the shoulders of giants to solve a previously intractable problem
|
||
|
||
---
|
||
|
||
## 16. Timeline and Feasibility
|
||
**Assertion:** This research is feasible within a PhD timeline given existing tools, models, and infrastructure access
|
||
|
||
**Evidence:**
|
||
- Existing infrastructure:
|
||
- University of Pittsburgh Cyber Energy Center
|
||
- Emerson control hardware access
|
||
- SmAHTR Simulink model already developed
|
||
- ARCADE platform operational
|
||
- Industry collaboration channels
|
||
- Tool maturity:
|
||
- FRET: Production-ready (NASA JPL)
|
||
- Strix: Competition-winning synthesis tool
|
||
- Reachability tools: Recent advances make high-dimensional systems tractable
|
||
- Risk mitigation:
|
||
- Start with simpler mode sequences, add complexity incrementally
|
||
- Extensive simulation before hardware-in-the-loop
|
||
- Fallback: Manual continuous controller design if synthesis proves intractable
|
||
- Precedent: HARDENS achieved similar scope in 9 months
|
||
|
||
**Key Message:** Ambitious but achievable with existing resources and tools
|
||
|
||
---
|
||
|
||
## 17. Conclusion: The Path Forward
|
||
**Assertion:** Formally verified autonomous hybrid control is essential for next-generation nuclear power and provides a template for broader safety-critical autonomy
|
||
|
||
**Evidence:**
|
||
- Three converging imperatives:
|
||
1. **Economic:** SMRs need autonomy to be viable ($21-28B annual O&M for datacenter demand)
|
||
2. **Safety:** Human error causes 70-80% of incidents; training can't fix cognitive limits
|
||
3. **Technical:** Tools now exist to verify hybrid systems; HARDENS proved discrete is feasible
|
||
- This research closes the gap:
|
||
- HARDENS + Continuous Verification = Complete Hybrid System
|
||
- Theory + Hardware-in-the-Loop = TRL 5
|
||
- Nuclear Demonstration = Pathway for broader adoption
|
||
- Vision: Control engineers generate high-assurance autonomous controllers from procedures
|
||
- No formal methods PhD required
|
||
- Mathematical proof of correctness included
|
||
- Deployable on existing industrial hardware
|
||
|
||
**Key Message:** The pieces exist; we're putting them together at the right time for the right application
|
||
|
||
---
|
||
|
||
## 18. Questions
|
||
**Assertion:** (Keep a few backup slides here for common questions)
|
||
|
||
Potential backup slides:
|
||
- Detailed FRET example
|
||
- Reactive synthesis algorithm overview
|
||
- Reachability analysis visualization
|
||
- Comparison with other autonomy approaches (ML, MPC, etc.)
|
||
- Regulatory acceptance pathway
|
||
- Scalability to larger systems
|