docs: 안전 피드램프 advisory 설계 브레인스토밍 + 작업지시서

- docs/안전피드램프-한계치-브레인스토밍.md (§0~§10): C-6111 피드램프/듀티/드로우 advisory 설계 — 램프율·ceiling 공식, 자기조절 캐스케이드, 편차 trim 소스, 압력 서브시스템(pi-6111b/ΔP/PCT), tray 레이아웃(패킹 3구간), 온도 역전 판정 spec
- plans/안전피드램프-advisory-작업지시서.md: WP0 Sim Override + WP1 시나리오매트릭스 + WP2 현행엔진 프로빙 + WP3 FeedRampAdvisor 구현 지시 (다른 LLM 실행용)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/안전피드램프-한계치-브레인스토밍.md

@@ -0,0 +1,497 @@
+# 안전 피드 램프 · 운전 한계치 — 브레인스토밍
+
+> 2026-06-01, C-6111 PGMEA 측류 추출식 증류탑 기준
+> 상태: **보류(brainstorming)** — 구현 착수 전 헛점 검토 단계
+
+## 0. 배경 / 발단
+
+선행 논의에서 출발:
+1. FF의 LevelDriven 스트림(D=ficq-6114, B=ficq-6116)이 `recommendedSp = K×피드`를 **"권장 SP" 컬럼에 상승값으로 그대로 표시** → 운전원이 추종 시 *피드↑ → 레벨↑ → 드로우 SP↑ → 중비물(B) 일시 과추출* 을 시스템이 부추기는 구조라는 지적.
+2. "advisory라 안전"은 근거 없는 합리화 (advisory 라벨은 그 숫자의 타당성을 보증하지 않음).
+3. → **관점 전환**: "권장값을 어떻게 표시하나"가 아니라, **"피드를 평형 깨지 않고 얼마나·얼마나 빨리 올릴 수 있나"를 계산**하는 쪽으로.
+
+## 1. 문제 정의 — 두 개를 분리
+
+| | 정체 | 성격 | 예시 질문 |
+|---|------|------|-----------|
+| **한계치 (ceiling)** | 평형 깨지 않는 **최대 피드** | 정적 상한 (level) | "1100이 애초에 가능한가?" |
+| **RATE 한계치 (ramp)** | 900→1100을 얼마나 **빨리** | 동적 상한 (rate) | "몇 분에 걸쳐 올려야 안전한가?" |
+
+사용자 원안: 900 → 1100 (Δ=200), RATE LIMIT + 시간 고려한 **점진 SP 상승 안전 램프**.
+
+## 2. C-6111 실제 config (ff_stream_config, column_id=1)
+
+| 스트림 | flow_tag | 역할 | K | θ_up/dn | τ | sp_max | rate_up/dn (kg/hr·min) | level_tag |
+|--------|----------|------|-----|---------|------|--------|------------------------|-----------|
+| P | ficq-6118 | Commanded | 0.95 | 60/60 | **900** | 2000 | 30/60 | – |
+| R | ficq-6113 | Commanded | 0.80 | 0/0 | 0 | 2000 | 30/30 | – |
+| D | ficq-6114 | LevelDriven | 0.02 | – | – | 1000 | 0/0 | lica-6113 |
+| B | ficq-6116 | LevelDriven | 0.03 | – | – | 500 | 0/0 | li-6111 |
+
+피드 = ficq-6101. (K 합 P+D+B = 0.95+0.02+0.03 = 1.00 → 물질수지 폐합. R은 내부 환류.)
+
+## 3. 계산 프레임워크
+
+### 3.1 RATE 한계치 (램프율)
+
+램프율 `R_feed`(kg/hr per min)에 걸리는 두 제약 중 **작은 쪽**이 binding:
+
+**(a) 밸브 슬루 제약** — 각 commanded 드로우가 제 rate 한계 안에서 피드를 추종:
+```
+R_feed ≤ min_i( rate_up_i / K_i ) = min(30/0.95, 30/0.80) = 31.6 kg/hr·min  (P binding)
+→ 200 kg/hr 를 약 6.3분
+```
+
+**(b) 동적 불균형 제약** — P의 지연(τ=900s + θ=60s)이 만드는 물질수지 결손:
+```
+ΔI(결손, kg/hr) ≈ K_P · (τ_P + θ_P) · R_feed
+              = 0.95 · 960s · (R_feed/60)  ≈ 15.2 · R_feed[kg/hr·min]
+```
+이 결손이 컬럼에 누적 → 레벨 상승 → D·B 과추출. 허용 밴드 ΔI_allow로 역산:
+```
+R_feed ≤ ΔI_allow / 15.2
+  ΔI_allow = 50 kg/hr → R_feed ≤ 3.3 → 200kg/hr 에 약 60분
+  ΔI_allow = 100      → R_feed ≤ 6.6 → 약 30분
+```
+
+**핵심 결론**: 밸브 속도론 "6분"이지만, P의 15분 지연 때문에 내부 균형 유지 시 **~1시간 램프**가 맞다. binding은 (b) 동특성이지 (a) 밸브가 아니다. `ΔI_allow`는 운전원이 정하는 손잡이(= 허용 레벨 스윙/과추출량).
+
+### 3.2 한계치 (ceiling)
+
+**밸브 포화 상한** (config만으로):
+```
+feed_max = min_i( sp_max_i / K_i )
+  P: 2000/0.95 = 2105  ← binding
+  R: 2000/0.80 = 2500
+  D: 1000/0.02 = 50000
+  B:  500/0.03 = 16667
+→ 1100은 여유 충분 (P_sp=1045, R=880, D=22, B=33 모두 sp_max 이내)
+```
+단, **진짜 상한은 더 낮음** (라이브 데이터 필요):
+- **플러딩**: 내부 traffic ↑ → ΔP ↑. `DeltaPFloodLimit` 대비 투영
+- **리보일러/스팀**: `SteamOpTag` OP%가 포화(>~95%)하면 분리 붕괴
+
+### 3.3 엔진 통합 — 자기조절(self-throttling) 램프
+
+기존 FF 엔진은 "주어진 피드에서 각 스트림 기대치"를 이미 계산. 그 위에 **Feed Ramp Advisor**:
+1. 목표 피드 타당성 검사(ceiling) → 초과 시 클램프 + 제한 제약 보고
+2. (a)(b)로 R_feed 산출 → 궤적 `feed(t)=900+R_feed·t`
+3. 램프 중 레벨·ΔP·프론트 감시 → 밴드 접근 시 R_feed 자동 감속/정지
+
+---
+
+## 4. ⚠ 헛점 / 리스크 분석 (이 문서의 핵심)
+
+### A. 모델 신뢰성 헛점
+
+| # | 헛점 | 영향 | 비고 |
+|---|------|------|------|
+| A1 | **θ·τ가 실측인가 placeholder인가** | R_feed 전부가 이 값에 비례 → 틀리면 램프 전체 오류 | 특히 R의 θ=0/τ=0은 비현실(환류 즉답 가정). config가 추정치일 가능성 큼 → `CrossCorrLagEstimator` 실측으로 교체 필요 |
+| A2 | **1차 선형 lag 가정** | deficit 공식은 선형. 증류탑은 비선형(분리효율·게인이 부하 의존) | 22% step은 근사 OK일 수 있으나 큰 변화엔 부정확 |
+| A3 | **운전점 의존 K** | 램프 계산에 config K vs 실측 K_obs 어느 것? 운전점마다 다름 | K_obs MA 기능 이미 존재 → 그쪽 사용 검토 |
+
+### B. 모델이 빠뜨린 물리 (가장 위험)
+
+| # | 헛점 | 영향 | 비고 |
+|---|------|------|------|
+| B1 | **D·B 제약 미반영** | 정작 우려한 **과추출의 주체가 D·B level loop**인데, binding을 P commanded로만 계산. D·B의 rate_up=0(미설정) → 밸브 포화·레벨 루프 속도 한계가 모델에 없음 | **모순**: P 지연이 만든 결손을 D·B가 흡수(과추출)하는데 D·B 자체 한계는 무시 |
+| B2 | **에너지 동특성 누락** | 안전 램프 전제 = "피드 올릴 때 reboil/reflux도 비례 상승". R은 commanded지만 **리보일러/스팀은 monitor만**(commanded 아님). 스팀이 못 따라가면 분리 붕괴·프론트 드리프트 | 램프 중 듀티 자동조정 없으면 공식 무의미 |
+| B3 | **R의 P 종속 연쇄지연** | R=R_f×P_sp(외부환류, P 지연 상속) → 램프 중 reflux도 지연 → 분리 약화 → 프론트 | 연쇄 lag, 단일 τ로 표현 안 됨 |
+| B4 | **결손→레벨 환산 미정** | deficit(kg/hr)를 레벨 스윙(%)으로 환산하려면 홀드업·단면적·밀도 필요. 없으면 ΔI_allow를 kg/hr로 줘야 해 비직관적 | 운전원은 레벨(%)로 주고 싶을 것 |
+
+### C. 동적/과도 안전 헛점
+
+| # | 헛점 | 영향 | 비고 |
+|---|------|------|------|
+| C1 | **transient 플러딩** | 정적 ceiling 체크는 램프 중 순간 ΔP 스파이크(reflux 일시 과잉) 못 잡음 | self-throttle이 부분 보완하나 ΔP 측정 자체 지연 존재 |
+| C2 | **감시 stall 시 폭주** | self-throttle은 라이브 레벨/ΔP에 의존. realtime stall(과거 실제 발생) 시 감시가 멀어버림 | **램프는 신선도 게이트 + stall 시 즉시 freeze 필수**. corroboration 재사용 |
+| C3 | **방향 비대칭 미처리** | up(부하↑)과 down 동특성 다름(P rate 30↑/60↓). 공식은 up만 | down ramp 별도 유도 필요 |
+| C4 | **램프완료 ≠ 신평형** | 1100 도달 후에도 τ=900s 때문에 ~15분 더 정착. "완료"와 "평형 도달" 구분 필요 | 정착 판정 기준 미정 |
+| C5 | **동시 외란** | 램프 중 압력변동·조성변화·상류 트립 겹치면 "다른 건 정상" 전제 붕괴 | transient detection 있으나 램프 vs 외란 구분 필요 |
+
+### D. 운전/권한 헛점
+
+| # | 헛점 | 영향 | 비고 |
+|---|------|------|------|
+| D1 | **피드 쓰기는 AdvisoryOnly 정면 위반** | 현재 시스템은 advisory-only 정책. 자동 램프 쓰기는 WriteGuard·운전원 ARM·rate clamp 전부 통과해야 | **보고(advisory)와 실행(write) 명확 분리** 필수 |
+| D2 | **피드를 이 탑이 제어하나?** | ficq-6101이 상류 공정/탱크에서 오면 이 탑이 임의 ramp 불가. 피드 SP 쓰기 권한·상류 제약 확인 안 됨 | 미확인 — 현장 확인 필요 |
+
+---
+
+## 5. 미해결 / 필요 데이터
+
+- D·B 밸브 최대 드로우율 (현재 config 0) 또는 레벨 루프 게인
+- 라이브 ΔP(`DeltaPTag`)·스팀 OP(`SteamOpTag`) → flooding/듀티 ceiling
+- 홀드업·단면적·밀도 → 결손 kg/hr ↔ 레벨 % 환산
+- θ·τ 실측치 (estimator vs config 검증)
+- 피드(ficq-6101) 쓰기 권한·상류 제약 (현장)
+
+## 6. 다음 단계 (모두 보류 상태)
+
+- **(1)** 공식을 **계산기 advisory**로 구현 (목표 피드 입력 → 한계치/램프율/예상시간/binding 제약 표시, 쓰기 없음)
+- **(2)** 데이터 식별 θ/τ(`CrossCorrLagEstimator`) 연동
+- **(3)** 라이브 ΔP·스팀으로 flooding/듀티 ceiling 포함
+- **(우선)** 종이 위 손계산 — 현재 라이브 피드/ΔP/스팀으로 실제 한계치·램프 1회 산출해 숫자 감각 확보
+
+> 헛점 B1(D·B 제약 미반영)·B2(에너지 동특성)·C2(stall freeze)·D1(쓰기 분리)이 가장 시급한 검토 대상.
+
+## 7. 추가 브레인스토밍 — 자기조절 캐스케이드 + (목표제거량 + 편차) SP 구조 (2026-06-01 b)
+
+### 7.1 실제 물리 캐스케이드 (운전원 정정)
+
+```
+FICQ-6101(피드)↑
+  → LI-6111(리보일러 레벨)↑
+    → TICA-6111A 온도↓ (액 증가/희석)
+      → 스팀밸브 출력↑ → 스팀투입↑
+        → 온도↑ → 증발량↑
+          → LI-6111 레벨 유지
+```
+
+**핵심 정정**: LI-6111(리보일러 레벨)은 **B 드로우가 아니라 리보일러 듀티(스팀, TICA-6111A 온도 캐스케이드)로 유지**된다. → 레벨은 *에너지(증발)*, B(중비물)는 *조성 목표* 로 잡는 **decoupled 구조**. 피드 증가가 B 과추출을 강제하지 않는다.
+
+### 7.2 선행 헛점에 주는 영향
+
+| 선행 헛점 | 캐스케이드 반영 후 |
+|---|---|
+| **B1** (D·B 과추출 강제) | **부분 해소** — 레벨은 듀티가 잡음. 단 FF config가 B를 `LevelDriven by li-6111`로 둔 것은 **모델 오류 의심**(B는 실제 조성구동) → §7.4 |
+| **B2** (에너지 동특성 "수동") | **재정의** — 스팀은 수동 아님. TICA-6111A 온도 캐스케이드로 **자동 추종**(closed loop). 단 이 루프도 *자체 lag* 보유 → 새 binding 제약 §7.3 |
+
+### 7.3 새 binding 제약 — 리보일러 에너지 루프 대역폭
+
+자기조절 캐스케이드는 피드 증가를 **자동 흡수**하지만, 온도/스팀/증발 루프는 자체 시상수(스팀 동특성 + 리보일러 열관성 + 온도측정 지연)를 가진다. 피드를 이보다 빨리 올리면:
+- TICA-6111A 온도 언더슈트 → 분리 약화(중비물이 P로 상승 / P 오염)
+- LI-6111 레벨 스윙
+
+→ 램프율 제약에 **(c) 에너지 루프 제약** 추가. binding = (a)밸브슬루 · (b)생성물 지연결손 · **(c)에너지 루프** 중 **최솟값**.
+
+**유추 검증**: *최대 피드 RATE 기준으로 SP를 움직이면 자기조절 캐스케이드가 평형 유지하며 증가 피드에 대응* → **맞다.** 단 그 "최대 RATE"는 (a)(b)(c) 중 가장 느린 루프가 결정.
+
+### 7.4 SP 구조 정정 — (목표제거량) + (advisory 편차)
+
+**SP = 제거 목표량 + advisory 편차** → **표준 피드포워드(조성×피드) + 피드백 트림(편차) 구조. 맞다.**
+
+```
+B_SP(중비물) = [중비물분율(원료분석) × 피드] + 편차_trim
+D_SP(경비물) = [경비물분율(원료분석) × 피드] + 편차_trim
+```
+
+| 항 | 정체 | 비고 |
+|---|------|------|
+| **제거 목표량 (base)** | 원료분석 조성분율 × 피드율 | 현재 고정 K(B 0.03 / D 0.02) 대신 **실제 원료분석값**. 분석 갱신 시 갱신 |
+| **편차 trim (advisory)** | 물질수지 오차 / 조성 드리프트 / 프론트 보정 | **반드시 clamp + rate limit (bounded)** |
+
+**원래 불만 정면 해결**:
+- 기존 `B_SP = K×피드` (무제한 상승, 레벨 추종) → 폐기
+- 신규 `B_SP = 분석목표 + bounded 편차` → base는 물질수지 정합(피드포워드), 편차는 유계 트림(피드백). **runaway 없음.**
+
+### 7.5 7.4가 남기는 미해결
+
+- **편차 소스 정의**: 무엇으로? (a) vloss 중 B 귀속분 (b) 조성분석기 드리프트 (c) 프론트 위치 — 측정 가능성 확인
+- **원료분석 입력 경로**: 분율은 어디서? (랩 수동입력 / 온라인 분석기 / KB) · 갱신 주기
+- **config 모델 정정**: B·D를 `LevelDriven` → `Commanded(조성구동)` 재분류? li-6111 level_tag은 모니터로 강등? → **현장 확인 필수** (li-6111 실제 제어 주체가 듀티인지)
+- **편차 한계**: clamp 폭·rate를 제거 목표량의 ±몇 %로?
+- **(c) 에너지 루프 시상수 식별**: TICA-6111A 온도↔스팀 응답 — 데이터 식별 가능?
+
+### 7.6 리보일러 듀티 피드포워드 — TI-6103 + TICA-6111A.OP (2026-06-01 c)
+
+운전원 제안: 원료 프리히터 공급온도 **TI-6103**을 알 수 있고, 현재 평형에서 **TICA-6111A.OP**를 안다. TI-6103↔TICA-6111A ΔT를 감안해 OP가 얼마나 올라야 하는지 제안 가능. (**TICA-6111A.OP → FIQ-6115 스팀투입량** 결정)
+
+#### 에너지수지
+```
+Q_reboiler = 현열(피드 승온) + 잠열(증발)
+           = F·Cp·(T_b − T_feed[TI-6103]) + V·λ
+필요 스팀 ≈ Q / λ_steam  →  FIQ-6115 target  →  OP
+```
+- F(피드)·T_feed(TI-6103) = 피드포워드 입력, **둘 다 외란**
+- **증분형이 강건**: ΔOP ≈ (dOP/dSteam)·ΔSteam, 현재 평형 OP 기준
+
+#### 핵심 — §7.3 제약 (c)를 완화
+(c) 에너지 루프 lag가 binding이었던 이유 = TICA PID가 **피드백**(온도 droop 후 반응). 스팀 피드포워드(F·TI-6103로 OP/FIQ-6115 선제 구동)를 더하면 리보일러가 **선제 대응** → 온도 upset 없이 피드 램프 가능. **이 제안은 검증도구일 뿐 아니라 피드램프 가속 디커플러.**
+
+#### AUTO / MANUAL 활용 (운전원 통찰 — 맞다)
+| PID 상태 | advisory 역할 |
+|---|---|
+| **AUTO** | advisory OP vs 실제 PID OP 비교 → **모델 검증**(정상상태에서만 valid). 일치=모델OK, 괴리=모델오차/미관측외란. **OP 쓰기 금지**(PID 소유), 표시만 |
+| **MANUAL** | advisory OP = **운전원 의사결정 지원** ("이 피드엔 OP X로") |
+
+#### 보너스 — TI-6103 자체가 외란 피드포워드
+피드 일정해도 TI-6103↓(프리히터 파울링/상류 외란) → 현열부하↑ → 스팀 더 필요. advisory가 TICA 온도 droop **전에** 포착. 피드램프와 독립적 외란제거 가치.
+
+#### 일관성 — 또 같은 구조
+```
+OP_advisory = [에너지수지 base(FF)] + [PID/운전원 trim]
+```
+B·D 드로우(§7.4)와 **동형**. 온 시스템이 "FF base + bounded 피드백 trim"으로 통일.
+
+#### 헛점 / 확인필요
+- **OP↔flow 비선형**: 절대 OP 계산은 밸브특성·스팀압 의존 → **flow 도메인(FIQ-6115 SP) advisory + 증분형**이 강건. **캐스케이드(TICA→FIQ flow loop)인지 OP직결인지 확인 필요**
+- **AUTO 비교는 정상상태만**: 과도 중 PID OP는 동적/미분동작 포함 → 정상상태 비교만 valid
+- **물성치**(Cp·λ·λ_steam)·**T_b**(압력·조성 의존, TICA PV 근사) 필요
+- **효율/열손실**: FF 게인의 미지 효율계수 → **AUTO 정상상태 OP vs 피드 회귀로 역산 보정** 가능
+- **안전**: 스팀 OP 직접쓰기 고위험 → AUTO=표시만, MANUAL=제안만, AdvisoryOnly 유지(D1)
+- **상호작용**: 듀티가 선제적이 되면 드로우 trim과의 싸움(§6말미 헛점2) 오히려 **감소**
+
+### 7.7 결론적 산출물 — FIQ-6115 권장 스팀투입량 (운전원 deliverable)
+
+**최종적으로 운전원에게 줘야 하는 것 = "FIQ-6115를 얼마로 하라"** (스팀 flow 단위). OP가 아니라 flow로 주면 밸브 비선형(§7.6 헛점) 우회 + 운전원 즉시 실행 가능.
+
+#### 현재 평형 앵커링 — 물성치 없이도 강건
+현재 평형(F_cur, FIQ-6115_cur)을 신뢰(플랜트가 찾은 값) → 미지 상수(Cp·λ·효율) **소거**.
+```
+FIQ-6115_target ≈ FIQ-6115_cur × [ 잠열분율·(F_new/F_cur)
+                                  + 현열분율·(F_new·(T_b−TI6103_new)) / (F_cur·(T_b−TI6103_cur)) ]
+
+1차 근사:  FIQ-6115_target ≈ FIQ-6115_cur × (F_new/F_cur)  +  TI-6103 현열보정
+```
+- 잠열/현열 분율 모르면 → 피드비례(1차) + TI-6103 ΔT 보정으로 시작, **AUTO 정상상태 데이터로 분율 역산** 정밀화
+- 결과: **"피드 900→1100이면 FIQ-6115를 X→Y kg/hr로"** 운전원에게 직접 제시
+- "물성치 필요" 헛점(§7.6) 해소 — 절대계산 아닌 **현재 운전점 대비 증분**
+
+#### advisory 통합 산출물 (한 화면, 한 세트)
+| 산출물 | 권장값 | 근거 |
+|---|---|---|
+| **FIQ-6115 (스팀)** | 목표 flow ("X→Y") | 에너지수지 앵커링 §7.6·7.7 |
+| **B·D 드로우** | 목표제거량 + 편차 | 조성 §7.4 |
+| **피드 램프율** | max RATE + 예상시간 | (a)밸브·(b)지연·(c)에너지 §3.1·7.3 |
+
+→ 피드를 올리되(램프율), 스팀을 **선제** 상향(FIQ-6115), 드로우를 조성목표로 맞춘다. 세 권장이 연동.
+
+### 7.8 캐스케이드 확인 결과 — OP 직결 (FIQ-6115 측정전용) 확정 (2026-06-01 d)
+
+**운전원 확인: TICA-6111A.OP는 스팀밸브 직결, FIQ-6115는 측정 전용**(스팀 flow 컨트롤러 없음).
+
+함의:
+- 운전원이 직접 넣는 값은 **OP(%)**, FIQ-6115엔 SP가 없다 → "FIQ-6115 SP를 줘라"는 불가
+- §7.6 **OP↔flow 비선형 헛점 재활성** → 단, FIQ-6115 측정이 있어 해결 가능
+
+#### 산출물 정정 (해결책)
+- **1차 deliverable = FIQ-6115 목표 스팀 flow** (에너지수지 앵커링, 견고 — 밸브곡선 불요)
+- **운전원 handle = OP(%)**. 두 가지 브리지:
+  1. **운전원이 곧 flow 컨트롤러 (MANUAL)**: advisory가 flow 목표("X kg/hr까지")를 주고, 운전원이 OP를 올리며 **FIQ-6115 읽으면서** 도달. **밸브 모델 0 필요.** 가장 정직·견고.
+  2. **시작 OP 제안 (보조)**: 라이브 OP↔FIQ-6115 회귀로 **local gain dFlow/dOP 온라인 추정** → `ΔOP ≈ ΔFlow / local_gain` → "OP X%→Y%부터" 제시해 도달 가속. 운전점 이동 시 재추정.
+  - **AUTO**: OP 자동. FIQ-6115 측정으로 **예측 flow vs 실측 검증** + local gain 역산.
+
+#### 부가 통찰
+스팀 공급압 변동 시 OP 고정이어도 flow 드리프트 → **FIQ-6115 측정이 그래서 필수 피드백**. "측정 전용"이 약점이 아니라 강점.
+
+#### 정정된 스팀 deliverable (§7.7 갱신)
+| 산출물 | 운전원에게 | handle |
+|---|---|---|
+| 스팀 | **FIQ-6115 목표 flow "X→Y kg/hr"** | OP(%) 수동조작 + FIQ-6115 보며 도달 (+ 시작 OP 제안) |
+
+## 8. 편차(trim) 소스 정의 — 상세 브레인스토밍 (2026-06-01 e)
+
+### 8.1 편차의 역할 (재확인)
+`B_SP = [조성분율×피드](base, 개루프 FF) + 편차_trim(피드백)`. base는 개루프라 오차 누적 → **편차가 측정 기반으로 보정**. 관건 = **무엇을 측정해 무엇을 목표로 driving 하나.**
+
+### 8.2 후보 소스 평가
+| 소스 | 타임스케일 | 장점 | 치명적 약점 |
+|---|---|---|---|
+| (a) 물질수지 vloss | 분~시간 | 질량보존 직접 | **스칼라 — 귀속 불가**(D/P/B·성분·계기바이어스 구분 못함) |
+| (b) 조성분석(GC/랩) | 분(온라인)~시간(랩) | 직접·정확 | 온라인 없으면 느림, 랩은 trim용 불가 |
+| (c) 온도·프론트(PCT) | 초~분 | 빠름·상시·**이미 구축**(WO-2/WO-5) | 간접 proxy, 압력·조성 민감, 섹션별 tray 필요 |
+
+### 8.3 핵심 문제 — vloss를 fast trim에 직접 넣으면 안 됨
+`vloss=F−(D+P+B)`는 스칼라. 중비물 축적인지 경비물 부족인지 구분 못함(상쇄 가능). **계기 바이어스일 수도** → 보정하면 공정을 계측오차에 맞춰 틀어버림(위험). → **vloss 단독 fast trim 금지.**
+
+### 8.4 제안 구조 — 2-타임스케일 + 프론트 귀속
+```
+B_SP = [중비물분율 × 피드]        ← base (FF)
+        + fast_trim_B             ← 하부 프론트/PCT error, bounded
+base 분율 ← slow re-baseline      ← vLossMa + 랩분석 (운전원 리뷰)
+```
+1. **fast trim (초~분)**: 섹션별 sensitive-tray PCT/프론트 편차. **B=하부 프론트, D=상부 프론트**. 유계(clamp+rate)
+2. **귀속 트릭**: vloss를 "**프론트 드리프트하는 스트림**"에 귀속 → 스칼라 모호성을 프론트가 해소(상부 고정·하부 상승=B 오차 국소화)
+3. **slow re-baseline (시간)**: vLossMa+랩분석으로 base 분율 천천히 재보정. 자동 runaway 아닌 **운전원 리뷰**
+
+### 8.5 방향(sign) 로직 (calibrate 필요)
+- **B**: 하부 PCT > ref (heavies 축적/프론트 상승, 제품 위협) → **B↑** / < ref (과추출, 수율손실) → **B↓**
+- **D**: 상부 대칭
+
+### 8.6 기존 자산 재사용
+PCT(WO-2)·sensitive tray·front indicator(WO-5)·vloss/vLossMa(WO-4)·transient gating 전부 이미 코드 존재. **편차 소스 = 이것들을 타임스케일 분리 + 유계로 배선.**
+
+### 8.7 이 구조의 헛점
+- **sensitive tray config 1개뿐** → 사이드드로우 2-프론트엔 **상/하 2개 필요**(B 하부·D 상부)
+- **ref 온도 기준**: 평형 시드(PRef식)면 피드조성 변할 때 ref도 drift → 갱신 방법?
+- **결합**: B·D trim + 듀티가 모두 온도 이동 → 상호작용. **trim rate ≤ 듀티 대역폭** 제약
+- **transient 중 온도는 조성 아닌 열동특성** → fast trim에 **transient 게이트 필수**(기존 재사용)
+- **PCT 부정확**(DTdP 오보정) → proxy 붕괴
+- **편차 clamp 폭**: 좁으면 실드리프트 못잡고, 넓으면 듀티와 싸움 → 정하는 기준 미정
+
+### 8.8 sensitive tray 1→2개 + tray 레이아웃 확정 (2026-06-01 h)
+
+#### 왜 2개인가 — 사이드드로우 = 3제품 = 2 front
+제품 3개(D 경비물·**P 측류 주생성물 95%**·B 중비물) → 분리 front 2개. **sensitive tray 1개는 한 front만 보고 나머지 구간은 장님** → §8.4 "front 귀속" 트릭 작동 불가(B/D 독립 trim 불가). 제어공학 표준: 2-제품탑=온도1점, **3-제품(사이드드로우)탑=온도 2점**(dual/two-point temperature control).
+
+현재 `ColumnConfig.SensitiveTrayTag`는 **단일** + C-6111은 null이라 비활성.
+
+#### 확정된 전체 레이아웃 (P&ID 확인, 2026-06-01 j) — 패킹 3구간
+> **태그 번호 (확정)**: P&ID는 **10111**(TICA-10111A, TI-10111B/C/D), DCS/DB는 **6111**(tica-6111a, ti-6111b/c/d). **동일 계기 — 10111→6111 치환**(운전원 확인 2026-06-01).
+```
+탑정 (pica-6111, 진공/경비물 D)
+REFLUX DISTRIBUTOR (R ficq-6113 진입)
+TI-6111D
+  PACKING (상부) — 정류, 제품 vs 경비물 D
+제품추출노즐 P (ficq-6118)        ← 전체높이 70~75%
+TI-6111C (긴 패킹 상단 = 추출 직하)
+  PACKING (긴 구간) — 주 분리, 제품 vs 중비물 B   ★ 핵심
+TI-6111B
+원료 PREHEATER DISTRIBUTOR (피드 ficq-6101, TI-6103 온도)
+  PACKING (하부, 짧음) — stripping, 제품 회수 vs B
+TICA-6111A(TE) — 컬럼 최하부/리보일러부, B 추출 (pi-6111b≈여기)
+```
+
+| 패킹 | 위치 | 역할 | bracket 온도 |
+|---|---|---|---|
+| 상부 | 제품~리플럭스 | 정류(경비물 D 제거) | TI-6111D ↔ TI-6111C |
+| **중간(가장 김)** | **피드~제품** | **주 분리(중비물 B front)** | **TI-6111B ↔ TI-6111C** |
+| 하부(짧음) | 리보일러~피드 | stripping(제품 탑저손실 방지) | TICA-6111A ↔ TI-6111B |
+
+- **이전 오류 수정**: 피드는 "리보일러 바로 위"가 아니라 **하부 짧은 패킹 위 PREHEATER DISTRIBUTOR**로 진입. **피드~제품 긴 패킹이 주 분리 구간** → B front가 최장 패킹에 걸쳐 **해상도 높음**. D 제거는 위쪽 짧은 정류.
+- **TI-6111D = 리플럭스 직하** → R 즉답. R이 상부 front 조작변수라 위치 이상적
+- 두 front 모두 단일 단 아닌 **패킹 구배** → 민감도 충분
+- 제품·TI-6111C가 **70~75% 높이** → 위 25~30%만 정류(D), 아래 70%가 주분리+stripping
+
+#### ti-6111c 공유 기준 차온 + B 이중신호
+- **상부 front (D)** = `ΔT(TI-6111C − TI-6111D)` (상부 정류 패킹): 경비물(저비점) 제품쪽 하강 시 구배 변화 → 침투 → **D↑**. **⚠ §10.2-B: TI-6111D는 환류 서브쿨링 오염 → 이 정의 재검토 필요(D 보정/대체)**
+- **하부 front (B)** = `ΔT(TI-6111C − TI-6111B)` (긴 중간 주분리 패킹): 중비물(고비점) 제품쪽 상승 시 침투 → **B↑**
+- **(보너스) stripping** = `ΔT(TI-6111B − TICA-6111A)` (하부 짧은 패킹): 제품(저비점)이 탑저로 손실되면 구배 변화 → **제품 탑저손실/B 과추출 조기경보** → B는 신호 2개(중간=중비물 침투 / 하부=제품 손실)
+- ti-6111c 공유 pivot → 차온 자연 분리 → §8.4 귀속 작동
+
+#### 보너스 — 제어 위계 명확화
+- **ti-6111c(PCT) = 제품 품질 proxy = 주 제어변수**(제품 spec). reflux(R)/duty로 1차
+- 상/하 front(D·B trim) = spec 유지 받치는 2차 보조
+
+#### 보너스 — 압력 프로파일 보간 (§9 연결)
+압력 2점(pica-6111 탑정, pi-6111b≈리보일러) → 단높이 선형보간으로 각 온도에 국소압 부여:
+ti-6111d≈pica-6111 / tica-6111a≈pi-6111b / **ti-6111c·ti-6111b=보간**. → §9 PCT를 단일압이 아닌 **프로파일 기반**으로. ti-6111c 제품온도 보정 정확도가 핵심.
+
+#### 코드/모델 변경
+| 현재 | 필요 |
+|---|---|
+| `SensitiveTrayTag` (단일) | `UpperSensitiveTrayTag`+`LowerSensitiveTrayTag` (또는 섹션별 차온쌍) |
+| `st.FrontInd` 1개 | 상/하 2개 인스턴스 |
+| `ApplyFront`→단일 (state,trim) | 섹션별 반환 |
+| §8 귀속 | 상부→D trim, 하부→B trim |
+
+#### sub-헛점 / 확인필요
+- **two-point 루프 간섭**: D·B 완전독립 아님(reflux/duty·내부 traffic 공유). 디커플링 또는 한쪽 detune 필요할 수 있음(RGA 영역)
+- **tray 선정**: 각 구간 최민감 지점은 운전 프로파일로 확인(고정가정 위험)
+- ~~태그 10111 vs 6111~~ → **확정**: 동일계기, P&ID 10111 → DCS 6111 치환
+- ~~ti-6111b 위치·피드 진입단·ti-6111c~d 중간단~~ → **해소**(2026-06-01 j): 전체 레이아웃 확정. 피드=하부 짧은패킹 위 PREHEATER DIST, ti-6111b=피드 직상, ti-6111c~d 사이=상부 정류 패킹
+
+## 9. 진공압 프로파일 — pi-6111b 미사용 + ΔP/PCT 함의 (2026-06-01 f)
+
+### 9.1 현재 실태 (DB 확인, ff_column_config id=1)
+| 항목 | 값 | 의미 |
+|---|---|---|
+| `pressure_tag` | **pica-6111만** | **pi-6111b 미사용** |
+| `dtdp` | **0.0** | **PCT(압력보정온도) 꺼짐** — pct=raw |
+| `delta_p_tag` | **null** | ΔP 플러딩 트리거 비활성 |
+| `sensitive_tray_tag` | **null** | 프론트/θ 기능 비활성 |
+| `p_ref` | null | 첫 압력 시드 |
+| `temp_tags` | tica-6111a, ti-6111b, ti-6111c, ti-6111d | 수집됨 |
+
+- pi-6111b는 **OPC 태그로 수집은 됨**(realtime/history DB 존재) — FF 엔진이 안 읽을 뿐
+- pica-6111조차 현재 `pUnstable`(과도감지)용뿐 + `PressureBand` 기본 무한대 → 사실상 거의 비작동
+- **즉 압력/PCT/ΔP/sensitive-tray 서브시스템이 통째로 dormant**
+
+### 9.2 압력 프로파일 의미
+진공탑 → 아래로 갈수록 절대압↑. **pica-6111(최상단) < pi-6111b(≈ 리보일러 위, 피드 디스트리뷰터 하단)**.
+
+**운전원 정정 (2026-06-01 g): pi-6111b ≈ 리보일러 압력**으로 간주. → 탑저 압력이 실측되는 셈.
+```
+컬럼 ΔP(전탑, top→bottom) = pi-6111b − pica-6111  (> 0)
+```
+함의: **피드가 탑 하부 진입**(디스트리뷰터 하단=리보일러 위) → §7.6 에너지 노드가 한 점에 모임(피드 TI-6103 진입 → pi-6111b 비점까지 승온 → 직하 리보일러 듀티).
+
+### 9.3 pi-6111b가 우리 설계의 빠진 조각인 이유
+| 설계 항목 | pi-6111b 기여 |
+|---|---|
+| **§3.2 플러딩 ceiling** | 별도 ΔP 트랜스미터 없이 **pi-6111b − pica-6111 = ΔP** → flooding 지표. `delta_p_tag`을 이 식/파생태그로 채움 |
+| **§7.6/7.7 에너지수지 T_b** | 비점=국소 압력 함수. pi-6111b≈리보일러압이므로 **탑저 비점 = pi-6111b 비점, tica-6111a가 그 실측치** → 추가 ΔP 보정 불요 + **tica-6111a ≈ 탑저조성 비점@pi-6111b** 교차검증 |
+| **§8 편차 trim PCT proxy** | §8.7 "PCT 부정확→proxy 붕괴" 헛점의 근원. dtdp=0이라 PCT 꺼짐 + 단일 탑정압으론 하부(B 귀속) 보정 부정확. **pi-6111b가 하부 섹션 PCT의 기준압** → §8 B fast-trim 작동 전제 |
+
+### 9.4 제안 배선
+- `pi-6111b` 수집값 → **ΔP 파생** = pi-6111b − pica-6111 → `delta_p_tag`(또는 계산 컬럼)로 플러딩 ceiling 공급
+- **단별 기준압 = 패킹가중 보간**(높이선형 아님, 긴 중간 패킹이 ΔP 대부분): pica-6111(탑정)~pi-6111b(탑저) 사이를 패킹구간/traffic로 분배. ti-6111d≈pica-6111+상부패킹ΔP / **제품·ti-6111c(70~75%높이)≈pica-6111+상부패킹ΔP** / ti-6111b≈+상부+중간패킹ΔP / tica-6111a≈pi-6111b. **제품온도(ti-6111c) PCT 기준압 = 제품 품질추정 직결**
+- `dtdp` 실측 보정계수로 설정(현재 0=꺼짐) → PCT 활성화
+- → §8 편차 trim(특히 B 하부)이 비로소 유효해짐 (의존성)
+
+### 9.5 헛점/확인필요
+- ~~pi-6111b는 중하부라 탑저는 더 아래 미계측~~ → **해소** (2026-06-01 g): pi-6111b ≈ 리보일러압. 탑저 압력 실측되는 셈, 추가 ΔP 보정 불요
+- ΔP = pi-6111b − pica-6111 의 부호·스팬 실측 확인 (둘 다 진공, mmHg). 이제 **전탑 ΔP**
+- 진공계 신선도/stall 게이트 (압력도 corroboration 대상)
+- tica-6111a(리보일러 온도) = 탑저 비점@pi-6111b 교차검증 활용 — 괴리 시 조성변화/계기이상 신호
+
+## 10. 온도 프로파일 단조성 · 역전 판정 · 프론트 부호 (2026-06-01 k)
+
+### 10.1 확정 baseline (운전원)
+정상 생산 시 **A>B>C>D 단조 감소** (탑저 tica-6111a 최고온 → 탑정 ti-6111d 최저온). A−D ≈ 10°C — 단 그 상당분은 **D의 환류 서브쿨링**(리플럭스 디스트리뷰터 냉액)에서 옴(조성 아님).
+
+### 10.2 발견된 버그/문제 (코드 확인)
+| # | 문제 | 영향 | 등급 |
+|---|------|------|------|
+| A | **부호 역전 버그** — `DiffTemp.Delta(tHi,tLo)=tHi−tLo` 주석="상단−하단", 그러나 `ApplyFront`(engine.cs:255) 호출=`Delta(temps[0]=A=하단, temps[^1]=D=상단)`=A−D=**하단−상단** → 규약 반대부호 | FrontPositionIndicator `dev>0→프론트상승→환류↑` 매핑이 "상단−하단" 가정 → **트림 권고 반전 + ApplyRecovery sigFront 오판** | 🔴 |
+| B | **D 환류 서브쿨링 오염** — ti-6111d=리플럭스 직하라 조성 아닌 환류온도 추종 | A−D·ΔT(C−D)가 분리 아닌 환류에 끌림 → §8.8 상부 front(D 사용) 약화 | 🔴 |
+| C | **역전 가드 부재** — 단조성 검증 없음, 순서 가정 silent | 실제 이상역전(플러딩 등) 미검출 | 🟡 |
+
+### 10.3 역전(inversion) 판정 — 구체 spec (설계, 미구현)
+
+#### 입력
+- **신뢰 구간 = A,B,C** (조성 트레이). C-6111: A=`tica-6111a`, B=`ti-6111b`, C=`ti-6111c`. **D(`ti-6111d`)는 환류 서브쿨링 오염이라 단조 체인에서 제외**(§10.2-B).
+- 온도는 **PCT 적용값** 사용(§9 압력 프로파일 보간 의존). PCT 미활성(dtdp=0)이면 raw + warning="PCT off, 역전판정 정확도 저하".
+- **게이팅**: `transient`(피드 이동·압력 불안정·정착대기) 중에는 판정 보류(열동특성 노이즈). 모든 입력 `Good`(신선) 필수, stale 시 보류.
+
+#### 판정량
+인접쌍 하강폭(정상 양수):
+```
+ΔAB = T(A) − T(B)   ,  ΔBC = T(B) − T(C)        // 정상 둘 다 > 0
+span = T(A) − T(C)                               // 정상 양수 (분리 강도 지표)
+```
+기준값 `spanRef`: cfg 지정 또는 **최초 정상상태에서 시드**(PRef 방식).
+
+#### 상태 분류 (우선순위 순)
+| 상태 | 조건 | 의미 | 등급 |
+|---|---|---|---|
+| **온도역전** | 임의 인접쌍 `ΔAB < −tolInv` 또는 `ΔBC < −tolInv` (상단이 하단보다 더 뜨거움) | 조성 upset / 플러딩 / 센서이상 | 🔴 |
+| **프로파일 붕괴** | `span < spanCollapseFrac × spanRef` | 분리 손실(평탄화) | 🟠 |
+| **약화** | `span < spanWarnFrac × spanRef` (붕괴 전 단계) | 분리 여유 감소 | 🟡 |
+| **정상** | 위 해당 없음 | — | — |
+
+#### 파라미터 (기본값, 운전 데이터로 튜닝)
+- `tolInv` = 0.5 °C (센서 노이즈 + 여유; 이 이상 음수라야 역전 인정)
+- `spanWarnFrac` = 0.5, `spanCollapseFrac` = 0.3 (spanRef 대비)
+- `spanRef` 시드: 최초 비-transient·전부 Good 인 tick의 span
+
+#### 조치
+- **front advice**: 역전/붕괴 시 front trim **HOLD** + confidence 강등(역전 중 front 방향 신뢰 불가).
+- **ApplyRecovery 연동**: 새 severity 신호 `sigInv`(역전) / `sigCollapse`(붕괴)를 기존 `sigVloss·sigFront·sigDp`와 **병렬 OR**로 추가. (advisory·ARM 게이트 유지 — 자동쓰기 아님.)
+- **센서 vs 공정 구분(corroboration)**: 역전이 ΔP(`pi-6111b−pica-6111`)·vloss와 **동반·지속**이면 공정(플러딩/조성); 단발·점프성이면 **센서이상 의심** → 역전 신호 억제 + 계기점검 권고. (단독 온도로 공정 단정 금지.)
+- **D 특수처리**: C−D 쌍은 서브쿨 baseline이라 절대 단조검증서 제외. 필요시 **서브쿨 보정 후 deviation**으로만 별도 모니터(역전 트리거엔 미포함).
+
+#### 출력 (advisory 필드 추가 제안)
+`tempProfileState`(정상/약화/붕괴/역전) + `inversionPair`(예 "B-C") + `span`/`spanRef`.
+
+#### 구현 메모
+- 신규 순수함수 `TempProfileJudge.Evaluate(temps[A,B,C], spanRef, params)` → 단위테스트(정상/역전/붕괴 각 케이스). `FeedforwardEngine`은 호출만(엔진 로직 최소 변경).
+- §10.2-A(부호) 버그픽스와 독립. WP2 P6에서 정상 프로파일·역전 재현으로 검증.
+
+### 10.4 제안 — 프론트 부호 정정
+- metric을 명시 "상단−하단"으로: `Delta(temps[^1], temps[0])`(D−A) 또는 부호 반전 → FrontPositionIndicator 매핑과 정합.
+- 단 D 오염 때문에 상부 front는 D 대신: (b1) D를 환류온도 기준 보정, (b2) C 단독 PCT 변화, (b3) D=에너지/서브쿨용 재지정 + 경비물 front는 탑정 조성/분석.
+- 하부 front(B)는 A,B,C만 쓰므로 부호 정정 후 신뢰 가능.
+
+### 10.5 작업 항목
+- (버그픽스, 엔진수정이라 별도) DiffTemp 호출 부호 정정 + 단위테스트.
+- (WP2 프로브) 정상시 A>B>C>D 확인, A−D≈10 중 환류 서브쿨 기여 측정, 부호 역전 재현.
+- (§8.8 갱신) 상부 front 센서 D 의존 재검토(b1/b2/b3).
+
+## 11. 참고
+
+- `docs/측류추출식-통합유량설정공식.md` (§9~§12 advisory 엔진)
+- `src/Infrastructure/Control/FeedforwardEngine.cs` (ComputeStream, deadtime/lag/rate)
+- `src/Core/Application/Feedforward/FeedforwardModels.cs` (StreamConfig)
+- `docs/운전원교육-FF과도상태-메커니즘.md`