Template

Files

windpacer 1bc46b1eb0 feat: 6-1차 컬럼 학습형 제어 오프라인 분석 (생산맵·shadow·startup)

신암정유 6-1차 측류 솔벤트 컬럼(C-6111) 실데이터로 오퍼레이터 모방 제어 분석:

- 데이터 추출기 tag_frame() (field_hist WIDE 포맷 디코드) + 운전모드 분류
- ① 생산맵: 스팀유량=f(피드,제품,목표T_C) 운전점 GBM R²0.99 (steam/feed≈0.73)
- shadow 백테스트: in-envelope 오퍼레이터 OP 94% 모방, OOD 게이트→폴백
- 롤링 재학습: 새 로드레짐 적응 (5월 OP MAE 3.9→1.2%)
- 캠페인내 트림: 컬럼 자기제어, 피드백 미미 → 전향 맵이 제어 지배
- ② START-UP 절차: 레시피 + 제품컷인 트리거(reb-A 84.5℃, ΔT 2℃, 조건기반)

문서: 설계·진행 플랜 + 남은 작업(형제확장·shutdown·assist·live포팅) 작업지시서.

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

2026-06-05 17:33:17 +09:00

52 KiB

Raw Blame History

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

상태: 설계(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 이미 굳은 핵심 결정 (재론하지 말 것 — 사용자와 합의됨)

접근법 = 정상상태 맵: OP_ss = f(정착 PV, 부하변수). 원시 behavior cloning(OP=f(PV,SP)) 아님. (§4)
SP를 정답으로 안 쓴다: 현장 SP 신뢰도 ~80%(MANUAL이라 방치 가능). 정착 PV = de facto target으로 사용. (§4)
안 떠는 이유 = 전향맵(피드백 없음) + 데드밴드 + dwell + rate-limit. stiction은 어떤 제어로도 못 고치며 "덜 움직이기"만이 답. (§5)
검증 = shadow 모드(실플랜트, write 안 함) > 시뮬레이터. 시뮬은 선택. (§6)
로드맵 = 학습 → shadow → operator-assist → guarded closed-loop, 이상 시 fallback은 PID가 아니라 오퍼레이터에게 반환. (§7)
RL/imitation은 실증 부족(sim2real 미해결)으로 1차 투입 부적합. 실증된 건 MPC(2단 구조)·MFAC·퍼지/전문가 supervisory. 우리 "정상상태 맵+gentle"이 마침 MPC 2단 구조(LP 정상상태 타깃 + 동적 move-suppress)와 동형 → de-risk. (§11·§12)
착수 1순위 = 기둥 A(루프 헬스 모니터링, APROMON류). dump만 있으면 즉시 가능하고 파일럿 루프를 데이터로 객관 선정해준다. (§13.1)
개발은 6차 플랜트 기준으로 먼저, 이후 차수 확장. 이유: 6차는 HC900 통신이 살아있어(현재 live 값은 가공이라도) 실 제어경로(shadow→assist→closed) 테스트 가능. 6·8·9·10차는 측류 반도체용 솔벤트로 동일 유형 → 6차용을 만들면 8·9·10에 그대로 확장. 1·2차는 측류 아닌 2컬럼 경질/중질 제거 일반 증류라 별도. (§15.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 + 사용자 도메인)에 권위 정의.
★학습 대상 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 반입 후 즉시)

dump을 별도 스키마(예: field_history)로 restore — 라이브 hc900 안 건드림. 용량 ≈ 수억 행(2000태그×30초×3개월), Timescale 압축 권장.
루프별 SP 신뢰도 실측 (|SP−정착PV| 분포)
정상상태 세그먼트 추출 (dPV/dt≈0, dOP/dt≈0)
OP_ss = f(정착PV, 부하) 맵 학습 + 잔차/피처 분석
stiction 1차 진단 (느린 루프 한정)
파일럿 루프 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 갭/리스크

모델 ID: 폐루프·외란상관·30초 → bump test는 보조. MANUAL OP step ≈ 개루프 데이터라 기존 데이터만으로 식별 우선 시도 (→ §13.0 참조).
계산: .NET QP 솔버(소형·1초면 충분), 무제약 DMC+클램프로 간이화 가능.
설명가능성: MPC는 룩업맵보다 덜 직관 → assist 모드 + 제약/타깃 화면표시로 보완.
유지보수: 모델 드리프트 → 주기적 re-ID.
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 우리 플랜과의 연결

기둥 A부터 (dump 직후 즉시) → 파일럿 루프 객관 선정 + hunting/stiction 진단
기둥 B = §12 MPC/정상상태 모델 엔진의 청사진
기둥 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)

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 우리가 할 일 ① — 파일에서 점검 (현장 점검 대체)

pg_restore -l field_full.dump | head -50    # PG버전·스키마·테이블·인덱스 목록

→ 이력 테이블명·컬럼(PV/SP/OP/MODE/외란)·timestamp 컬럼·TimescaleDB 여부를 파일에서 직접 파악.

14.3 우리가 할 일 ② — 별도 DB로 복원

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 최적화 (이력 테이블 확인 후)

-- 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 파일 도착 후 즉시 (요약)

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~~	죽은 플랜트 — 제외

개발 순서:

6차 먼저 — HC900 통신이 살아있음(현재 live 값은 가공이라도 실 제어경로 shadow→assist→closed 테스트 가능). 6차 = 측류 솔벤트 대표.
→ 8·9·10차 (동일 유형, 코드 재사용)
→ 1·2차 (2컬럼 일반증류, 제어구조 다름)
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)

field_hist에서 TICA-6111A + 6-1 피처 풀 pull.
★운전상태 분류 (필수 전처리)★ — 각 시점을 다음 모드로 라벨:
- 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 어드바이저(언제 로드 올릴지)로 확장 가능 — 현 스코프 밖, 메모.
AUTO 구간 제거(OP 연속변동 탐지), off-spec 제외, 정상상태 세그먼트(dPV≈0·dOP=0) 추출.
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, 진공, 스트림) → 밸브문제와 분리, 더 강건. 이후 유량→밸브% 역변환.
산출물: 맵 + 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 다음 액션

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

52 KiB Raw Blame History Unescape Escape