HC900-Crawler/docs/작업플랜-민감단온도-전환복귀제어.md

작업 플랜 — 민감단(T_C) 온도 유지 · 전환류 도피 · Bumpless 복귀 (2026-06-06)

진단 (2026-06-06, diagnosis-checklist.md 적용)

#	심각도	항목	근거	파일·라인
1	🟠 MED	기존 상태기계와의 통합 방향 미정의	계획은 T_C 이탈 중심 트리거를 제안하나, 기존 FeedforwardEngine.ApplyRecovery()(FeedforwardEngine.cs:400)는 imbalance(vloss/ΔP/front/tempSevere/sigTHigh) 중심으로 이미 ColumnMode{Normal,Recovering,Returning} 전이를 구현함. "enum 그대로 사용"(line 12)이라고만 하고 트리거 통합/대체/병렬 여부가 명시되지 않아 구현 시 양쪽 로직 충돌 위험. 교차검증 Q3: 의도적으로 모호할 수 있으나 상태기계 골격이 이미 가동 중이므로 반드시 정합 필요.	본문 §0, 대비 FeedforwardEngine.cs:400-486
2	🟡 LOW	TempLowLimit DB/Config 명세 부재	"하한 추가"(line 13)만 언급하고 구체적 Config 필드명·DB 컬럼·기본값·트리거 로직을 정의하지 않음. ColumnConfig.TempHighLimit(FeedforwardModels.cs:74)은 존재하나 TempLowLimit은 아직 없음. FeedforwardConfigStore.cs:89의 ordinal 31 이후로 추가 필요.	본문 §기존자산, 대비 FeedforwardModels.cs:74
3	🟡 LOW	복귀(Returning) 게이트 조건 불일치	계획(line 38)은 startup 컷인 트리거(reb-A 온도대역+ΔT(A-D) 안정)로 복귀 게이팅을 제안하나, 기존 코드(line 463-464)는 !severe && frac < ImbalanceTriggerFrac * 0.5(물질수지 회복)로 평가함. 서로 다른 회복 기준이 동일 상태기계에 적용될 가능성.	본문 §모듈3, 대비 FeedforwardEngine.cs:463-464
4	🟡 LOW	하강 램프 구현 현황과 계획 간 간격	계획(line 43)은 "FeedRampAdvisor에 하강 램프 추가(현재 상승만)"라고 명시했으나, FeedRampCalculator.Compute()(FeedRampCalculator.cs:87-88)는 down-ramp 분기를 warnings.Add만 하고 시간 0으로 처리. StreamConfig.RateDnPerMin(StreamConfig.cs:27)은 이미 존재하나 계산 로직에 미반영. 구체적 구현 방향(ComputeAsync 하강 분기, rate 선택 등)이 계획에 없음.	본문 §모듈4-A, 대비 FeedRampCalculator.cs:87-88
5	🟡 LOW	tempref 용어 정의 없음	line 25, 65에서 tempref를 참조하지만 문서 내 정의 없음. 이 문서만 읽으면 tempref가 DB 테이블인지, JSON 파일인지, API인지 식별 불가. c{prefix}_tempref.json은 gen_temp_profiles.py(scripts/analysis) 산출물이며 SteamAdvisorController.cs:183에서 로드됨. 동일 디렉토리 작업플랜-컬럼온도프로파일-이격모니터.md:21에 정의되어 있으므로 cross-reference 필요.	본문 line 25, 65
6	🟡 LOW	파라미터 미지정 (N분, rate, bandwidth)	"지속 N분"(line 32), "rate-limit 상승/하강"(line 34, 39), "T_C in-band 지속"(line 38)의 구체값·단위·기본값이 명시되지 않음. "hunting-averse"(line 66) 원칙과 배치되는 애매함. 단, 계획 문서의 초기 단계에서는 허용 가능한 수준(교차검증 Q3).	본문 §모듈2,3,4

교차검증 종합

• Q1 (이미 수정됨?) — 해당 없음 (plan 문서, 수정 대상 코드 아님)
• Q2 (다른 레이어 처리?) — #1은 기존 FeedforwardEngine이 이미 상태기계를 소유 중이므로 계획이 이를 오버라이드/확장할지 명시해야 함
• Q3 (의도적 설계?) — #5, #6은 계획 초기 단계의 자연스러운 애매함; #2는 TODO로 의도적이나 명세 누락
• Q4 (재현 시나리오?) — #1: FeedforwardEngine 활성화 + 이 계획 구현 시 Recovery 트리거 2중 평가로 전환류 진입/복귀 조건 충돌

---

온도 프로파일 모니터(작업플랜-컬럼온도프로파일-이격모니터.md)의 제어 확장. 메모리 §16.9(경량 트림), §17(온도프로파일=품질게이트). SteamAdvisor·FeedRampAdvisor 재활용.

큰 그림

민감단 T_C가 곧 품질·분리도 proxy. 목표: T_C를 목표대역에 유지 → 벗어나면 전환류로 도피 → 회복되면 bumpless 복귀. 상태기계: Normal → (T_C 이탈) Recovering(전환류) → (T_C 회복) Returning(복귀램프) → Normal. ★ColumnMode{Normal,Recovering,Returning} enum이 이미 FeedforwardModels에 존재 — 이 설계의 골격이 일부 깔려 있음.

기존 자산 연결 (중복금지)

• ColumnMode(Normal/Recovering/Returning) — 상태기계 enum 그대로 사용.
• TempHighLimit(전환류 트리거, FeedforwardModels) — 상한 트리거 이미 있음. 하한 추가.
• AdvisoryResult.TempProfileState(정상/약화/붕괴/역전/정착대기) — 이탈 판정 입력.
• SteamAdvisor steam=f(feed,product,T_C) 맵 — T_C 목표 역산·다변수 디커플링의 핵심.
• FeedRampAdvisor/FeedRampExecutorService — 유량 램프(상승). 하강 램프 추가 필요.
• startup 분석(c6111_startup) 컷인 트리거 reb-A 84.6±0.5℃ & ΔT(A-D) 1.9±0.4℃ — 복귀(Returning) 제품 재컷인 게이트로 재활용.

---

모듈 1 — T_C 유지 SP 제안 (Normal)

목적: T_C를 목표대역(예: 기준 median±0.5℃) 유지하는 조작변수 SP 제안. 물리: T_C = f(steam↑, feed↓, reflux↓, vacuum). 주 조작 = 리보일러 steam OP(=SteamAdvisor RecOp). 부하변수(feed/product) 변하면 T_C 흔들림 → steam으로 보상. 제안 로직:

1. 기준 T_C target = tempref 매칭제품 median(또는 운전원 설정).
2. 디커플링 feedforward: feed/product가 바뀌면 SteamAdvisor 맵으로 "그 부하에서 target T_C 유지하는 steam" 산출 → RecOp. (맵이 이미 T_C를 입력으로 학습 → target T_C 고정·부하 대입하면 필요 steam 역산).
3. 경량 트림 FB(§16.9): 잔차 e=T_C−target에 gain~−0.6, 데드밴드 0.1℃, dwell 20분(hunting-averse). 산출: STEAM OP SP 제안(작업지시서-STEAM-SP-FF통합과 연계) + T_C 편차 표시.

모듈 2 — 전환류(Recovering) 전환 트리거

목적: T_C가 목표대역 이탈(분리 악화) → 제품 차단·전량 환류로 도피. 트리거: T_C < 하한(또는 프로파일붕괴/역전, TempProfileState) 지속 N분 → Recovering 진입. 액션: product SP→0(컷오프), reflux 전량 환류(LINEOUT), steam 유지/소폭. = startup의 "전환류 라인아웃" 상태와 동일. 주의: 급변 금지 — product는 rate-limit 하강, steam 급강 금지(컬럼 식음 방지).

모듈 3 — 복귀(Returning) 모드

목적: 전환류 중 T_C가 목표대역 재진입 → 제품 재컷인 후 정상복귀. 게이트: ★startup 컷인 트리거 재활용 — reb-A 목표대역 & ΔT(A-D) 안정 & T_C in-band 지속 → 제품 재컷인 허용. 액션: product 컷인(rate-limit 상승) → feed 램프업(모듈4) → 안정되면 Normal.

모듈 4 — Bumpless 램프 (핵심)

목적: 모드 전환·복귀 시 OP/유량 점프 없이, 민감단 T_C 불변 제약 하 유량 램프. 4-A 온도 램프: FeedRampAdvisor에 하강 램프 추가(현재 상승만). reb-A/T_C 목표를 현재값에서 target까지 rate-limit(℃/min) 궤적. bumpless=현재 PV에서 출발. 4-B 유량 협조 램프(T_C 유지): feed(또는 reflux)를 램프할 때 T_C가 흔들리지 않게 steam을 동반 램프.

• feed 궤적 f(t) 각 스텝마다 SteamAdvisor 맵으로 "그 feed·target T_C 유지 steam" 산출 → steam OP 동반 궤적.
• 즉 feed↑ 매 스텝에 필요 steam↑를 맵에서 선제 적용(feedforward) → T_C 평탄.
• reflux 램프도 동일(reflux↑→냉각↑→steam 보상). 4-C Bumpless 보장: 모드 전환 순간 제안 OP = 현재 실제 OP에서 출발(초기오프셋 0), 이후 ramp. WriteGuard rate-limit으로 점프 차단.

---

상태기계 (요약)

Normal ──T_C 이탈(모듈2)──▶ Recovering(전환류)
  ▲                              │
  │                       T_C 회복+컷인게이트(모듈3)
  │                              ▼
  └────정상 안정──── Returning(복귀 bumpless 램프, 모듈4)

ColumnMode enum으로 구현. 각 전이에 dwell·rate-limit·운전원 승인(개별 follow).

안전/주의

• ★closed-loop는 advisory+개별 follow 기반(메모리: 조건 실변동중 자동제어 금물). 전 모드 advisory-only 우선, 운전원 인가 시 write.
• 전환류/복귀는 안전 시퀀스(급변 금지) — startup/shutdown 분석의 rate 보존.
• T_C target·대역은 tempref 기준 + 운전원 조정. 제품전환(bimodal) 시 target 재설정.
• hunting-averse: 데드밴드·dwell·rate-limit 필수.

검증

• 오프라인: field_hist에서 실제 전환류 에피소드(startup 펄스) 대비 상태기계 재현. 복귀 컷인 트리거 일치.
• shadow: Normal에서 모듈1 제안 OP vs 실제, T_C 유지 RMSE.
• 램프: feed 램프 구간에서 제안 steam 궤적이 T_C 평탄 유지하는지(맵 예측 vs 실측 T_C).

선행 의존

온도 프로파일 모니터(완료) · STEAM-SP-FF통합(steam OP 제안 경로) · FeedRampAdvisor 하강램프 확장.