# 학습형 제어 (오퍼레이터 수동조작 모방) — 설계 플랜

> 상태: 설계(design) 단계. 코드 착수 전.
> 작성 맥락: PID hunting 회피를 위해 현장 MANUAL 운전 이력을 학습해 OP를 자동 산출하는 제어기 설계 논의 보존.

---

## 0. 오리엔테이션 — 다음 세션의 나에게 (READ FIRST)

> 이 블록은 다음에 이 문서를 여는 에이전트(=미래의 나)가 **지금과 동일한 사고 상태로 즉시 몰입**하기 위한 것이다. 아래를 먼저 읽고 §1~§13으로 들어가라.

### 0.1 이 문서가 뭔가
HC900 프로젝트(`/home/windpacer/projects/hc900_ax`, CLAUDE.md 참조)의 **신규 작업 줄기**에 대한 설계 플랜이다. 본체 프로젝트는 "HC900 Modbus→C++ gateway→gRPC→C# 크롤러→PostgreSQL"로 Experion OPC UA 경로를 대체하는 일이고, **이 문서는 그 위에 얹는 "학습형 제어기"** 설계다. 아직 **코드는 한 줄도 안 짰다.** 전부 설계 합의 단계.

### 0.2 사용자가 진짜 풀려는 문제 (가장 중요 — 이걸 잊으면 길을 잃는다)
- 현장(6차 플랜트)은 **PID를 못 믿어서 거의 모든 루프를 MANUAL로 돌리고 오퍼레이터가 손으로 OP를 잡는다** (진공제어만 PID/AUTO 예외).
- 사용자가 **가장 두려워하는 단 하나 = hunting(지속 진동)**. PID 교란성 발진. 이 공포가 모든 설계 결정의 1순위 제약이다.
- 따라서 목표는 "PID를 잘 튜닝"이 **절대 아니다.** **오퍼레이터의 수동 조작을 학습해 자동화**하되, **구조적으로 안 떠는** 제어기를 만드는 것. 평가 기준은 "잘 튜닝된 PID"가 아니라 **"현재 신뢰받는 오퍼레이터"**.

### 0.3 이미 굳은 핵심 결정 (재론하지 말 것 — 사용자와 합의됨)
1. **접근법 = 정상상태 맵**: `OP_ss = f(정착 PV, 부하변수)`. 원시 behavior cloning(`OP=f(PV,SP)`) 아님. (§4)
2. **SP를 정답으로 안 쓴다**: 현장 SP 신뢰도 ~80%(MANUAL이라 방치 가능). **정착 PV = de facto target**으로 사용. (§4)
3. **안 떠는 이유 = 전향맵(피드백 없음) + 데드밴드 + dwell + rate-limit.** stiction은 어떤 제어로도 못 고치며 "덜 움직이기"만이 답. (§5)
4. **검증 = shadow 모드(실플랜트, write 안 함) > 시뮬레이터.** 시뮬은 선택. (§6)
5. **로드맵 = 학습 → shadow → operator-assist → guarded closed-loop**, 이상 시 fallback은 PID가 아니라 **오퍼레이터에게 반환**. (§7)
6. **RL/imitation은 실증 부족(sim2real 미해결)으로 1차 투입 부적합.** 실증된 건 **MPC(2단 구조)**·MFAC·퍼지/전문가 supervisory. 우리 "정상상태 맵+gentle"이 마침 **MPC 2단 구조(LP 정상상태 타깃 + 동적 move-suppress)와 동형** → de-risk. (§11·§12)
7. **착수 1순위 = 기둥 A(루프 헬스 모니터링, APROMON류).** dump만 있으면 즉시 가능하고 파일럿 루프를 데이터로 객관 선정해준다. (§13.1)
8. **개발은 6차 플랜트 기준으로 먼저, 이후 차수 확장.** 이유: 6차는 **HC900 통신이 살아있어**(현재 live 값은 가공이라도) 실 제어경로(shadow→assist→closed) 테스트 가능. 6·8·9·10차는 **측류 반도체용 솔벤트**로 동일 유형 → 6차용을 만들면 8·9·10에 그대로 확장. 1·2차는 **측류 아닌 2컬럼 경질/중질 제거 일반 증류**라 별도. (§15.9)
9. **★개발 범위 = 6-1차 단독★** (6-1/6-2 독립운전). 6-1차 활성 제어루프 6개: **TICA-6111A**(파일럿) + **FICQ-6101/6113/6114/6116/6118**. 제외: PICA-6111(진공), LICA(사장). 6-1차용 완성 → 6-2·8·9·10 복제. 피처는 **6-1차 내부 변수만** 사용. (§15.11) 컬럼 토폴로지·센서위치·스트림역할은 §16.1(기존 ff_config + 사용자 도메인)에 권위 정의.
10. **★학습 대상 3종★**: ①정상생산 제어(정상상태 맵, 현재) + ②START-UP 절차 + ③SHUTDOWN 절차(②③=시퀀스/절차 모방, 안전 자동화, 추후). 6모드 상태분류기가 ①필터+②③골격 이중역할. **과도구간 데이터 버리지 말 것.** (§16.4)

### 0.4 데이터 자산 (반입·복원 완료 2026-06-05 — 상세 §15)
- **dump 반입 완료**: 현장(신암정유) DB `shinam`(PG9.5) → 별도 DB **`field_hist`**(우리 PG16) 복원 완료. 라이브 `iiot_platform`/`hc900` 안 건드림.
- 기간 **2026-02-05~06-05 (~4개월), 간격 주로 30초**. WIDE 포맷: `cont001~017` + `ptlist/tblist/mapping` 디코드. 시계열 복원 규칙·검증은 §15.3.
- **OP(106)·SP(114)·PV(456) 모두 존재 → PV+SP+OP 완비 루프 104개.** 학습 대상 확보(make-or-break 통과).
- ⚠️ **MODE 태그는 없음** (100% MANUAL이라 미기록 추정). → **진공제어(PID) 루프 식별·제외 방법이 미해결** (§15.5).
- ★통찰★: MANUAL OP 계단조작 = 개루프 step 데이터 → 시스템 식별 유리. bump test 보조. (§13.0)
- 30초 해상도: 느린 루프(온도/레벨) OK, 빠른 루프(유량/압력) 동역학·stiction은 aliasing 한계.

### 0.5 지금 막혀있는 곳 / 다음 행동
- **데이터 확보됨**(`field_hist`). 다음: ① (선택) cont 테이블 하이퍼테이블+압축 → ② **§13.1 기둥 A KPI**(진동지수·IAE·OP travel·stiction) → ③ 파일럿 루프 선정 → ④ SP 신뢰도 실측 + 정상상태 세그먼테이션 → ⑤ `OP_ss=f(정착PV,부하)` 맵.
- **사용자 확인 대기**: 진공(PID) 루프를 태그 패턴/지식으로 어떻게 가려낼지 (§15.5).
- 미해결 질문 전체는 §10·§15.5.
- ★**남은 작업(형제확장·shutdown·operator-assist·live포팅)은 `docs/작업지시서-학습형제어-다음단계.md`에 실행 지시서로 정리됨.** ①생산제어·②startup은 6-1차 오프라인 완료(§16.6~16.10).

### 0.6 톤/태도 (사용자와의 작업 방식)
- 사용자는 한국어로 빠르게 핵심만 던진다. **장황한 옵션 나열 말고 추천을 줘라.** 단, 안전·hunting 관련해선 트레이드오프를 정직하게.
- 이 문서는 **사용자가 "기록/플랜에 남겨"라고 하면 즉시 갱신**해온 살아있는 문서다. 큰 결정이 바뀌면 §0.3을 먼저 고쳐라.

### 0.7 관련 포인터
- 본체 지침: `/home/windpacer/projects/hc900_ax/CLAUDE.md`
- 메모리: `learned-control-operator-imitation.md` (이 줄기), `mode-write-mechanism.md`(OP/MODE 쓰기 메커니즘), `project_overview.md`
- 기능 벤치마크 원문: `docs/PITOPS-브레인스토밍-웹페이지복사.md`
- 기존 FF 자산 재활용: `FeedforwardWriteGuard`(상하한/rate-limit), `FfTrackingStore`(모델 결정 로깅), `...AdvisorService` 네이밍

---

## 1. 배경 / 문제 정의

- 현장에서 **PID가 제대로 안 쓰임** → 오퍼레이터가 루프를 **MANUAL로 돌려놓고 손으로 OP를 조정**.
- 가장 두려워하는 것: **PID 교란에 의한 hunting(지속 진동)**.
- 따라서 목표는 "PID를 더 잘 튜닝"이 **아니라**, **오퍼레이터의 수동 조작을 학습해 자동화**하는 것. 비교 기준은 "잘 튜닝된 PID"가 아니라 "현재 신뢰받는 오퍼레이터".
- 오퍼레이터는 본질적으로 hunting을 안 함 → **오퍼레이터를 모방하면 "안 떠는" 성질을 그대로 물려받음**.

## 2. 목표

- 현장 실 운전데이터로 `OP`(제어출력)를 학습 → 그 모델로 제어.
- **hunting 없이** 동작하는 것이 최우선 제약.
- 단계적·안전 우선 투입 (사람을 루프에 두고 시작).

## 3. 데이터 자산 (확정)

- 현장 DB 서버에 **PostgreSQL, 30초 주기, 몇 달치** 이력 존재. `pg_dump`으로 반입 예정.
- **OP 로깅됨** ✅ (제어출력 학습 가능 — make-or-break 통과)
- **100% MANUAL 운전 데이터** (진공제어만 PID/AUTO 예외) → 통째로 *오퍼레이터 시연 데이터*. MODE 필터링 거의 불필요.
- **모든 플랜트 변수 존재**: 온도, 압력, 유량, 레벨, 진공압력 → `f(목표, 부하)`의 입력 확보.
- **SP 신뢰도 ~80%**: MANUAL이라 오퍼레이터가 SP를 자기 목표값으로 정확히 설정했는지 불확실(20%는 stale 가능).

### 해상도 주의 (30초)
| 루프 종류 | 30초로 가능 |
|---|---|
| 온도/레벨/조성 (τ 분~시간) | 동역학·stiction 한계주기 ✅, 시스템ID ✅ |
| 유량/압력 (τ 초) | 빠른 동역학·stiction은 **aliasing으로 소실** ❌ (정상상태 맵은 학습 가능) |

→ 30초 해상도는 **gentle 제어기(정상상태 맵 + 데드밴드)** 방향을 지지함. 공격적 RL/고정밀 동역학 시뮬에는 부족.

## 4. 핵심 전략: 정상상태 운전 맵 (Steady-State Map)

원시 behavior cloning(`OP=f(PV,SP)`) 대신 **정상상태 맵**을 학습:

```
OP_ss = f(정착 PV, 부하변수)      ← SP를 아예 안 거침
```

근거:
- **SP 80% 신뢰도 문제 우회** — MANUAL 정상상태에서 오퍼레이터가 OP를 잡아두고 PV가 안정돼 있으면 **그 PV가 곧 진짜 목표**(SP 입력값과 무관). 정착 PV = de facto target.
- **구조적으로 안 뜸** — 전향(feedforward) 맵은 피드백 루프가 없어 자기 혼자 진동 불가.
- **설명 가능** — "이 조건이면 밸브는 이 위치"라는 오퍼레이터 지식의 모델화. 블랙박스 NN보다 현장 수용성↑.

### SP의 역할 = 보조
- SP 신뢰도는 **루프별로 데이터로 실측**: 정상상태 구간마다 `|SP − 정착PV|` 분포 → 작으면 신뢰, 지속적으로 벌어지면 stale → 그 구간 폐기.
- "80%"를 전역으로 받지 말고 루프별 차등 적용.
- 전이(transition) 구간의 목적지 힌트로만 SP 보조 사용(PV와 일치할 때 한정).
- **배포 시 기준값은 SP 레지스터가 아니라 오퍼레이터/레시피 입력 목표**에서.

## 5. Hunting — 원인과 방지

### 원인 4가지
| 원인 | 증상 | 처방 |
|---|---|---|
| ① 과도한 게인 | 감쇠 안 되는 진동 | 게인↓ (느린 제어) |
| ② 데드타임/지연 | 주기 ≈ 2×데드타임 | **dwell time ≥ 데드타임** |
| ③ 밸브 stiction | OP 톱니/PV 삼각파 **한계주기** | **어떤 PID로도 못 잡음** — 데드밴드로 가두고 거의 안 움직이기 |
| ④ PV 노이즈 | OP 고주파 chattering | 데드밴드 + 필터 |

③ stiction이 오퍼레이터가 MANUAL로 도망가는 주 원인일 가능성 높음. 사람은 stiction 영역에서 OP를 가만히 둠.

### 학습 제어기가 안 떠는 이유 (정밀)
- **전향 맵 부분** = 피드백 없음 → 절대 자기발진 불가.
- **느린 트림(feedback) 부분** = 반드시 **데드밴드 + dwell + rate-limit**으로 이산·저속화 → ②③④ 동시 차단.
- "안 떠는 건 데드밴드/dwell이 만든다."

### Hunting 자동 감지기 (안전 폴백 트리거)
- 최근 N분간 오차 `(SP−PV)` 부호 반전 ≥ k회, 또는 OP 방향 반전 ≥ k회 + 진폭 초과
- 감지 시 → **OP 동결 → 오퍼레이터에 반환** + 경보

## 6. 검증 전략: Shadow 모드 > 시뮬레이터

실 MANUAL 데이터가 있으므로 **시뮬레이터는 더 이상 전제조건이 아님**:
- 학습: 실데이터로 바로 → 시뮬 불필요.
- 검증: **shadow 모드(실플랜트)가 더 나은 검증기** — 플랜트가 이미 MANUAL로 도니, 모델이 실시간 OP를 *예측만* 하고 오퍼레이터 실제 조작과 비교. write 안 하니 위험 0, 진짜 오퍼레이터 상대 정직한 검증, distribution shift도 즉시 노출.
- 시뮬은 **선택사항**(hunting 감지기·fallback을 드문 시나리오로 스트레스 테스트할 때만). 필요 시 같은 데이터로 system-ID해 보정(느린 루프 한정).

## 7. 로드맵 (단계적·안전 우선)

```
① 실 MANUAL 데이터로 정책 학습   OP_ss = f(정착PV, 부하…)
        ↓
② Shadow 모드 (실플랜트, write 안 함)
   오퍼레이터 vs 모델 실시간 비교 — 위험 0
        ↓
③ Operator-assist  "권장 OP=X" 화면 표시, 사람이 누름 (신뢰 구축)
        ↓
④ Guarded closed-loop  데드밴드+dwell+rate-limit+상하한 + hunting 감지
        ↓
   이상 시 fallback = 오퍼레이터에게 반환 (PID 아님 — PID는 못 믿음)
```

기존 자산 활용: `FeedforwardWriteGuard`(상하한/rate-limit), `FfTrackingStore`(모델 결정 로깅), `...AdvisorService` 네이밍이 자문 모드에 부합.

## 8. 리스크 / 확인 항목

- **Distribution shift (imitation 고질병)**: 학습 정책이 오퍼레이터가 안 가본 상태에 들어가면 오차 누적. 완화책 = 몇 달치 넓은 커버리지 + gentle 정책으로 분포 근처 유지 + shadow/assist 선행.
- **OP 변경 빈도 측정**: 드물게 계단식이면(대부분 그럴 것) 정책이 사실상 정적 맵 = 공짜 gentle 제어기.
- **off-spec 구간 학습 위험**: 오퍼레이터가 불량값 잡고 있던 구간. 품질/생산 데이터로 필터, 없으면 shadow+assist 단계에서 사람이 거름.
- **Causality/confounding**: 오퍼레이터가 DB 밖 정보(육안, 랩 샘플, 전화)로 움직였을 수 있음. 잔차/피처 분석으로 "가용 변수가 OP를 얼마나 설명하나" 측정.
- **OP 레지스터 RW 확인**: register-map에서 대상 루프 OP의 access.

## 9. 다음 스텝 (dump 반입 후 즉시)

1. dump을 **별도 스키마**(예: `field_history`)로 restore — 라이브 `hc900` 안 건드림. 용량 ≈ 수억 행(2000태그×30초×3개월), Timescale 압축 권장.
2. 루프별 **SP 신뢰도 실측** (`|SP−정착PV|` 분포)
3. **정상상태 세그먼트 추출** (dPV/dt≈0, dOP/dt≈0)
4. **`OP_ss = f(정착PV, 부하)` 맵 학습** + 잔차/피처 분석
5. **stiction 1차 진단** (느린 루프 한정)
6. **파일럿 루프 1개 선정** (느리고 안정적인 온도/레벨 우선, 빠른 유량은 나중)

## 10. 미해결 질문

- [ ] dump 반입 시점?
- [ ] 현장 DB **스키마(테이블·컬럼명)** — 쿼리 설계용
- [ ] 파일럿 후보: "오퍼레이터가 제일 안정적으로 잘 잡는 루프"는? (현장 감 + 데이터 양쪽)
- [ ] 품질/생산 데이터 존재 여부 (off-spec 필터용)
- [ ] 대상 루프 OP가 register-map에서 RW인지

---

## 11. 참고 문헌 — 실증된 제어 기법 (실증·인용 1·2위)

> 선정 기준: **실플랜트 실증 이력 + 인용수**. RL/imitation 계열은 논문은 많으나
> 실플랜트 실증이 빈약(sim-to-real 미해결)해 1차 투입 부적합 → 아래 두 기법이 검증된 선택지.

### 1위 — 산업용 MPC (Model Predictive Control)
- **문헌**: S.J. Qin & T.A. Badgwell, *A Survey of Industrial Model Predictive Control Technology*, Control Engineering Practice **11** (2003) 733–764.
- **링크**: https://www.sciencedirect.com/science/article/abs/pii/S0967066102001867
- **요지**:
  - 상용 MPC(선형·비선형)를 **벤더 실사 데이터** 기반으로 정리한 서베이. 제어 분야 **최다 인용급(수천 회)**.
  - 1980년대 **DMC(Dynamic Matrix Control, Shell/Cutler)·IDCOM** 이래 정유·석화에 **수천 개 실제 설치** — 비-PID 고급제어의 사실상 산업 표준.
  - 핵심 특성: **미래 예측 + 제약(상하한·rate) 명시적 준수 + 다변수 처리**. 잘못 튜닝된 PID보다 hunting 위험이 낮고, 운전 한계를 직접 지킴.
- **우리 적용**:
  - 30초 운전데이터로 **느린 루프(온도/레벨)는 동역학 모델 ID 가능** → MPC 구성 가능. 빠른 유량은 ID 한계(해상도 부족).
  - 단점: 좋은 동역학 모델이 전제. 우리의 "정상상태 맵 + 데드밴드 트림"은 이 모델 의존도를 낮춘 실용적 절충.

### 2위 — MFAC (Model-Free Adaptive Control)
- **문헌**: Zhongsheng Hou & Shangtai Jin, *Model Free Adaptive Control: Theory and Applications*, CRC Press (2013). 원개념 Hou, 1994.
- **링크**: https://www.taylorfrancis.com/books/mono/10.1201/b15752/model-free-adaptive-control-zhongsheng-hou-shangtai-jin
- **요지**:
  - **모델 없이 입출력(I/O) 측정 데이터만으로** 제어기 설계·안정성 분석. 핵심은 **동적 선형화(dynamic linearization, pseudo-partial-derivative)** — 매 시점 등가 선형모델을 데이터로 추정.
  - 미지의 이산시간 **비선형·시변** 시스템 대상. 1차 원리/system-ID로 모델링이 어려운 복잡 공정에 적합.
  - 산업 적용 사례 다수(주로 중국). MFAC + 예측제어 + 반복학습제어(ILC)로 확장.
- **우리 적용**:
  - "PID·모델 없이 데이터로 제어"라는 우리 취지에 직접 부합. MPC처럼 사전 모델이 필요 없음.
  - 단 적응 게인이 들어가므로 **hunting 방지 가드(데드밴드·dwell·rate-limit)와 병행** 필요.

### 우리 방향과의 관계
우리가 설계한 **"정상상태 맵 + gentle 제어(데드밴드/dwell)"** 는 화려한 RL보다 **MPC/supervisory 계보(수십 년 실증)에 가깝다.** 즉 방향이 검증된 쪽에 붙어 있어 de-risk됨. 추가로 **퍼지/전문가 시스템 supervisory control**(시멘트 킬른·철강 등)은 "오퍼레이터 지식→자동화"를 수십 년 실증한 가장 직접적 계보 — 별도 사례조사 가치 있음.

---

## 12. 1위 심화 — 산업용 MPC 정밀 분석

> ★핵심 발견★: 상용 MPC는 **2단 구조**이며, 우리가 독립적으로 설계한
> "정상상태 맵 + gentle 동적 제어"가 **산업 표준 아키텍처와 동형**.

### 12.1 동작 원리 — Receding Horizon
매 주기: ① 모델로 미래구간(P) PV 예측(미래 OP 시퀀스 M의 함수) → ② 비용
`J = Σ(SP−PV_예측)² + λ·Σ(ΔOP)²` 을 제약(`OP_min/max`, `|ΔOP|≤rate`, `PV 한계`)
하에 최소화 → ③ **첫 수만 적용**, 다음 주기 재측정 후 재최적화.
PID는 "현재 오차"만, **MPC는 "미래 궤적"을 본다**는 게 본질 차이.

### 12.2 ★상용 MPC = 2단 구조 (우리 설계와 동형)★
Aspen DMC3 / Honeywell Profit Suite 등 상용 패키지 구조:
```
[상층] LP/정상상태 최적화  → "어디로" (정상상태 OP/PV 타깃)
[하층] 동적 MPC           → "어떻게 부드럽게" (move 최소화)
```
→ **우리 `OP_ss=f(정착PV,부하)` 맵 = 상층 LP의 데이터 기반판. 데드밴드/dwell 트림
= 하층 동적 MPC의 경량판.** 우리 설계가 수십 년 검증된 표준 골격과 같음 = de-risk.

### 12.3 왜 PID보다 hunting이 적나
| Hunting 원인 | MPC 처리 |
|---|---|
| ② 데드타임 | 모델이 지연응답을 명시 예측 → "효과 볼 때까지 대기". **MPC 최대 강점** |
| ① 과도 게인 | move suppression λ로 공격성 조절 (λ↑ = gentle = 오퍼레이터처럼) |
| 다변수 간섭 | 모델이 상호작용 포함 → decoupling 내장 |
| 제약/windup | OP·rate 한계를 최적화에 명시 → windup성 진동 없음 |

단 **③ stiction(한계주기)은 MPC도 못 고침** (공격적 MPC는 오히려 자극).
처방 동일: **λ↑ + 데드밴드** → 데드타임·stiction 동시 대응.

### 12.4 핵심 제약 — 모델 필요 + 식별 문제 (최대 관문)
- 상용 MPC = step-response/FIR(DMC) 또는 저차 전달함수(FOPDT) 모델 사용.
- 식별엔 **여기성(excitation)** 필요 — 통상 step/PRBS **bump test**.
- **우리 데이터의 한계**:
  - operator MANUAL = **외란에 반응한 폐루프 데이터** → 입력·외란 상관 → 편향 모델 위험(폐루프 식별법 필요).
  - **30초 해상도** → 느린 루프(온도/레벨) ID 가능, **빠른 유량 부족**.
  - → **느린 파일럿 루프 + 가동 중 소수 bump test** 보강이 현실적.

### 12.5 벤더 실증 계보 (Qin & Badgwell)
- **DMC** (Cutler & Ramaker, Shell 1980) → AspenTech → **DMCplus / DMC3**
- **Honeywell RMPCT** (Robust Multivariable Predictive Control Technology) + Profimatics PCT → **Profit Controller / Profit Suite**
- **IDCOM/HIECON** (Adersa) — 최초 상용 MPC
- 정유·석화 중심 **수천 건 실제 설치**.
- **HC900이 Honeywell** → Profit 계보와 개념적 한 식구(단 Profit은 Experion/TPS급, HC900 소형 → 자체 구현 필요).

### 12.6 우리 시스템 적용 아키텍처
```
C# 크롤러 = MPC 호스트
  PV/부하 읽기(gRPC 캐시 ~1s)
   → [상층] 데이터 정상상태 맵 → OP_ss 타깃
   → [하층] move-suppressed QP → ΔOP 1수
   → WriteTag로 OP (FeedforwardWriteGuard 상하한/rate)
  1초 주기 = 느린 루프엔 충분
  로드맵 동일: shadow → assist → guarded closed-loop
```

### 12.7 갭/리스크
1. **모델 ID**: 폐루프·외란상관·30초 → bump test는 *보조*. **MANUAL OP step ≈ 개루프 데이터**라 기존 데이터만으로 식별 우선 시도 (→ §13.0 참조).
2. **계산**: .NET QP 솔버(소형·1초면 충분), 무제약 DMC+클램프로 간이화 가능.
3. **설명가능성**: MPC는 룩업맵보다 덜 직관 → assist 모드 + 제약/타깃 화면표시로 보완.
4. **유지보수**: 모델 드리프트 → 주기적 re-ID.
5. **stiction**: MPC 미해결 → 데드밴드 레이어 필수.

### 12.8 권고
- **Full 상용형 MPC를 처음부터 가지 말 것** (모델ID·계산·신뢰 부담).
- 대신 **2단 구조 경량화**: `정상상태 맵(데이터)` + `강한 move-suppress 예측 트림`
  = **"우리 데이터·제약에 맞춘 경량 MPC"** (산업 표준 골격과 일치).
- 파일럿 = **느린 루프(온도/레벨)** — 기존 MANUAL 데이터로 식별 우선, bump test는 필요 시 보조.
- 착수 순서 추천: **(a) 상층 정상상태 맵 먼저**(데이터만으로 가능) → 이후 **(b) 하층 모델 식별**(기존 데이터 우선, bump test 보조).

### 12.9 참고 링크
- Qin & Badgwell 서베이: https://www.sciencedirect.com/science/article/abs/pii/S0967066102001867
- 상용 MPC 2단(LP+동적) 구조 설명: https://www.picontrolsolutions.com/blog/picontrol-closed-loop-time-domain-technology-helps-on-aspen-dmc-honeywell-rmpct-profit-emerson-and-other-mpc-software/
- Honeywell Profit Controller / RMPCT 개요: https://www.scribd.com/document/90410821/Profit-Controller-Rmpct-Overview

---

## 13. 기능 로드맵 — PiControl/PITOPS 벤치마크

> 출처: `docs/PITOPS-브레인스토밍-웹페이지복사.md` (PiControl 제품 페이지).
> PiControl 3제품 = 3개 기능 기둥. **제품을 사는 게 아니라 핵심 아이디어를 C# 스택에 내재화.**
> - **APROMON** = 루프 성능 모니터링(CLPM)
> - **PITOPS** = 다변수 폐루프 시스템 식별 + 다목적 PID 튜닝 + APC 설계
> - **COLUMBO** = MPC 모델 유지보수(오프라인 Excel)

### 13.0 ★핵심 시사점 — bump test 걱정 완화★
PITOPS의 셀링포인트가 우리 §12.4 난제와 동일: *"정상운전·폐루프 데이터에서 step test 없이 모델 식별 — 진동/불안정/stiction/고잡음/미측정외란 데이터에서도 전처리 없이."*
- 우리만의 추가 행운: 플랜트가 **100% MANUAL** → 오퍼레이터 OP 계단 조작 = **개루프 step 데이터가 몇 달치 흩어진 셈** → PITOPS가 어렵게 푸는 폐루프보다 **오히려 식별이 쉬움**.
- 남은 과제 = "오퍼레이터 move vs 외란" 분리 → PITOPS의 **미측정 외란 패턴 식별** 기능이 담당.
- **결론**: 기존 MANUAL 데이터만으로 모델 식별 우선 시도, bump test는 보조 (§12.4·12.7·12.8 갱신 반영).

### 13.1 기둥 A — 루프 헬스 모니터링 (APROMON 류) · 우선순위 **즉시**
dump만 있으면 바로 구현 가능. 부수효과로 **파일럿 루프를 데이터로 객관 선정**(§9 미해결 자동 해결).
- 루프별 KPI: **진동지수(oscillation index)**, **time-in-manual %**, SP추적오차, **IAE**, **밸브 이동률(OP travel)**, **SNR**
- 30+ 기준 → 단일 **Grade(0~100)**
- **valve stiction 감지**, **frozen/noisy 센서 감지**
- 임계 이하 루프 자동 플래그 → 우선순위 작업목록 (수작업 트렌드 감사 대체)
- ※ 우리 §5 "hunting 자동 감지기"의 상위 일반화

### 13.2 기둥 B — 시스템 식별 엔진 (PITOPS 류) · 우선순위 **중** (MPC 전제)
- MANUAL/operator 데이터 → **FOPDT·2차·적분형·deadtime·개루프불안정** transfer function 피팅
- **시간영역**(Z변환 불요) **제약 비선형 최적화**
- **미측정 외란 패턴 식별·분리**(트렌드로 표시)
- **stiction/hysteresis 동시 식별**
- SISO/MISO 다변수, 초~분 다중 스케일
- = §12의 MPC 모델 엔진 + 상층 정상상태 맵의 동역학 보강

### 13.3 기둥 C — 다목적 제어 설계 (PITOPS 류) · 우선순위 **중**
- 목표함수에 **외란(펄스/스텝/램프/사인)·노이즈·OP rate·valve stiction·비선형 게인** 반영
- = 우리 hunting-averse 제어의 데드밴드/dwell/rate-limit를 **정량 목표**로 일반화
- what-if 시뮬(추정 파라미터로 시나리오 비교)

### 13.4 부가 규약
- **검증 지표**: FIT(%)·IAE·NRMSE
- **TTSS(Time to Steady State)** 도구 → 우리 §9 "정상상태 세그먼테이션"과 직결
- **데이터 규약**: CV/MV/DV(=PV/OP/외란) 컬럼 구조 → 학습 파이프라인 입력 포맷 채택
- **보안 모델**: 식별/학습은 **DB dump 오프라인**으로 (레벨3 네트워크 미접속, COLUMBO 철학)
- 데이터 규모: 단일 케이스 ~10만 행급 처리

### 13.5 우리 플랜과의 연결
1. **기둥 A부터** (dump 직후 즉시) → 파일럿 루프 객관 선정 + hunting/stiction 진단
2. **기둥 B** = §12 MPC/정상상태 모델 엔진의 청사진
3. **기둥 C** = §5 hunting 방지 가드의 정량화

### 13.6 참고 링크
- PiControl 제품 페이지 원문: `docs/PITOPS-브레인스토밍-웹페이지복사.md`
- COLUMBO(MPC 유지보수): 정상운전 데이터로 MPC 모델 refit, 오프라인 Excel

---

## 14. 데이터 반입 절차 (SOP) — 현장 DB → 우리 환경

> **전제: 현장에서는 점검·선별이 불가.** 그래서 현장은 **DB 전체를 한 줄로 dump해 파일만 전달**하고,
> 테이블 구조 파악·TimescaleDB 처리·복원·최적화는 **전부 우리 쪽에서 파일로부터** 한다.
> 결론: **별도 DB `field_hist`** 로 적재(별도 스키마 아님 — `-Fc`가 원본 스키마명을 박아 충돌/rename
> 문제 → 별도 DB가 충돌0·복원1방). 라이브 `hc900`(DB `iiot_platform`) 안 건드림.

### 14.0 우리 환경 (확정)
- PG16 + TimescaleDB 컨테이너 `iiot-timescaledb` (`timescale/timescaledb-ha:pg16`), 5432.
- 운영 DB `iiot_platform`, 스키마 `hc900`, user `postgres`.
- **pg 클라이언트 도구는 컨테이너 안에만** → 모든 복원은 `docker exec`.

### 14.1 현장이 할 일 — 딱 한 줄 (전체 DB dump)
```bash
pg_dump -U <사용자> -d <DB이름> -Fc -Z6 -f field_full.dump
```
- **DB 전체** 통째. 테이블명·구조 몰라도 됨, 점검 불필요.
- `-Fc` 단일 압축파일(USB 운반 쉬움), `-Z6` 압축.
- 결과 **`field_full.dump` 파일 하나만 전달**.

**변형:**
- DB 이름 모를 때: `psql -U postgres -l` 로 목록 확인 후 위 명령에 사용.
- 명령줄 불가, pgAdmin(GUI)만: 대상 DB 우클릭 → **Backup...** → Format **Custom** → 저장 (= `-Fc`).
- 같이 알려주면 좋은 것(몰라도 진행 가능): 파일 **대략 용량**(수백MB/수GB/수십GB) → 복원 병렬도·디스크 준비용.

### 14.2 우리가 할 일 ① — 파일에서 점검 (현장 점검 대체)
```bash
pg_restore -l field_full.dump | head -50    # PG버전·스키마·테이블·인덱스 목록
```
→ 이력 테이블명·컬럼(PV/SP/OP/MODE/외란)·timestamp 컬럼·TimescaleDB 여부를 **파일에서 직접 파악**.

### 14.3 우리가 할 일 ② — 별도 DB로 복원
```bash
docker cp field_full.dump iiot-timescaledb:/tmp/
docker exec -i iiot-timescaledb psql -U postgres -c "CREATE DATABASE field_hist;"
docker exec -i iiot-timescaledb pg_restore -U postgres -d field_hist \
  -j 4 --no-owner --no-privileges -v /tmp/field_full.dump
```

### 14.4 우리가 할 일 ③ — TimescaleDB 최적화 (이력 테이블 확인 후)
```sql
-- field_hist DB. <history_table>·<ts>·<tagname>은 14.2에서 파악한 실제값
CREATE EXTENSION IF NOT EXISTS timescaledb;
SELECT create_hypertable('<schema>.<history_table>', '<ts>', migrate_data => true);
ALTER TABLE <schema>.<history_table>
  SET (timescaledb.compress, timescaledb.compress_segmentby = '<tagname>');
SELECT add_compression_policy('<schema>.<history_table>', INTERVAL '7 days');
CREATE INDEX ON <schema>.<history_table> ('<tagname>', '<ts>' DESC);
```

### 14.5 주의
- **버전 호환**: PG16 `pg_restore`가 구버전 `-Fc` dump 복원 가능(forward 호환).
- **현장이 TimescaleDB인 경우**: 전체 `-Fc` dump에 하이퍼테이블 청크가 포함됨 → 복원 시 일부 오류 가능. 그때 우리 쪽에서 `SELECT timescaledb_pre_restore();` → 복원 → `timescaledb_post_restore();` 순서로 재처리. **현장은 신경 안 써도 됨**(우리가 14.2에서 감지해 처리).
- **복원 튜닝**: 대용량 시 `SET maintenance_work_mem='1GB'; SET synchronous_commit=off;` + `-j` 병렬.
- **분석 접속**: `field_hist` 전용 연결문자열만 추가 (`hc900`과 조인 불필요).

### 14.6 파일 도착 후 즉시 (요약)
1. `pg_restore -l` 로 구조 파악 → 2. `field_hist` 복원 → 3. 하이퍼테이블+압축 → 4. §13.1 기둥 A KPI 쿼리 착수.

---

## 15. 실데이터 구조 — shinam dump (2026-06-05 반입·복원 완료)

> 파일 `docs/PG-Dump-20260605/field_full_shinam.dump` (453MB, PG9.5.25 커스텀 dump) →
> **별도 DB `field_hist`** 로 복원 완료(iiot_platform 안 건드림, 무해 경고 1개: public 스키마 중복).
> 현장 = **신암정유(주)**, 소스 DB명 `shinam`.

### 15.1 기간·해상도 (확정)
- 기간: **2026-02-05 12:53 ~ 2026-06-05 11:22** (약 120일 ≈ 4개월).
- 간격: **주로 30초** (2월 일부 60초 혼재, 간헐적 공백=재기동/다운타임). `dtat` 유니크.
- cont001 행수 336,519 (테이블별 20만~33.6만).

### 15.2 데이터 모델 — WIDE 포맷 + 디코드 테이블
- **`cont001`~`cont017`** (17개): 시계열 본체. 컬럼 = `dtat`(timestamp) + `col01..colNN`(real). 설명 "신암정유(주) 아날로그 모니터링 포인트 (Read Only)".
- **`ptlist`** (799행): 포인트 정의. `pid, ptname(예 /ASSETS/P10/TI-10117.PV), shortptname, asset, cont`.
- **`tblist`** (17행): 테이블 정의. `tid, tblname(cont0NN)`.
- **`mapping`** (817행): `tid, pid, oit` — **어느 테이블(tid)의 어느 컬럼(oit)이 어느 포인트(pid)인지** 디코드.
- `cont`·`batch`·`batchlist`: 0행(비어있음).

### 15.3 ★태그 시계열 복원 규칙 (검증 완료)★
```
ptname → ptlist.pid
       → mapping(pid) → (tid, oit)
       → tblist(tid)  → tblname
       → SELECT dtat, col{oit:2자리0패딩} FROM {tblname} ORDER BY dtat
```
- **oit는 colNN에 직결** (oit=3 → col03). 검증: `TI-10117.PV` → cont015.col03 → ~22°C(온도 합리값).
- 한 루프(PV/SP/OP)는 **서로 다른 cont 테이블·컬럼에 흩어져 있을 수 있음** → 시간축(dtat)으로 조인.

### 15.4 접미사 분포 — OP/SP/PV 확인 (make-or-break 통과)
| 접미사 | 개수 | 비고 |
|---|---|---|
| **PV** | 456 | 공정값 |
| **SP** | 114 | 설정값 (신뢰도 ~80%, §4) |
| **OP** | 106 | ✅ **제어출력 존재** |
| FIELDVALUE | 55 | |
| QV | 32 | 적산/유량 추정 |
| VALUE | 29 | |
| LSET | 6 | local setpoint? |
| HZSET | 1 | |

- **PV+SP+OP 완비 루프 = 104개** (PV+OP만 = 106). → imitation/학습 대상 루프 ~104개 확보.

### 15.5 진공(PID) 루프 제외 규칙 (확정)
- **진공 = 압력제어기 `PICA-*`** (OP 보유 12개) → AUTO/PID 루프이므로 **학습 대상에서 제외**.
  - 제외 12: PICA-111, -2111, -2121, -3203, -5111, -6111, -6211, -8111A, -9111A, -9211A, -10111A, -10211A
- `PI-*`(43개)는 전부 PV만 = 단순 압력지시계 → 어차피 제어루프 아님(무관).
- 제외 SQL: `WHERE upper(split_part(base,'-',1)) <> 'PICA'`.
- (MODE 태그는 없음 — 100% MANUAL이라 미기록. 위 PICA 제외로 AUTO/MANUAL 구분 대체.)

### 15.6 학습 대상 루프 인벤토리 (PV+SP+OP 완비, PICA 제외 = **91개**)
| 계기 | 루프수 | 종류 | 파일럿 적합성 |
|---|---|---|---|
| **TICA** | 12 | 온도제어 | ★ **느림 → 30초 적합, 첫 파일럿 이상적** |
| **LICA** | 20 | 레벨제어 | 비교적 느림 (차순위) |
| LIC/LISA | 3 | 레벨 | |
| **FICQ** | 54 | 유량(적산) — 다수. ※사용자 feed-ramp의 FICQ 계열 | 빠름 → 나중 |
| FICA | 1 | 유량제어 | 빠름 |
| AIC | 1 | 분석기 제어 | |
- 전체 완비루프 103 = 진공 12 + 학습대상 91.
- **플랜트 인코딩**: 태그 숫자 앞자리 = 차수(1~6,8,9,10 / **7차 없음**), `ptlist.asset`=`/ASSETS/Pn`이 차수 보유. 91개 분포: P6=15, P1=15, P10=14, P9=14, P2=14, P5=7, P8=6, P3=3, P4=3. TICA는 P6·P9·P10에 각 2개.

### 15.9 플랜트 분류 & 개발 전략 (사용자 도메인 지식)
**활성 플랜트 = 1, 2, 5, 6, 8, 9, 10** (3·4차는 **죽은 플랜트, 안 씀** → 제외. 7차 없음.)

| 플랜트 | 유형 | 비고 |
|---|---|---|
| **6, 8, 9, 10** | **측류(side-draw) 반도체용 솔벤트** | 동일 유형(형제). 6차용 만들면 8·9·10 확장 |
| **1, 2** | 측류 아님 — **2컬럼 경질/중질 제거 일반 증류** | 별도 유형 |
| 5 | (유형 미확인, 활성, 7루프) | 확인 필요 |
| ~~3, 4~~ | **죽은 플랜트 — 제외** | |

**개발 순서**:
1. **6차 먼저** — HC900 **통신이 살아있음**(현재 live 값은 가공이라도 실 제어경로 shadow→assist→closed 테스트 가능). 6차 = 측류 솔벤트 대표.
2. → **8·9·10차** (동일 유형, 코드 재사용)
3. → **1·2차** (2컬럼 일반증류, 제어구조 다름)
4. 5차는 유형 확인 후.

**학습 대상 루프(활성, 3·4 제외)**: P6=15, P1=15, P10=14, P9=14, P2=14, P5=7, P8=6 → **계 85개**.

### 15.10 6차 학습 데이터 출처 — 판정: **실데이터** (2026-06-05 검증)
사용자: "6차 플랜트 데이터가 가공". → dump 속 P6를 통계 지문으로 판별한 결과 **실 오퍼레이터 데이터로 강하게 판정**:
- **인과성 corr(PV,OP)**: FICQ-6101 0.72, TICA-6111A 0.88 (실 공정 물리 — 가공 노이즈면 ≈0)
- **OP 평탄율 98%** + 수천 이산 스텝 + 유지구간 들쭉날쭉(중앙 8분~최대 53h) = 전형적 수동조작 서명
- 센서 노이즈(음수 영점 포함)·SP distinct 3~11·반복성 없음 모두 현실적
- (LICA-6113은 OP 전구간 0 = 미사용 루프일 뿐)
- **해석**: 사용자의 "가공"은 현재 **HC900 live 피드(실시간 테스트 시뮬값)**를 지칭한 것으로 추정. shinam dump의 P6 이력은 실데이터.
- **결론**: **6차를 P6 실이력으로 직접 학습** 가능(형제 우회 불필요). 학습·배포 모두 6차 일관.
- ✅ **사용자 확정(2026-06-05): "완벽한 현실 데이터, 의심하지 마." → dump P6 = 실데이터 확정.** "가공"은 live 피드 지칭.

### 15.11 6차 내부 구조 & OP 활동 스크린 (2026-06-05)
**6차 = 6-1차(태그 61XX) + 6-2차(62XX), 두 train 독립 운전(연관 없음, 컬럼별 독립).**
- 6-1차: TICA-6111A, FICQ-6101/6113/6114/6116/6118, (PICA-6111=진공 제외)
- 6-2차: TICA-6211A, FICQ-6201/6213/6214/6216/6218, (PICA-6211=진공 제외)
- ★모델링 함의: 한 train 루프의 **부하/외란 피처는 같은 train 안에서만** 사용. 6-1↔6-2 교차 피처 금지. 각 train = 독립 모델링 단위.

**OP 활동 스크린 (평탄율=OP 정지비율, chg=수동 스텝 수)**:
| 루프 | flat% | OP변경 | 판정 |
|---|---|---|---|
| TICA-6111A | 98.0 | 6590 | ★수동, 풍부 (6-1 파일럿) |
| TICA-6211A | 97.7 | 7651 | 수동, 풍부 (6-2) |
| FICQ-6101/6113/6201/6118/6213/6218… | 98.4~99.7 | 850~5458 | 모두 수동 서명 |
| **LICA-6113/6128/6213** | 100.0 | **0** | **OP=0 사장루프(미사용) → 제외** |

- AUTO 의심(평탄율 급락) 루프는 전체기준 없음 → 간혹 있다는 AUTO 기간은 **소수 구간** → 학습 시 **세그먼트 단위 AUTO 탐지**(OP 연속변동 구간)로 제거 필요(§4·§13.1 time-in-manual). MODE 태그 없으니 OP 거동으로 판별.
- **6차 활성 제어루프**: 6-1차 6개(TICA-6111A + FICQ 5) + 6-2차 6개. LICA 3개는 사장.

### 15.7 ⚠️ 잔여 주의
- "Read Only 모니터링 포인트" 설명 → OP가 오퍼레이터 실제 조작값인지 1차 확인 권장(맞을 것으로 판단).

---

## 16. 6-1차 파일럿 (TICA-6111A) — 착수

### 16.1 6-1차 컬럼 C-6111 — 권위 토폴로지 (기존 `hc900.ff_column_config`/`ff_stream_config`에서)
> ★피처 역할을 추측할 필요 없음★ — 팀이 이미 정의해둠. column_id=1, name=**C-6111**, enabled=t, **advisory_only=t**(이미 자문모드 가동).

| 역할 | 태그 | 출처 컬럼 |
|---|---|---|
| **제어출력 OP(학습대상)** | **TICA-6111A.OP** = 리보일러 **스팀 밸브(조작)** | steam_op_tag |
| **스팀 유량(측정)** | **FIQ-6115** (cont008 PV37/QV38) = 실제 스팀유량/열입력 | 사용자 도메인 |
| **제어온도(target)** | 민감단 **TI-6111C** | sensitive_tray_tag |
| 온도 프로파일 | TICA-6111a, TI-6111b, TI-6111c, TI-6111d | temp_tags |
| **피드(주 외란)** | **FICQ-6101** | feed_tag |
| 진공압력 | **PICA-6111** | pressure_tag |
| 컬럼 차압(플러딩) | **PI-6111B** | delta_p_tag |
| 온도 상한 | 89.5 / p_ref 50 | temp_high_limit |

**스트림 역할 (ff_stream_config, column_id=1)**:
| key | 태그 | role | 비고 |
|---|---|---|---|
| **P(★측류 제품)** | FICQ-6118 | Commanded | **반도체 솔벤트 제품 = 진짜 측류(side-draw)**. coeff 0.95, θ60/60, τ900 |
| R(리플럭스) | FICQ-6113 | Commanded | is_reflux, reflux_from_product |
| D(경질분 제거) | FICQ-6114 | LevelDriven | **측류 아님** — 리플럭스 라인의 **경비물(경질분/light) 제거** 유량. level=lica-6113, grade B |
| B(중질분 제거) | FICQ-6116 | LevelDriven | **보텀 아님** — **중비물(중질분/heavy) 제거** 유량. level=li-6111, grade B |

> **컬럼 본질**: C-6111 = **측류 정제 컬럼**. 측류 제품 P(FICQ-6118, 반도체 솔벤트)를 가운데서 뽑고, 경질분(D)·중질분(B)을 양쪽으로 퍼지, 리플럭스(R) 환류. 오퍼레이터는 스팀(TICA-6111A.OP)으로 온도 프로파일(민감단 TI-6111C)을 잡아 이 분리·순도를 관리.

> ★운전 현실(사용자)★: **D(FICQ-6114)·B(FICQ-6116)은 유량이 작아 제어가 어려워 대부분 고정 운전** (스크린 평탄율 99.6~99.7%로 일치). → 모델에서 **준상수**로 취급(능동 조작변수 아님). **오퍼레이터 핵심 레버 = 스팀(TICA-6111A.OP/FIQ-6115) + 리플럭스(FICQ-6113) + 측류제품(FICQ-6118)**. 피드 FICQ-6101은 주 외란.

**센서 물리 위치 (사용자 도메인) — C-6111 수직 프로파일 하부→상부**:
| 태그 | 위치 | 모델 의미 |
|---|---|---|
| **TICA-6111A** | 리보일러 온도(최하부, 최고온) | 스팀 직접 제어점(OP 연결) |
| **TI-6111B** | 중간부, **원료투입 디스트리뷰터 위** | 피드존 온도 |
| **TI-6111C** | 중상부, 팩킹 넘어 **제품 추출 트레이 근처** | ★**민감단=측류제품(FICQ-6118) 순도 직결**(sensitive_tray) |
| **TI-6111D** | 상부 리플럭스 디스트리뷰터 밑(최저온) | 탑상 온도 |
| TI-6103 | **원료 예열 온도** | 주 외란(피드 엔탈피) |
| TI-6117 | 제품 탱크 이송 전 온도 | 다운스트림(제품 상태 — 제어입력 아님, 품질 프록시 가능) |
| LI-6111 | **리보일러 레벨** | 하부 인벤토리/하이드롤릭 |
| LICA-6113 | **리플럭스 드럼 레벨** | 환류 인벤토리 |

> **온도 순서 A > B > C > D** (리보일러 최고온 → 탑상 최저온, 단조 감소 구배). 정상 분리 = 이 구배 유지, 구배 붕괴=분리 이상 신호.
> ΔT(인접단 차, 예: A−B, B−C, C−D)가 **분리도 지표** → 피처로 사용. 모델: `스팀 = f(목표 TI-6111C, 피드 FICQ-6101, 원료예열 TI-6103, 리플럭스 FICQ-6113, 측류 FICQ-6118, 진공 PICA-6111)`.

- **제어 철학**: 오퍼레이터가 **스팀(TICA-6111A.OP)** 으로 민감단 온도(TI-6111C)를 잡고, **피드 FICQ-6101**·진공·스트림이 외란. → 모델 `OP_ss = f(목표온도, FICQ-6101, PICA-6111, PI-6111B, 스트림유량…)`.
- **저장탱크 온도 제외**(사용자): TI-6117, TI-6121/6122/6123/6125/6126.
- ★기존 ff 시스템(FeedforwardSupervisor 등)이 C-6111에서 이미 advisory로 가동 중 → 우리 학습형 맵은 **이와 연계/보완**(중복 금지). FROM-TO·역할은 `ff_*`·`pid_equipment.from_tag/to_tag`에서 읽음.

### 16.2 파일럿 적합성 (TICA-6111A 실측)
- OP 가동률 **99.4%** (거의 항상 활성) · 정상상태 **92.7%** (정상상태 맵 학습에 풍부)
- **SP 신뢰 67%**(±2 이내) → SP 불완전 확정 → **§4대로 정착 PV를 target으로** 사용이 옳음.
- 평균 |SP−PV| 1.51 (오퍼레이터가 PV를 목표 근처로 잘 유지)

### 16.3 다음 모델링 단계 (오프라인, Python)
1. field_hist에서 TICA-6111A + 6-1 피처 풀 pull.
2. **★운전상태 분류 (필수 전처리)★** — 각 시점을 다음 모드로 라벨:
   - **STOPPED**(유량0·실온) / **STARTUP**(승온) / **LINEOUT-전환류**(hot+진공ON **but 측류제품 FICQ-6118≈0**, 리플럭스 높음, 저부하 — 프로파일 정렬·랩샘플 대기) / **LOAD-RAMP**(피드·제품 상승중) / **RUNNING-생산**(피드·제품 정상범위, 정상상태) / **SHUTDOWN**(하강).
   - 판정 신호: 피드 FICQ-6101, 리보일러온도 TICA-6111A, 진공 PICA-6111, **측류제품 FICQ-6118(≈0=전환류 핵심 판별)**, 리플럭스/제품 비.
   - **정상상태 맵 학습 = RUNNING-생산 구간만** (여러 로드율의 정상점은 **모두 유효** → 운전점 커버리지↑). **LINEOUT·LOAD-RAMP·STARTUP·SHUTDOWN·STOPPED 전부 제외**.
   - ★STARTUP/SHUTDOWN/LOAD-RAMP/LINEOUT 과도는 **버리지 말고 1급 데이터로 보존·라벨**★ — (a)동특성 식별 + (b)**START-UP/SHUTDOWN 절차학습(②③)의 학습데이터**(§16.4).
   - ※ 기존 `hc900.v_plant_running_state`(+_corroborated, vacuum_torr/pump 기반) 판정 로직을 field_hist에 재현.
   - 💡 향후: 라인아웃→제품컷 시점 학습 시 **START-UP 어드바이저**(언제 로드 올릴지)로 확장 가능 — 현 스코프 밖, 메모.
4. AUTO 구간 제거(OP 연속변동 탐지), off-spec 제외, 정상상태 세그먼트(dPV≈0·dOP=0) 추출.
5. **`OP_ss = f(정착PV, 6-1 부하)`** 회귀(설명가능 모델: 선형/GBM/GMR) + 피처 중요도·잔차 분석.
   - ★스팀유량 FIQ-6115 활용 두 갈래★:
     - (밸브특성) OP(TICA-6111A.OP) ↔ FIQ-6115 관계 학습 → **밸브 stiction/비선형 진단**(§5).
     - (에너지모델) target = **스팀유량 demand** `FIQ-6115_ss = f(목표온도, 피드 FICQ-6101, 진공, 스트림)` → 밸브문제와 분리, 더 강건. 이후 유량→밸브% 역변환.
6. 산출물: 맵 + FIT/IAE 검증 + "오퍼레이터 OP가 가용변수로 얼마나 설명되나".
   → 이후 shadow 모드용 예측기로 연결(§7).

### 16.4 학습 대상 3종 (스코프 확장 — 사용자)
정상상태만 학습하지 않는다. START-UP/SHUTDOWN 절차도 결국 학습(안전 자동화).
| # | 대상 | 문제 유형 | 시점 |
|---|---|---|---|
| ① | 정상 생산 제어 | 정상상태 맵 `OP_ss=f(...)` (회귀) | **현재** |
| ② | **START-UP 절차** | **시퀀스/절차 모방** — 시간순 동작 + **전이 트리거**(예: 프로파일 정렬+샘플OK→제품컷→로드램프) | 추후 |
| ③ | **SHUTDOWN 절차** | 시퀀스/절차 모방(역순, 안전) | 추후 |
- ②③은 ①과 문제 종류가 다름: "조건→OP"가 아니라 **"상태→다음단계 언제·어떻게"**. 궤적/절차 학습.
- ★**6모드 상태분류기(§16.3-2)가 ②③의 backbone**: STOPPED→STARTUP→LINEOUT→LOAD-RAMP→RUNNING→SHUTDOWN 전이를 학습. 상태분류 = ① 필터 + ②③ 골격 이중역할.
- 안전 중요(반도체 솔벤트 startup/shutdown = 고위험 과도). → 과도구간 데이터 1급 보존 필수.

### 16.5 진행 로그 (2026-06-05)
**착수 완료 — 추출기 + 운전모드 분류 + 타임라인 검증.** 코드: `scripts/analysis/c6111_extract.py`
(재사용 추출기 `tag_frame()` = ptlist/mapping/tblist 디코드). 산출: `c6111_data.pkl`, `c6111_timeline.png`, `c6111_episode.png`.
- **운전모드 분포**(4개월): PROD 99.2%(2781h), SHUTDOWN 0.4%, LINEOUT 0.2%, STARTUP/STOPPED 각 0.1%.
- **여러 로드 캠페인** 확인(3~4월 고부하 ~700-900, 5월초 이후 저부하 ~400) → 맵 운전점 커버리지 양호.
- **과도 에피소드 ~4회**(5/13 10h, 4/30 7h, 5/2, 2/15) — 각각 깨끗한 shutdown→냉각→startup 사이클.
- ★STARTUP 절차 실데이터 검증: 진공재확립→스팀투입→승온→**전환류(리플럭스 ON, 제품 0)**→정렬→**제품컷인**→생산. 사용자 설명과 일치.
- 임계(분포 기반): hot&vacuum = reb_temp>60 & vacuum<200 & steam_op>5; 전환류 = product<80.
- ⚠️ 절차학습(②③)은 **few-shot(~4 에피소드)** — 6-2·8·9·10 동일유형 에피소드 합치면 샘플 보강 가능.
- 다음: ① **생산 정상상태 맵** (PROD 구간, 밸브특성 OP↔FIQ-6115 + `스팀=f(목표온도,피드,…)`).

### 16.6 ① 생산 맵 결과 (2026-06-05) — 코드 `scripts/analysis/c6111_prodmap.py`
- **밸브특성**: 스팀유량 ≈ 18.5·OP − 220 (OP 22~48%→flow 98~698). **히스테리시스 0.4% = stiction 사실상 없음** → 이 컬럼 hunting은 스팀밸브 원인 아님.
- **★학습 단위 = 운전점(6h 중앙값)★**: 정상상태가 98%로 너무 안정 → 점단위 회귀는 캠페인내 변동 부족으로 실패(음의 R²). **6h 운전점(479개)으로 집계하면 해결**. steam vs feed에 **이산 로드 캠페인 클러스터**(feed≈400/500/700/800-900) 확인.
- **맵 `스팀유량 = f(피드, 제품, 목표 T_C)`**: GBM **test R²=0.993**, MAE 7.9(스팬 1.8%). Linear 0.987. **피드 단독 R²=0.985, steam/feed비=0.729**.
- 피처 중요도: **T_C 0.42 > feed 0.31 > product 0.26**, 나머지(예열·T_D·진공) ~0. feed_preheat 계수 음(−)=물리 정확.
- **함의**: 오퍼레이터 스팀 **99% 설명/학습 가능**. 본질은 **steam/feed 비율(~0.73) + 온도·제품 보정**. = 기존 `ff_column_config` steam/feed 계수를 **데이터로 검증·정밀화**(경로 나).
- ⚠️ 이건 **정상상태(에너지밸런스) 맵** = §4 OP_ss 베이스라인(전향). 아직 동특성·캠페인내 미세 온도제어(피드백 트림)는 별도.
- 다음 후보: (a) shadow-mode 예측기로 연결(live 피드/제품/목표→스팀 권장, 오퍼레이터 비교) / (b) 캠페인내 미세 온도 피드백(트림) 분석 / (c) 6-2·8·9·10 확장.

### 16.7 Shadow 예측기 백테스트 (2026-06-05) — 코드 `scripts/analysis/c6111_shadow.py`
시간 전진 분할(학습 2~4월 70% / shadow held-out 5월 30%), 스팀유량 예측 →밸브 역특성→ 예측 OP를 **실제 오퍼레이터 OP와 비교**. OOD(학습 운전envelope 1~99% 밖) 게이트 포함.
- **신뢰구간(in-envelope): OP MAE 0.80%, |예측−실제 OP|≤2% 가 94%** → **오퍼레이터 손을 충실히 모방**.
- **held-out 5월 = 100% OOD** (저부하 feed 378~423 < 학습하한 433, 목표 T_C도 85.3→84.0으로 낮춤). 예측 OP가 **체계적 +4.0%(std 1.1%) 과예측** = 외삽 바이어스.
- ★**OOD 게이트가 5월 전체를 정확히 플래그 → "오퍼레이터 폴백"** = §5 안전설계(범위밖→사람) 실증. shadow가 **나쁜 조언을 내기 전에 스스로 기권**.
- **교훈**: 모델은 신뢰구간에서 탁월(94% 일치)하나, **새 운전레짐엔 외삽 바이어스** → 반드시 (1)OOD 게이트 + 오퍼레이터 폴백, (2)연속/롤링 재학습으로 envelope 확장.
- 다음 후보: (1) **롤링 재학습** 데모(5월이 in-envelope가 됨을 확인) / (2) **operator-assist**(예측 OP 화면표시) / (3) 캠페인내 미세 온도 트림 / (4) 6-2·8·9·10 확장.

### 16.8 롤링 재학습 (2026-06-05) — 코드 `scripts/analysis/c6111_rolling.py`
walk-forward: 5월을 하루씩 전진, '그 날 이전 전체 이력(expanding)'으로 매일 재학습→그 날 예측. 입력 평활 인과(trailing).
| 모델 | 5월 OP MAE | ≤2% 일치 |
|---|---|---|
| 정적(2~4월 고정) | 3.88% | 3.7% |
| **롤링 재학습** | **1.17%** | **83.7%** |
- **적응 곡선**: 05-01 첫날 4%(OOD 100%) → **05-02 단 하루 흡수로 1.6%** → 이후 ~0.5%. **OOD 첫주 35%→0%**.
- 05-14~19 일시 상승(5/13 shutdown/startup 직후 sub-레짐) 후 자동 회복.
- ★**완성된 안전 설계**: 롤링 재학습(envelope가 플랜트 추종) + OOD 게이트(전이 첫 1~2일은 오퍼레이터 폴백) → 적응 후 94% 모방. 새 레짐 진입 시 사람이 잠깐 몰다 모델이 흡수.
- **결론**: ① 생산 제어의 offline 파이프라인(추출→모드분류→정상맵 R²0.99→shadow 94%→롤링 적응) **완주·검증**. 핵심 = `스팀≈0.73·피드 + 온도/제품 보정`, 롤링+OOD로 안전.
- 다음 후보: (2) operator-assist 패키징(예측 OP 화면) / (3) 캠페인내 미세 온도 트림(피드백) / (4) 6-2·8·9·10 확장 / (5) live C# shadow 포팅.

### 16.9 캠페인내 온도 트림 = gentle 피드백 (2026-06-05) — 코드 `scripts/analysis/c6111_trim.py`
부하 일정 구간(PROD의 70%)에서 오퍼레이터의 스팀 미세조정이 무엇에 반응하나 분석.
- **온도 유지 성능**: 목표대비 **reb-A·T_C 오차 std ≈ 0.07~0.09℃ (±0.13℃, 노이즈 수준)**. 극도로 안정.
- **OP는 1.3%만 이동**(98.7% 정지), dwell 중앙 21분.
- **트림 트리거 약함**: 작은 이동 dOP vs reb-A오차 corr **−0.245**(T_C −0.10보다 큼; TICA 직접변수). **데드밴드 차이 없음**(이동/비이동 |오차| 동일). 큰 이동(11회)은 **피드변화(−0.65)=전향**.
- ★**결론: 캠페인 내부에선 컬럼이 자기제어(self-regulating), 스팀 거의 개루프. 의미있는 피드백 트림이 거의 없음.** 제어는 **전향 맵(§16.6)이 지배**, 피드백은 미미(저게인 ~−0.6%OP/℃, 데드밴드 ~0.1℃=노이즈, dwell ~20분).
- **함의**:
  - **전향 맵(steam=0.73·피드+보정)이 사실상 정상생산 제어 전체.** §5의 "전향+gentle 데드밴드 트림" 중 전향이 압도적.
  - **hunting 저위험 설명**: 오퍼레이터가 공정과 싸우지 않음(스팀=부하, 온도 자기안정).
  - **자동화 가치 = 부하변동 시 일관된 전향 스팀 + 전이/startup 처리**, 정상 유지(쉬움)가 아님.
- 데이터 도출 gentle 제어 스펙: FF `steam=f(피드,제품,목표T_C)` + (옵션)경량 FB(reb-A오차, gain~−0.6, 데드밴드±0.1℃, dwell≥20분).

### 16.10 ② START-UP 절차 (2026-06-05, few-shot) — 코드 `scripts/analysis/c6111_startup.py`
전체 모드 데이터에서 **제품 컷인** 이벤트 탐지→정렬→중첩, 절차를 해석가능 레시피로 추출.
- 탐지 5건 중 **깨끗한 절차적 컷인 3건**(02-15, 04-30 22:00, 05-13; 컬럼 정렬 T_C~83-84℃, ΔT~2℃), 2건은 미정렬 블립(T_C 63-66, ΔT 30-50 — 비정상/부분).
- **★START-UP 레시피★** (시퀀스): STOPPED → 진공재확립 → **스팀투입·승온** → **전환류 라인아웃**(리플럭스 ON, 제품 0) → **제품 컷인** → **피드 램프** → 생산.
- **단계 타이밍**: 스팀투입→컷인(라인아웃 길이) **60~120분 가변**, 리플럭스확립→컷인 25~82분, 컷인→풀로드 빠름(0.5~18분).
- ★**제품 컷인 트리거 = 조건기반(시간 아님)**, 3건 일관: **reb-A 84.6±0.5℃, ΔT(A-D) 1.9±0.4℃** (프로파일이 생산상태로 압축=정렬 완료). 사용자 설명("정렬 상태 보고 로드 올림")과 정확히 일치.
- **→ START-UP 어드바이저 플레이북**: 승온 후 **reb-A≈84.5℃ & ΔT(A-D)≈2℃ 도달 시 제품 컷인** 권장, 이후 피드 램프. = 안전·설명가능 절차 자동화의 핵심 게이트.
- ⚠️ **few-shot(3 클린/4개월)** → 형제(6-2·8·9·10) startup 합치면 트리거 신뢰도·변동성 보강.
- 다음: 6-2·8·9·10 확장(샘플 보강+코드 재사용) / SHUTDOWN 절차(③) / operator-assist·live 포팅.

### 15.8 다음 액션
1. (선택) 큰 cont 테이블 TimescaleDB 하이퍼테이블+압축 (§14.5) — 분석 스캔 가속.
2. **§13.1 기둥 A**: 91개 루프 KPI(진동지수·IAE·OP travel·stiction) → 파일럿 선정. **TICA 12개부터** 권장.
3. §4 정상상태 세그먼테이션 + SP 신뢰도 실측 → `OP_ss=f(정착PV,부하)` 맵.
