

 ▐▛███▜▌   Claude Code v2.1.143
▝▜█████▛▘  Opus 4.7 · Claude Pro
  ▘▘ ▝▝    ~/projects/ExperionCrawler


❯  측류추출-시간지연-적용방식.md 을 읽고, 이걸 로컬 LLM에서 자동운전 할 수 있는 방법을 제시해줘

● 파일을 먼저 찾아서 읽어보겠습니다.

  Searched for 1 pattern, read 1 file (ctrl+o to expand)

● 문서를 읽었습니다. 이제 이 시스템이 실제로 무엇을 할 수 있는지(특히 DCS 쓰기/제어 능력이 있는지) 파악해서 현실적인
  자동운전 방안을 제시하겠습니다. 기존 MCP 도구와 아키텍처를 빠르게 확인하겠습니다.

  Searched for 2 patterns (ctrl+o to expand)

● Bash(grep -nA2 "@mcp.tool" mcp-server/server.py | grep -E "^.*def " | sed -E 's/.*def ([a-zA-Z0-9_]+).*/\1/' | sort |
      tr '\n' ' '; echo; echo "=== query_pv_history s…)
  ⎿  active_alarms analyze_pid_impact ask_iiot_llm build_pid_graph_parallel classify_intent extract_pid_tags find_t
     ags generate_status_report get_tag_metadata infer_field_instruments list_drawings match_pid_tags parse_documen
     t parse_pid_drawing parse_pid_dxf parse_pid_pdf query_events query_pv_history query_with_nl rag_query run_sql
     … +18 lines (ctrl+o to expand)

● 문서와 코드베이스를 다 확인했습니다. 핵심 사실부터 정리하면:

  - 이 문서의 방법 A/B(데드타임 블록, 1차 지연 필터, 무빙애버리지)는 결정론적 제어 수학입니다 — 매 스캔(약 1초)마다 도는
   PID/필터 로직.
  - 현재 ExperionCrawler MCP 도구는 전부 읽기 전용입니다 (query_pv_history, get_tag_metadata, active_alarms,
  query_events, run_sql …). 밸브/SV 쓰기, OPC write, 셋포인트 명령 도구는 하나도 없습니다.

  이 두 사실이 "로컬 LLM 자동운전"의 설계를 결정합니다.

  ---
  0. 가장 중요한 원칙 — LLM을 제어 루프에 넣지 마세요

  문서가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야 하는 빠른 루프입니다. 여기에 LLM을 직접
  넣으면:

  - 비결정성 — 같은 입력에 다른 출력. 밸브 제어엔 치명적.
  - 지연(latency) — 토큰 생성 수 초. 탑 넘침(Flooding) 방지 같은 즉시 대응 불가.
  - 환각 — 잘못된 SV 한 번이 측류 순도 영역을 파괴.

  → 결론: 빠른 보상 로직은 코드(결정론 엔진)가, LLM은 그 위의 감독·조언·튜닝(분 단위/이벤트 단위) 만 맡습니다. 이게
  업계에서 LLM을 공정에 붙이는 유일하게 안전한 형태입니다.

  ---
  1. 2-Plane 아키텍처

  ┌─────────────────────────────────────────────────────────────┐
  │  Plane 2: 인지/감독 (LLM, 분~이벤트 단위, 느림)              │
  │  - Step Test 곡선 분석 → θ(데드타임)·τ 자동 추출            │
  │  - 파라미터(K, τ) 튜닝 제안                                  │
  │  - 헌팅/Flooding/순도드리프트 이상 감지 + 운전원 설명       │
  │  - "왜 제품밸브가 천천히 열려요?" 운전원 Q&A               │
  │           │ (파라미터/권고만 전달, 직접 밸브 X)             │
  │           ▼                                                  │
  │  ┌──────────────────── 안전 게이트 ─────────────────────┐  │
  │  │ Hard min/max clamp · rate limit · dead band · 감사로그│  │
  │  └──────────────────────────┬───────────────────────────┘  │
  ├─────────────────────────────┼───────────────────────────────┤
  │  Plane 1: 결정론 보상 엔진 (코드, 초 단위, 빠름)            │
  │  F_raw → [Lag τ=300s 필터] → F_clean                        │
  │            ├─ B_sv = K_B × deadtime(F_clean, 1~2분)         │
  │            ├─ D_sv = K_D × lag(F_clean, 5분)                │
  │            └─ P_sv = K_P × lag(F_clean, 15~20분)            │
  └─────────────────────────────────────────────────────────────┘
                                │
                읽기: query_pv_history (현 시스템 OK)
                쓰기: OPC write (Phase B에서 신규 — 현재 없음)

  Plane 1은 LLM이 아니라 순수 수학입니다. 1차 지연은 y[k] = y[k-1] + (Δt/τ)(x[k]-y[k-1]), 데드타임은 링버퍼 한 줄.
  파이썬/C# 어느 쪽이든 수십 줄.

  ---
  2. 현 시스템에 매핑 — 지금 코드로 "당장 가능한 것"

  현 시스템이 읽기 전용이므로, 밸브를 직접 안 여는 "조언형 자동운전(Advisory)" 이 즉시 구현 가능합니다:

  ┌───────────────────────┬───────────────────────────────────────────────┬──────────────────────┐
  │         기능          │              사용하는 기존 도구               │      신규 필요       │
  ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤
  │ 원료 유량 읽기·필터링 │ query_pv_history(["ficq-6113.pv"])            │ 필터 계산기          │
  ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤
  │ 권고 SV 계산·표시     │ (위 + 메타데이터)                             │ 보상 엔진(읽기 전용) │
  ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤
  │ Step Test 곡선 분석   │ query_pv_history(온도/수위/분석기)            │ LLM 분석 프롬프트    │
  ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤
  │ 이상 감지·설명        │ active_alarms, query_events, summarize_events │ 에이전트 루프        │
  ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤
  │ 운전원 Q&A            │ 기존 채팅 + ReAct 에이전트 모드(이미 있음)    │ 시스템 프롬프트      │
  └───────────────────────┴───────────────────────────────────────────────┴──────────────────────┘

  즉 Plane 2 전체와 Plane 1의 "계산·표시" 는 지금 코드 위에서 만들 수 있고, 운전원이 권고값을 보고 손으로 적용합니다.
  DCS 쓰기 없이 안전.

  ---
  3. LLM이 진짜 잘하는 4가지 역할

  1. Step Test 분석 (강력 추천) — 문서 §3의 그 작업. 유량 스텝 후 하부온도/상부온도/환류드럼수위/측류 Analyzer 곡선을
  query_pv_history로 뽑아 LLM에 주면 각 구간의 데드타임 θ와 τ를 읽어냅니다. (결정론적 곡선 피팅으로 교차검증) → 그 값이
  Plane 1 파라미터가 됩니다.
  2. 파라미터 튜닝 조언 — 처리량·원료 조성이 드리프트할 때 K·τ 재조정 제안.
  3. 이상 상황 서술 — "FT 헌팅이 5분째 ±5% 지속, 필터 τ를 300→420초 권장" 같은 자연어 진단.
  4. 운전원 코칭 — 신입 운전원에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명.

  ---
  4. 단계별 로드맵

  - Phase A — 조언형 (현 코드로 가능, 위험 0): 보상 엔진(읽기 전용) + 권고 SV 대시보드 + LLM Step Test 분석기. DCS 쓰기
  없음, 운전원 수동 적용.
  - Phase B — 감독형 폐루프: OPC 쓰기 채널 신규 추가(가장 큰 작업·안전심사 필요). Plane 1이 SV를 직접 쓰되 하드 클램프
  안에서만. LLM은 여전히 밸브 직접 X — 파라미터만 제안하고 변경은 운전원 승인.
  - Phase C — 자가 튜닝: LLM이 Step Test 시점을 제안 → 자동 피팅 → 시뮬레이터에서 A/B 검증 후 반영. (현 브랜치가 sim/...
   이므로 디지털 트윈으로 실플랜트 전에 검증 권장)

  ---
  5. 안전 가드 (Phase B 이상 필수)

  - Plane 1의 하드 min/max·rate limit·dead band는 LLM 출력과 무관하게 항상 강제.
  - LLM 권고는 기본 "표시", 자동 적용 경로는 별도 게이트 + 전 변경 감사 로그.
  - 통신 두절/이상 시 마지막 안전 SV로 폴백.

  ---
  핵심은 "LLM이 운전하는" 게 아니라 "결정론 엔진이 운전하고 LLM이 감독·튜닝한다" 입니다. 그래야 안전하면서도 LLM의
  가치(Step Test 해석, 적응 튜닝, 운전원 보조)를 다 살립니다.

  어디까지 진행할지에 따라 다음 작업이 달라져서 한 가지만 확인하겠습니다.

● User declined to answer questions
  ⎿  · 어느 범위부터 실제로 구현해 드릴까요? (Phase A 조언형부터 / Step Test 분석기만 먼저 / 결정론 보상 엔진 코드만 /
     설계 문서만 작성)

● 무엇을 명확히 하고 싶으신가요? 위 제안 중 궁금하거나 다르게 가져가고 싶은 부분을 말씀해 주세요.

  몇 가지 짚어볼 만한 지점을 미리 적어두면:

  - "자동운전"의 의미 — (a) 증류탑이 원료 변화에 스스로 보상하며 도는 것(=결정론 엔진이 운전, LLM 감독)인지, 아니면 (b)
  LLM이 운전원처럼 자율 판단·조치하는 것(=ReAct 에이전트)을 원하시는지. 제 제안은 (a)를 중심에 뒀습니다.
  - 실제 DCS 쓰기 가능 여부 — 현 시스템은 읽기 전용이라 폐루프(밸브 직접 조작)는 OPC 쓰기 채널 신설 + 안전 심사가
  전제입니다. 실제 Experion에 쓰기 접근이 가능한 환경인지.
  - 대상 범위 — 이 측류추출 증류탑 한 기에 한정인지, 일반화 가능한 프레임워크로 만들 것인지.
  - 검증 환경 — 현 브랜치가 sim/... 인데, 실플랜트 전에 시뮬레이터/디지털 트윈으로 먼저 검증할 생각이신지.

  어떤 점을 더 풀어서 다룰지, 또는 위 범위 질문 자체를 어떻게 바꾸면 좋을지 알려주세요.

✻ Worked for 2m 21s

❯ 이미 쓰기 기능은 추가되어 있어, UI OPC UA Write 탭을 살펴봐

● 쓰기 기능이 이미 있군요. 확인하겠습니다.

  Searched for 2 patterns, read 2 files (ctrl+o to expand)

● 쓰기 채널이 실제로 있군요. 컨트롤러와 통합 제어 시퀀스, 그리고 안전 가드 유무를 확인하겠습니다.

  Searched for 2 patterns (ctrl+o to expand)

● 핵심을 파악했습니다. 쓰기 채널이 실제로 다 갖춰져 있네요. 마지막으로 백그라운드 서비스 패턴과 안전 가드 유무만
  확인하겠습니다.

● Bash(cd /home/windpacer/projects/ExperionCrawler; echo "=== ControlOpRequest fields ==="; sed -n '1385,1410p'
      src/Web/Controllers/ExperionControllers.cs; echo "=== B…)
  ⎿  === ControlOpRequest fields ===
     public class ControlOpRequest
     {
     … +25 lines (ctrl+o to expand)

● 확인 완료했습니다. 제가 처음에 "읽기 전용"이라고 한 건 틀렸고, 정정합니다. 쓰기 채널이 온전히 갖춰져 있습니다.

  실제로 있는 쓰기 능력

  ┌────────────────────────────────┬─────────────────────────────────────────────────────┬──────────────────────────┐
  │              기능              │                        구현                         │        엔드포인트        │
  ├────────────────────────────────┼─────────────────────────────────────────────────────┼──────────────────────────┤
  │ SP/OP 직접 쓰기                │ ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId,   │ POST /api/experion/write │
  │                                │ value)                                              │                          │
  ├────────────────────────────────┼─────────────────────────────────────────────────────┼──────────────────────────┤
  │ MAN/AUTO 모드 변경             │ SetModeAsync(cfg, nodeId, "MAN"|"AUTO")             │ POST /api/experion/mode  │
  ├────────────────────────────────┼─────────────────────────────────────────────────────┼──────────────────────────┤
  │ 통합 제어 (MD→MAN → OP 쓰기 →  │ ControlOp(TagName, OpValue, RestoreAuto)            │ POST                     │
  │ AUTO 복귀)                     │                                                     │ /api/experion/control    │
  └────────────────────────────────┴─────────────────────────────────────────────────────┴──────────────────────────┘

  게다가 백그라운드 서비스 패턴(IHostedService/AddHostedService)도 이미 Realtime·History·OpcServer·Mcp에서 쓰고 있고,
  실시간 PV 구독(ExperionRealtimeService.AddMonitoredItemAsync)도 있습니다. 즉, 폐루프 자동운전이 신규 인프라 없이 기존
  코드 위에서 실제로 구현 가능합니다.

  ⚠️ 그런데 자동운전 전에 반드시 알아야 할 2가지

  코드를 읽다가 발견한 위험 지점입니다:

  1. 쓰기 경로에 안전 가드가 0건입니다. WriteTagAsync는 들어온 double 값을 그대로 씁니다 — min/max 클램프, rate limit,
  범위 검증, 변화율 제한이 전혀 없습니다. 사람이 UI에서 손으로 쓸 땐 운전원이 최종 안전망이지만, 엔진이 자동으로 쓰는
  순간 이 안전망이 사라집니다. 잘못된 SV 한 줄이 바로 밸브로 갑니다.
  2. 현재 LLM(MCP)에는 쓰기 도구가 없습니다. 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는" 상태가 유일한 안전
  경계입니다. 자동운전을 붙이면 이 경계를 넘게 됩니다.

  → 따라서 0순위 작업은 쓰기 가드 레이어입니다. 자동운전 엔진보다 먼저.

  업데이트된 아키텍처 (폐루프 가능 버전)

  ┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위) ──────────────────┐
  │  Step Test 곡선 분석 → θ·τ 추출 │ 파라미터(K,τ) 튜닝 제안  │
  │  헌팅/Flooding/순도 이상 감지·설명 │ 운전원 Q&A            │
  │         │ ※ 밸브 직접 쓰기 X. "엔진 파라미터 저장소"에만   │
  │         │   제안→운전원 승인 후 반영                       │
  ├─────────┼──────────────────────────────────────────────────┤
  │  🔒 안전 가드 레이어 (신규 0순위) ─ 모든 쓰기 강제 통과     │
  │   hard min/max · 변화율 제한 · dead band · 화이트리스트     │
  │   · 자동 폴백(통신두절→안전SV) · 전 쓰기 감사로그          │
  ├─────────┼──────────────────────────────────────────────────┤
  │  Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초단위) │
  │   Realtime 구독으로 F 읽기 → Lag(300s) 필터                 │
  │   → B_sv(데드타임 1~2분)/D_sv(5분)/P_sv(15~20분) 계산       │
  │   → WriteTagAsync / ControlOp 로 쓰기 (가드 통과 후)        │
  └─────────────────────────────────────────────────────────────┘

  기존 코드 매핑:
  - 읽기: ExperionRealtimeService(실시간 F·온도·수위) + query_pv_history(Step Test 곡선)
  - 엔진: 신규 AutoRunService : BackgroundService — 기존 IHostedService 패턴 그대로
  - 쓰기: 기존 IExperionOpcWriteClient — 단, 신규 가드 레이어를 반드시 경유
  - LLM 감독: 기존 MCP 도구 + ReAct 에이전트 모드(이미 있음)

  핵심 원칙은 그대로입니다 — 빠른 보상은 결정론 엔진(코드)이, LLM은 분 단위 감독·튜닝만. LLM은 밸브를 직접 건드리지
  않고, 엔진의 파라미터(K·τ·한계값)만 제안하며 그것도 운전원 승인 게이트를 거칩니다.

  쓰기가 된다는 사실이 그림을 바꿨으니, 무엇부터 만들지 다시 여쭙겠습니다.

● User declined to answer questions
  ⎿  · 추가 쓰기 능력을 확인했습니다. 무엇부터 구현할까요? (순서 조정 가능) (안전 가드 레이어 먼저 (권장) / 결정론 보상
     엔진 (폐루프) / 조언형(개루프)부터 / 시뮬레이터 먼저)
     · LLM이 자동운전에 개입하는 수준은 어디까지 허용할까요? (감독·조언만 (권장) / 파라미터 쓰기(승인 게이트) / MCP 쓰기
      도구 추가)

● 어떤 점을 더 명확히 하고 싶으신가요? 편하게 말씀해 주세요.

  참고로, 제가 질문으로 가두기보다 지금 파악한 내용을 바탕으로 짚어볼 지점들을 적어두면:

  - 자동운전의 형태 — 제 그림은 "결정론 엔진이 운전하고 LLM은 감독·튜닝"입니다. 혹시 의도하신 게 "LLM이 운전원처럼
  상황을 보고 스스로 SV를 쓰는 자율 에이전트"라면 방향이 달라집니다. 어느 쪽을 원하시는지.
  - 안전 가드 — 현 쓰기 경로에 클램프/변화율 제한이 전혀 없는 점은 자동운전 시 실제 위험입니다. 이걸 먼저 깔지, 아니면
  다른 우선순위가 있으신지.
  - 시작 범위 — 시뮬레이터 검증부터인지, 바로 실플랜트 엔진부터인지.
  - 태그/노드 매핑 — 측류추출 증류탑의 F(원료), B(하부), D(상부), P(측류), 스팀(S) 각각에 해당하는 실제 태그명/Node ID를
   알고 계신지 (예: ficq-6101.sp). 엔진을 만들려면 이 매핑이 필요합니다.

  혹은 위 질문 자체를 다르게 묻길 원하시면 그것도 알려주세요. 무엇이든 보충해 주실 내용을 먼저 듣고 진행하겠습니다.

✻ Churned for 1m 59s

❯ 태그/노드 매핑 은 이미 어느정도 구현해 두었어, vllm_qwen36b 에게 원료투입경로, 스팀 투입경로 이런걸 물어봐바

● 태그/노드 매핑이 있군요. vLLM에게 직접 물어보겠습니다. 먼저 관련 MCP 도구 스키마를 로드합니다.

● vLLM에게 원료 투입 경로와 스팀 투입 경로를 물어보겠습니다.

  Called iiot-rag (ctrl+o to expand)

● ask_iiot_llm는 컨텍스트 없이는 빈 응답이네요. 실제 매핑 데이터를 먼저 끌어와서 vLLM에 컨텍스트로 넘기겠습니다. 태그
  검색과 연결 추적을 동시에 돌립니다.

  Called iiot-rag 4 times (ctrl+o to expand)

● C-6111 컬럼(P6 영역, 6xxx 시리즈)이 PGMEA 측류추출탑이군요. 이제 연결 경로를 추적하고 컬럼 주변 계기를 찾겠습니다.

  Called iiot-rag 4 times (ctrl+o to expand)

● C-6111 측류추출 증류탑(진공탑)의 핵심 계기가 보입니다. 하부·환류·측류 제어 루프를 마저 확인하겠습니다.

  Called iiot-rag 4 times (ctrl+o to expand)

● 핵심 매핑이 거의 다 드러났습니다. D-6113이 환류 드럼이군요. 이제 수집한 실데이터를 컨텍스트로 vLLM에 넘겨 5개 경로를
  종합 정리시키겠습니다 (요청하신 "vLLM에게 물어보기").

  Called iiot-rag (ctrl+o to expand)

● ask_iiot_llm(vLLM 직접 질의) 도구는 두 번 다 (응답 없음)을 반환합니다 — vLLM 엔드포인트가 안 떠 있거나 그 MCP 경로가
  끊긴 것으로 보입니다 (한 번 확인해 보시는 게 좋겠습니다). 대신 데이터 기반 도구(find_tags, trace_connections — DB +
  LLM이 만든 P&ID 그래프)는 정상 동작했고, 거기서 C-6111 측류추출탑의 실제 매핑을 복원했습니다.

  C-6111 PGMEA 측류추출 증류탑 — 실측 태그 매핑 (P6 영역)

  trace_connections가 돌려준 원료 경로:
  P-6101 → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기

  ┌─────┬──────────┬───────────────────────┬──────────────┬───────────────┬──────────────────────────┬────────────┐
  │  #  │   경로   │   조작변수(MV)/제어   │     유량     │     온도      │        수위/압력         │  문서상 τ  │
  ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤
  │     │ 원료     │ FICQ-6101(SP/OP) →    │              │ TI-6111?      │                          │ 입력신호(L │
  │ F   │ 투입     │ FCV-6101              │ FT-6101      │ (예열 E-6103) │ —                        │ ag 300s    │
  │     │          │                       │              │               │                          │ 필터)      │
  ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤
  │ S   │ 리보일러 │ 스팀밸브(리보일러     │ FI-6115      │ TI-6111A(BOT) │ PI-6700(스팀압)          │ 가장 빠름  │
  │     │  스팀    │ 듀티)                 │              │ , TICA-6111A  │                          │            │
  ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤
  │ B   │ 하부     │ 하부 발출 밸브        │ (미확인)     │ TI-6111A(BOT) │ LI-6111(하부수위)        │ 1~2분      │
  │     │ 제거     │                       │              │               │                          │            │
  ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤
  │     │ 상부/환  │ FICQ-6113(PV29.9/SP36 │              │               │ LI-6113(D-6113           │            │
  │ D/R │ 류       │ .4)                   │ FI-6113      │ TI-6111D(TOP) │ 환류드럼), LICA-6113,    │ 5분        │
  │     │          │                       │              │               │ PI-6111(진공)            │            │
  ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤
  │ P   │ 측류     │ 측류 추출 밸브        │ FI-6120(PGME │ TI-6111B/C(MI │ LI-6121/6122/6123(제품탱 │ 15~20분    │
  │     │ 제품     │                       │ A)           │ D)            │ 크)                      │            │
  └─────┴──────────┴───────────────────────┴──────────────┴───────────────┴──────────────────────────┴────────────┘

  OPC Node 형식: ns=1;s=sinamserver:ficq-6101.sp / .op / .md(MAN=0/AUTO=1) — UI 기본값과 일치.

  자동운전 엔진에 그대로 꽂히는 그림

  - 입력(외란/피드): FICQ-6101 원료 유량 → Lag(300s) 필터 → F_clean
  - MV 1 (B, τ 1~2분): F_clean → 하부 발출 밸브, LI-6111 수위 제약(Flooding 방지)
  - MV 2 (D/R, τ 5분): F_clean → FICQ-6113.sp, LI-6113 드럼 수위 연동
  - MV 3 (P, τ 15~20분): F_clean → 측류 추출 밸브, TI-6111B/C 중간단 온도/순도 보호
  - S: 하부 온도(TI-6111A/TICA-6111A)에 직결 — 가장 빠른 응답

  흥미로운 현재 상태: FICQ-6113 PV 29.9 / SP 36.4로 추종 중이고 진공압 PICA-6111 30.4 — 탑이 실제 운전 중인 데이터로
  보입니다.

  아직 비어 있는 2칸 (엔진 만들기 전 확정 필요)

  1. B(하부 제거) 유량계·밸브 태그 — LI-6111 수위는 있는데 발출 유량/밸브 태그가 안 잡힙니다.
  2. P(측류) 추출 밸브 태그 — FI-6120(유량 측정)은 있으나 추출 제어밸브가 미확인.

  이 두 개는 find_tags로 6112/6114/6116번대를 더 훑거나, C-6111에서 trace_connections downstream를 돌리면 채울 수
  있습니다.

  지금 매핑을 (a) 더 파서 빈 칸 2개를 채울까요, 아니면 (b) 이 매핑을 자동운전 엔진 설계 문서/태그 설정으로 정리해
  드릴까요? 그리고 ask_iiot_llm이 빈 응답인 건 vLLM 서버 상태를 확인해 보시는 걸 권합니다.

✻ Cooked for 2m 38s

❯ 아니, 제품 추출 부분은 아직 매핑을 완료하지 않았어, 이건 내가 할거고, 일단, 측류추출-자동운전-플랜.md에 컨셉과
  선택사항을 모두 기록해줘

● 플랜 문서를 작성하겠습니다. 원본 문서와 같은 위치(루트)에 두고, 제품 추출(P) 매핑은 사용자 담당 TODO로 표시하겠습니다.

● Write(측류추출-자동운전-플랜.md)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Create file
 측류추출-자동운전-플랜.md
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
    1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜
    2
    3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서
    4 > **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록.
    5 >
    6 > 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태.
    7
    8 *작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
    9
   10 ---
   11
   12 ## 0. 핵심 원칙 (가장 중요)
   13
   14 **LLM을 빠른 제어 루프에 넣지 않는다.**
   15
   16 `측류추출-시간지연-적용방식.md`가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야
   17 하는 빠른 루프다. 여기에 LLM을 직접 넣으면:
   18
   19 | 문제 | 영향 |
   20 |------|------|
   21 | 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 |
   22 | 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 |
   23 | 환각 | 잘못된 SV 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 |
   24
   25 → **결론**: 빠른 보상은 **결정론 엔진(코드)** 이 담당하고, **LLM은 분 단위 감독·튜닝·조언만** 한다.
   26 이것이 LLM을 실공정에 붙이는 유일하게 안전한 형태다.
   27
   28 ---
   29
   30 ## 1. 2-Plane 아키텍처
   31
   32 ```
   33 ┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위, 느림) ───────────────┐
   34 │  · Step Test 곡선 분석 → θ(데드타임)·τ(시상수) 자동 추출      │
   35 │  · 파라미터(K, τ, 한계값) 튜닝 제안                            │
   36 │  · 헌팅 / Flooding / 순도 드리프트 이상 감지·자연어 설명       │
   37 │  · 운전원 Q&A ("왜 제품밸브가 천천히 열려요?")                 │
   38 │         │ ※ 밸브 직접 쓰기 금지. "엔진 파라미터 저장소"에만    │
   39 │         │   제안 → 운전원 승인 후 반영                         │
   40 ├─────────┼──────────────────────────────────────────────────────┤
   41 │  🔒 안전 가드 레이어 (신규, 0순위) ─ 모든 쓰기가 강제 통과     │
   42 │   hard min/max · 변화율(rate) 제한 · dead band · 태그 화이트   │
   43 │   리스트 · 통신두절→안전SV 폴백 · 전 쓰기 감사로그            │
   44 ├─────────┼──────────────────────────────────────────────────────┤
   45 │  Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초 단위)   │
   46 │   Realtime 구독으로 F(원료유량) 읽기                          │
   47 │   → Lag(τ=300s) 필터로 헌팅 제거 → F_clean                    │
   48 │   → B_sv(데드타임 1~2분) / D_sv(5분) / P_sv(15~20분) 계산      │
   49 │   → 가드 통과 후 WriteTagAsync / ControlOp 로 쓰기            │
   50 └────────────────────────────────────────────────────────────────┘
   51             읽기: ExperionRealtimeService · query_pv_history
   52             쓰기: IExperionOpcWriteClient (가드 레이어 경유 필수)
   53 ```
   54
   55 ---
   56
   57 ## 2. 보상 제어 수식 (Plane 1 — 결정론, LLM 아님)
   58
   59 원본 문서 §2·§4 기준.
   60
   61 - **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])`
   62 - **데드타임(Dead Time)**: 링버퍼로 N틱 지연
   63 - **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** 1개 (원본 §4.1 "1순위 대책")
   64
   65 | MV | 제어 대상 | τ / 데드타임 | 목적 |
   66 |----|----------|-------------|------|
   67 | B | 하부 제거량 | 1~2분 | 탑 넘침(Flooding) 즉시 방지 |
   68 | D/R | 상부 제거량/환류 | 5분 | 압력/조성 안정화 |
   69 | P | 측류 제품 추출 | 15~20분 | 초고순도 PGMEA 품질 보호 (가장 보수적) |
   70 | S | 리보일러 스팀 | 가장 빠름(수초~수분) | 하부 온도 직결 |
   71
   72 추가 안전요소(원본 §4.2/§4.3): 각 PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑).
   73
   74 ---
   75
   76 ## 3. 현 시스템에서 확인된 능력 (재사용 자산)
   77
   78 ### 3.1 쓰기 (이미 구현됨)
   79 | 기능 | 구현 | 엔드포인트 |
   80 |------|------|-----------|
   81 | SP/OP 직접 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, value)` | `POST /api/experion/write` |
   82 | MAN/AUTO 모드 | `SetModeAsync(cfg, nodeId, "MAN"\|"AUTO")` | `POST /api/experion/mode` |
   83 | 통합 제어 (MD→MAN → OP쓰기 → AUTO복귀) | `ControlOp(TagName, OpValue, RestoreAuto)` | `POST /api/experion/con
      trol` |
   84 | UI | "OPC UA Write" 탭 (#15) | `index.html #pane-write` |
   85
   86 ### 3.2 읽기
   87 - `ExperionRealtimeService` — 실시간 PV 구독 (`AddMonitoredItemAsync`), `IHostedService`
   88 - `query_pv_history` (MCP) / `ExperionHistoryController` — Step Test용 시계열
   89
   90 ### 3.3 백그라운드 서비스 패턴
   91 - `IHostedService`/`AddHostedService` 이미 Realtime·History·OpcServer·Mcp에서 사용 중
   92   → 신규 `AutoRunService : BackgroundService`가 기존 패턴에 그대로 들어감
   93
   94 ### 3.4 LLM 감독용 MCP 도구 (기존)
   95 - `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`,
   96   `summarize_events`, `generate_status_report`, ReAct 에이전트 모드(구현됨)
   97
   98 ---
   99
  100 ## 4. ⚠️ 안전 관련 발견 사항 (자동운전 전 반드시 처리)
  101
  102 1. **쓰기 경로에 안전 가드가 0건.** `WriteTagAsync`는 들어온 double을 그대로 쓴다 —
  103    min/max 클램프·rate limit·범위 검증·변화율 제한 전무. 사람이 UI에서 손으로 쓸 땐 운전원이
  104    최종 안전망이지만, **엔진이 자동으로 쓰는 순간 안전망이 사라진다.** → **0순위: 가드 레이어.**
  105 2. **현재 LLM(MCP)에는 쓰기 도구가 없다.** 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는"
  106    상태가 유일한 안전 경계. 자동운전을 붙이면 이 경계를 넘게 됨 → 신중한 권한 설계 필요.
  107 3. **`ask_iiot_llm`(vLLM 직접 질의) MCP 도구가 빈 응답.** 2회 시도 모두 `(응답 없음)`.
  108    vLLM 엔드포인트 상태/연결 점검 필요. (단 `find_tags`/`trace_connections`는 정상 동작.)
  109
  110 ---
  111
  112 ## 5. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections` 기반)
  113
  114 `trace_connections`가 돌려준 원료 경로:
  115 ```
  116 P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기
  117 ```
  118
  119 | # | 경로 | 조작변수(MV)/제어 | 유량 | 온도 | 수위/압력 | τ |
  120 |---|------|------------------|------|------|----------|---|
  121 | **F** | 원료 투입 | **FICQ-6101**(SP/OP)→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력신호(Lag 300s) |
  122 | **S** | 리보일러 스팀 | 스팀밸브(리보일러 듀티) | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) |
       가장 빠름 |
  123 | **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1
      ~2분 |
  124 | **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼),
      LICA-6113, PI-6111(진공), PICA-6111 | 5분 |
  125 | **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크)
      | 15~20분 |
  126
  127 - OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1)
  128 - 현재 운전 데이터 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종 중, 진공압 PICA-6111 30.4 → 탑 가동 중으로 추정
  129
  130 ### 5.1 미완료 매핑 (담당 구분)
  131 - **P(측류 제품 추출) 경로 매핑 — 사용자가 직접 진행 예정** (본 플랜에서는 보류)
  132 - B(하부 제거) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는
  133   C-6111 `trace_connections downstream`로 보강 가능 (착수 시 확정)
  134
  135 ---
  136
  137 ## 6. 선택사항 (의사결정 대기)
  138
  139 ### 6.1 시작 지점 — "무엇부터 구현하나"
  140 | 옵션 | 내용 | 비고 |
  141 |------|------|------|
  142 | **A. 안전 가드 레이어 먼저** | 쓰기 경로에 클램프·변화율·dead band·화이트리스트·감사로그 추가 | **권장**. 자
      동운전 전제조건이며 수동 쓰기도 즉시 안전해짐 |
  143 | B. 결정론 보상 엔진(폐루프) | `AutoRunService`: F구독→Lag/데드타임→B/D/P SV 계산→가드 경유 쓰기 | 실제 자동운
      전 핵심 |
  144 | C. 조언형(개루프)부터 | 엔진은 권고 SV만 계산·표시, 쓰기는 운전원이 클릭 승인 | 로직 안전검증 후 폐루프 전환
      |
  145 | D. 시뮬레이터 먼저 | FOPDT 증류탑 디지털 트윈으로 실플랜트 전 검증 | 현 브랜치 `sim/...` 와 자연스러움 |
  146
  147 ### 6.2 LLM 개입 수준 — "LLM 권한 어디까지"
  148 | 옵션 | 내용 | 비고 |
  149 |------|------|------|
  150 | **가. 감독·조언만** | Step Test 분석·이상 설명·파라미터 제안만. 밸브/쓰기 절대 안 함 | **권장**. 가장 안전 |
  151 | 나. 파라미터 쓰기(승인 게이트) | LLM이 K·τ 등 엔진 파라미터 변경 제안 → 운전원 승인 후 반영. 밸브 직접 제어는
       여전히 엔진만 | 적응 튜닝 가능 |
  152 | 다. MCP 쓰기 도구 추가 | LLM이 MCP로 직접 SV/모드 쓰기(가드 경유) | 유연하나 위험 큼 — 신중 적용 |
  153
  154 > 현재 권장 조합: **6.1-A (가드 먼저) + 6.2-가 (LLM 감독만)** 로 시작 → 검증 후 단계적 확장.
  155
  156 ---
  157
  158 ## 7. 단계별 로드맵
  159
  160 - **Phase 0 — 안전 가드 레이어**: 쓰기 경로 클램프/rate/dead band/화이트리스트/폴백/감사로그. (전제조건)
  161 - **Phase A — 조언형(개루프)**: 보상 엔진이 권고 SV 계산·대시보드 표시 + LLM Step Test 분석기.
  162   DCS 쓰기는 운전원 수동 승인. 위험 최소.
  163 - **Phase B — 감독형 폐루프**: `AutoRunService`가 가드 안에서 SV 자동 쓰기. LLM은 파라미터만 제안(승인 게이트).
  164 - **Phase C — 자가 튜닝**: LLM이 Step Test 시점 제안 → 자동 피팅 → 시뮬레이터 A/B 검증 후 반영.
  165
  166 ---
  167
  168 ## 8. LLM이 잘하는 4가지 역할 (Plane 2 상세)
  169
  170 1. **Step Test 분석 (강력 추천)** — 원본 §3. 유량 스텝 후 하부/상부/환류드럼/측류 온도·Analyzer 곡선을
  171    `query_pv_history`로 뽑아 LLM에 주면 구간별 데드타임 θ·시상수 τ를 읽어냄 (결정론 곡선피팅으로 교차검증)
  172    → 그 값이 Plane 1 파라미터가 됨.
  173 2. **파라미터 튜닝 조언** — 처리량·원료 조성 드리프트 시 K·τ 재조정 제안.
  174 3. **이상 상황 서술** — "FT 헌팅 5분째 ±5% 지속, 필터 τ 300→420초 권장" 식 자연어 진단.
  175 4. **운전원 코칭** — 신입에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명.
✻ Cooked for 2m 38s

❯ 아니, 제품 추출 부분은 아직 매핑을 완료하지 않았어, 이건 내가 할거고, 일단, 측류추출-자동운전-플랜.md에 컨셉과
  선택사항을 모두 기록해줘

● 플랜 문서를 작성하겠습니다. 원본 문서와 같은 위치(루트)에 두고, 제품 추출(P) 매핑은 사용자 담당 TODO로 표시하겠습니다.

● Write(측류추출-자동운전-플랜.md)
  ⎿  Wrote 196 lines to 측류추출-자동운전-플랜.md
       1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜
       2
       3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서
       4 > **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록.
       5 >
       6 > 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태.
       7
       8 *작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
       9
      10 ---
     … +200 lines (ctrl+o to expand)

● 측류추출-자동운전-플랜.md를 루트(측류추출-시간지연-적용방식.md 옆)에 작성했습니다.

  기록된 내용:

  - §0 핵심 원칙 — LLM을 빠른 제어 루프에 넣지 않음
  - §1 2-Plane 아키텍처 — 결정론 엔진(초 단위) + LLM 감독(분 단위) + 안전 가드 레이어 다이어그램

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  Settings  Status   Config   Usage   Stats

  Session


  Total cost:            $2.01
  Total duration (API):  7m 3s
  Total duration (wall): 21m 49s
  Total code changes:    197 lines added, 0 lines removed
  Usage by model:
  Usage by model:
  Usage by model:
       1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜
       2
       3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서
       4 > **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록.
       5 >
       6 > 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태.
       7
       8 *작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
       9
      10 ---
     … +200 lines (ctrl+o to expand)

❯ /usage
  ⎿  Settings dialog dismissed

● 측류추출-자동운전-플랜.md를 루트(측류추출-시간지연-적용방식.md 옆)에 작성했습니다.

  기록된 내용:
  - §0 핵심 원칙 — LLM을 빠른 제어 루프에 넣지 않음
  - §1 2-Plane 아키텍처 — 결정론 엔진(초 단위) + LLM 감독(분 단위) + 안전 가드 레이어 다이어그램
  - §2 보상 수식 — Lag 필터/데드타임, MV별 τ(B 1~2분 / D 5분 / P 15~20분 / S 가장 빠름)
  - §3 재사용 자산 — 기존 쓰기 클라이언트·엔드포인트·BackgroundService 패턴·MCP 도구
  - §4 안전 발견 — 쓰기 가드 0건, LLM 쓰기 도구 없음, ask_iiot_llm 빈 응답
  - §5 실측 태그 매핑 — F/S/B/D·R 매핑 표 + P는 "🔲 사용자 매핑 예정"으로 보류 표시
  - §6 선택사항 — 6.1 시작 지점(A~D), 6.2 LLM 권한(가~다), 권장 조합 명시
  - §7 로드맵 — Phase 0/A/B/C
  - §8 LLM 4대 역할, §9 미해결 항목(P 매핑 = 사용자 담당으로 명기)

  말씀대로 제품 추출(P) 경로 매핑은 사용자 진행 예정으로 §5.1과 §9에 담당 구분해 두었습니다. P 매핑을 마치시면
  알려주시면 표의 해당 칸을 채우겠습니다.

✻ Sautéed for 1m 11s

❯ PID loop의 튜닝을 LLM이 보조할 수 있는 방법은?, 이걸 학습으로 플랜트 상황에 맞게 튜닝 가능할까?

● 좋은 질문입니다. 두 부분으로 나눠서 — (1) LLM이 PID 튜닝을 어떻게 보조하나, (2) 그걸 학습으로 플랜트에 맞게 적응시키는
   게 현실적인가.

  1. LLM의 PID 튜닝 보조 — 역할 분담이 핵심

  자동운전 플랜의 §0 원칙과 동일합니다: LLM은 숫자를 만들지 않습니다. 정확한 산수와 결정성이 필요한 부분(모델 식별, 튜닝
   공식 계산)은 결정론 수학이 하고, LLM은 그 위에서 판단·진단·번역·오케스트레이션을 합니다.

  ┌──────────────────────────────────────────────────┬─────────────────────────┬────────────────────────────────────┐
  │                       작업                       │          담당           │                이유                │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ Bump/Step Test 응답에서 FOPDT 모델(K, τ, θ) 식별 │ 수학(최소제곱 곡선피팅) │ LLM 산수는 부정확·비결정           │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ 튜닝 공식 적용 → Kc, τI, τD 계산                 │ 수학(SIMC/Lambda 등)    │ 동일                               │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ 어떤 튜닝 규칙·목표(λ)를 쓸지 결정               │ LLM                     │ 루프 용도·강건성 트레이드오프 판단 │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ 루프 분류 (유량/수위/온도/압력) → 튜닝 철학 선택 │ LLM                     │ 도메인 지식 매칭                   │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ 트렌드에서 병증 진단 (발진/둔감/stiction/windup) │ LLM                     │ 패턴 해석·서술                     │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ 운전원 언어 ↔ 파라미터 번역                      │ LLM                     │ "오버슈트가 심해" → "Kc↓ 또는 τI↑" │
  ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤
  │ 재튜닝 시점 판단·근거 로깅                       │ LLM                     │ 이벤트 단위 의사결정               │
  └──────────────────────────────────────────────────┴─────────────────────────┴────────────────────────────────────┘

  표준 워크플로우 (LLM이 지휘)

  ① LLM: 이 루프는 무엇? (예: TICA-6111A = 온도, 품질직결, 느림)
     → 튜닝 철학 결정 (Lambda/SIMC, λ 보수적으로)
  ② 수학: Bump Test 수행 → 응답곡선 → FOPDT (K,τ,θ) 최소제곱 피팅
  ③ LLM: 피팅 품질 검증 ("R²낮음, 노이즈/외란 의심 → 재시험 권고")
  ④ 수학: SIMC 공식으로 Kc,τI,τD 산출
  ⑤ LLM: 결과 설명 + 안전범위 점검 → 운전원 승인 게이트
  ⑥ 가드 레이어 경유 적용 (플랜 §1 그대로)

  루프별로 튜닝 철학이 다른데, 이게 LLM의 진짜 가치

  ┌────────────────────────┬───────────────────────────────────┬──────────────────────────────┐
  │    루프 (이 플랜트)    │               철학                │       LLM이 자동 선택        │
  ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤
  │ FICQ-6101 유량         │ 빠름, Lambda 작게, P+I만 (D 금지) │ 노이즈 많음 → 적극적 D 배제  │
  ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤
  │ LI-6111 / LI-6113 수위 │ Averaging/Surge (느슨하게)        │ 원본 문서 §4.3과 직결 — 완충 │
  ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤
  │ TICA-6111A 온도        │ 지배동특성, 보수적 λ              │ 품질직결 → 강건성 우선       │
  ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤
  │ PICA-6111 진공         │ 비교적 빠름                       │ —                            │
  └────────────────────────┴───────────────────────────────────┴──────────────────────────────┘

  그리고 "튜닝 대상"이 둘이라는 점

  1. 기저 PID 루프 (Kc, τI, τD) — 위 고전 튜닝
  2. 피드포워드 보상 파라미터 (Lag τ, 데드타임, 게인 K_D/K_B/K_P) — 자동운전 플랜의 Step Test 분석이 바로 이걸 식별

  LLM은 둘 다 보조하며, Step Test 곡선 해석은 두 작업의 공통 입력입니다.

  ---
  2. "학습으로 플랜트에 맞게" — 가능하다, 단 메커니즘 선택이 전부

  가능합니다. 하지만 "강화학습으로 증류탑을 학습"은 실플랜트에선 위험·비현실적입니다(샘플 비효율 + 탐색 = 나쁜 SV 투입).
   안전한 것부터 야심찬 것 순으로 사다리를 제시합니다:

  ┌──────┬──────────────────────────────────────────────────────────┬──────────────┬────────────────────────────────┐
  │ 레벨 │                           방법                           │ "학습" 성격  │             현실성             │
  ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤
  │ L1   │ 주기적 재식별 (Bump Test 재실행 → FOPDT 재피팅 → 재튜닝) │ ML 아님,     │ ★★★ 가장 실용·안전             │
  │      │                                                          │ 적응         │                                │
  ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤
  │ L2   │ 게인 스케줄링 (처리량·등급별 다점 튜닝 후 보간)          │ 룩업 학습    │ ★★★ 비선형 대응 정석           │
  ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤
  │ L3   │ 고전 적응제어 (RLS 온라인 추정 → Self-Tuning)            │ 온라인 추정  │ ★★ 검증됨(Åström), 진동주의    │
  ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤
  │ L4   │ 베이지안 최적화 (성능비용 IAE/오버슈트를 소수 실험으로   │ 데이터기반   │ ★★ 트윈 우선, 샘플효율 최고    │
  │      │ 최소화)                                                  │ ML           │                                │
  ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤
  │ L5   │ 강화학습(RL)                                             │ 정책학습     │ ★ 시뮬레이터 전용, 실플랜트    │
  │      │                                                          │              │ 금지                           │
  └──────┴──────────────────────────────────────────────────────────┴──────────────┴────────────────────────────────┘

  추가로 탐색 없이 안전하게 학습하는 두 가지가 이 시스템에 특히 잘 맞습니다:

  - 섀도/추천 모드 학습: 엔진이 "이렇게 하겠다"를 계산만 하고, 실제 운전원 조치 + 결과를 로깅 → 둘의 격차를 학습.
  "운전원은 항상 P밸브를 우리 모델보다 느리게 연다" → 모델 보정. 탐색 위험 0, 지도학습.
  - CLPM (폐루프 성능 모니터링): Harris 지수(최소분산 대비)·발진 감지·밸브 stiction 진단을 일상 운전 데이터만으로 수행 →
   루프 건강도 점수화 → 튜닝 열화 시 자동 플래그. 이게 재튜닝의 트리거가 되고, LLM이 우선순위를 서술.

  추천 적응 루프 (이 플랜트 기준)

  일상 데이터 → CLPM(Harris·stiction·발진) → LLM이 "열화 루프" 식별·서술
     → 게인 스케줄(L2) 해당 점 벗어남? → Bump Test 재식별(L1)
     → 트윈에서 베이지안 최적화(L4)로 미세조정 → 운전원 승인 → 가드 경유 반영
     → 결과 로깅 → 섀도 학습으로 모델 보정 (순환)

  반드시 지켜야 할 제약 (정직하게)

  - 디지털 트윈 우선 — 현 브랜치 sim/... 활용. L4/L5는 실플랜트 전 트윈 검증 필수.
  - 식별성(Identifiability) — 충분한 가진(excitation) 없으면 모델 못 만듦. 고순도 탑은 비선형·느림 → 작은 선형모델은
  국소적으로만 유효 → 그래서 L2 게인 스케줄링이 핵심.
  - 안전 제약 — 모든 적응은 플랜 §0 가드 레이어 하드 한계 안에서만. 탐색형(L4/L5)엔 trust-region 필수.
  - LLM은 비용함수·실험설계·수렴판정·가드를 담당하고, 최적화 수치는 알고리즘이 낸다 — 여기서도 §0 원칙 유지.
  - 이 C-6111은 품질직결·느림·비선형 = 가장 보수적으로 다뤄야 하는 케이스. L1+L2+섀도부터, L4는 트윈에서만.

  ---
  요약: LLM은 PID 튜닝의 지휘자·진단가·번역가로 강력하고(수치는 결정론 수학이 산출), 플랜트 적응 학습도 가능하되 RL이
  아니라 재식별+게인스케줄링+베이지안최적화+섀도학습+CLPM 조합이 안전하고 현실적인 답입니다.

  이 내용을 자동운전 플랜 문서에 "§10. PID 튜닝 보조 & 적응 학습" 섹션으로 추가해 둘까요?

✻ Brewed for 1m 10s

❯ 좀더 얘기를 하고 문서를 작성하자,

  내가 알고있는것은 밸브의 사이즈, 배관의종류, 컨트롤밸브의 CV 값과 CV 커브, 플로우미터의 유량범위 등의 물리적인
  데이터를 가지고 있다면, 결정론적인 부분을 이것으로 프로그램화 하고, LLM은 실제로 무엇을 할 수있다는거야?

● 아주 정확한 지점을 찌르셨습니다. 솔직하게 답하면 — 그 물리 데이터를 가지고 있다면, 제어 수학에서 LLM이 할 일은 오히려
  크게 줄어듭니다. 그게 맞고, 그게 좋은 겁니다. 하나씩 정리하죠.

  1. 물리 데이터로 결정론화되는 부분 (LLM 불필요)

  말씀하신 데이터는 사실 "데이터 피팅으로 추정"해야 했던 것들을 계산으로 바꿔버립니다:

  ┌───────────────────────────────────┬─────────────────────────────────────────────┬────────────────────┐
  │            물리 데이터            │            계산되는 결정론 모델             │ 이전엔 뭐로 구했나 │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 컨트롤밸브 Cv + Cv 커브(설치특성) │ OP(%) → 유량 관계, 밸브 게인 dQ/dOP         │ Step Test 식별     │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 배관 종류·구경·길이               │ ΔP·마찰, 이송 데드타임 θ = 관내체적/유량    │ Step Test로 θ 측정 │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 드럼/트레이 홀드업 체적           │ 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) │ Step Test로 τ 측정 │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 플로우미터 레인지                 │ 스케일링·분해능·노이즈 플로어               │ —                  │
  └───────────────────────────────────┴─────────────────────────────────────────────┴────────────────────┘

  → 즉 자동운전 플랜의 B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업 = 체적/유량 으로 직접 계산됩니다. 밸브 게인도 Cv
  커브 미분으로 나옵니다. 여기에 LLM을 넣을 이유가 없습니다. 모델기반 튜닝(SIMC/Lambda)도 이 물리모델로 바로 Kc·τI가
  떨어집니다. 이 부분은 그냥 프로그램하세요. 제 처음 답에서 "Step Test로 식별"이라던 것의 상당 부분이 당신의 경우
  불필요해집니다.

  2. 그런데 물리 데이터가 못 주는 3가지

  여기가 핵심입니다. Cv·배관·유량범위는 하이드롤릭(얼마나 흐르나) 을 줍니다. 그런데 증류탑의 진짜 어려움은 거기가
  아닙니다.

  (가) 분리/조성 동특성 — 당신 데이터에 없음.
  원본 문서의 "P(측류)는 15~20분으로 가장 느리다" 는 배관 이송이 아니라 트레이별 물질·열 홀드업 + 기액평형(VLE)으로 새
  조성이 자리잡는 시간입니다. 홀드업 체적은 당신이 알지만, 상대휘발도·트레이 효율·VLE는 Cv 커브에 없습니다. 이 P 지연은
  물리 데이터만으론 안 나오고, 단별(stage) 분리 모델이 필요합니다. → B·D는 물리로 계산되지만, P는 안 됩니다. 이게
  경계선입니다.

  (나) 모델-플랜트 불일치(드리프트). Cv 커브는 깨끗한 신품 설계값입니다. 실제론 밸브 stiction·시트 마모, E-6103 파울링,
  트레이 효율 저하로 시간에 따라 어긋납니다. 물리모델은 "어제의 진실"이고 플랜트는 오늘 다릅니다.

  (다) 목적·맥락·예외. 무엇이 "잘 도는" 건지(회수율 최대 vs 에너지 최소 vs 순도 사수), 등급 변경, 기동/정지, 계기 고장,
  상류 외란 — 정적 물리 데이터엔 전혀 없습니다.

  3. 그래서 LLM이 실제로 하는 일 (과장 없이)

  물리모델이 좋을수록 LLM은 제어 경로에서 빠지고 가장자리로 이동합니다. 솔직한 목록:

  ┌────────────────────┬───────────────────────────────────────────────────────────────────┬───────────────────────┐
  │      LLM 역할      │                            구체적으로                             │      정직한 가치      │
  ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤
  │ ① 커미셔닝 보조    │ 밸브 데이터시트·Cv 커브·배관 스펙을 파싱해 결정론 엔진의          │ ★★ 즉시 유용. "물리는 │
  │                    │ config/코드로 조립, Cv 값 정합성 점검                             │  결정론" 철학 그대로  │
  ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤
  │ ② 데이터           │ 물리예측 유량 vs 실측 잔차 계산은 수학, "이 OP·ΔP에서 8% 미달 →   │                       │
  │ 정합(드리프트      │ 밸브 파울링/마모 의심" 해석·재교정 트리거는 LLM                   │ ★★ (나) 해결          │
  │ 진단)              │                                                                   │                       │
  ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤
  │ ③ 소프트센서 보조  │ 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간     │ ★ (가) 보완(완전 해결 │
  │                    │                                                                   │  아님)                │
  ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤
  │ ④ 감독형 예외 처리 │ 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장)에서  │ ★★★ 물리 침묵 영역    │
  │                    │ 판단·완화                                                         │                       │
  ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤
  │ ⑤ 운전원           │ 의도/경제목표 → SV·제약으로 번역, "왜 이렇게 도는지" 설명         │ ★★★ 물리 침묵 영역    │
  │ 인터페이스         │                                                                   │                       │
  ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤
  │ ⑥ 교차 데이터 융합 │ 알람+이벤트+랩분석+정비이력+물리잔차를 엮어 진단                  │ ★★★ 기존 MCP 도구     │
  │                    │                                                                   │ 활용                  │
  └────────────────────┴───────────────────────────────────────────────────────────────────┴───────────────────────┘

  4. 핵심 원리 (한 줄)

  ▎ LLM의 가치는 물리모델 품질에 반비례합니다. 당신처럼 물리를 잘 잡을수록 LLM은 제어 산수에서 사라지고 — ③ 못 측정하는
  ▎ 조성, ④ 프로그램 안 된 예외, ⑤ 사람 인터페이스, ⑥ 교차 진단, ①커미셔닝으로 옮겨갑니다. 이게 정상이고 안전한
  ▎ 모습입니다.

  ---
  문서로 넘어가기 전에 같이 정리하고 싶은 게 몇 가지 있습니다:
  ▎ 모습입니다.

  ---
  문서로 넘어가기 전에 같이 정리하고 싶은 게 몇 가지 있습니다:

  1. 분리/조성(가) 모델을 어디까지 갈 건가? — P 지연을 (a) 그냥 보수적 고정 τ(15~20분)로 두고 안 건드릴지, (b) 간이
  트레이/홀드업 모델을 세울지, (c) 운전데이터 기반 경험모델로 둘지. 이게 LLM 역할 ③의 깊이를 결정합니다.
  2. 물리 데이터의 형태 — Cv 커브가 표/수식/데이터시트 PDF 중 무엇인가요? 역할 ①(LLM이 config로 조립)의 실현성이 여기
  달려 있습니다.
  3. LLM을 "제어 보조"로 보시는지 "운전 보조(예외·인터페이스)"로 보시는지 — 위 ②④⑤⑥ 중 어디에 무게를 두실지에 따라 문서
  구조가 달라집니다.

  이 세 가지에 대한 생각을 들려주시면, 그걸 반영해서 플랜 문서에 섹션을 작성하겠습니다.

✻ Baked for 1m 17s

❯ 내가 생각하는 방향은 이거야
  1. 결정론이든, llm이든 목표 설정값을 연산---> Experion 서버에 전달
  2. Experion 서버에서 프로그램을 해서, 전달된 값을 화면상(Operator Station 모니터링 HMI)에 PID Loop 표시에 제안한
  SP값을 표시
  3. 운전원이 여기에 익숙해지고, 신뢰가 생긴다면, mode 변경, -> Set Point 변경 주도권 가져옴
  4. PID LOOP의 Hunting이 심하다고 판단되는 기준을 넘으면, 매뉴얼 모드로 변경, 제어출력(OP)를 가지고 변경하면서 안정권
  유지

  꼭 DCS 컨트롤러의 PID 제어기의 파라미터를 교정하는것이 아니어도 매뉴얼 모드에서, op 변경만 가지고도 가능할까? 하는
  의문에서 시작된 것이 이 세션의 시작 목적이기도 함---> 당연히 안전장치(rate제한, 절대값 제한, 현재 유량 범위 감안 밸브
   변동폭 제한, 기본 컨트롤러에 설정된 ESD, IL 동작 이 보증된 상태에서 임

● 이제 핵심이 명확해졌습니다. 그리고 시작 질문 — "PID 파라미터를 안 건드리고, MANUAL에서 OP만으로 안정화 가능한가?" — 에
   정직하게 답하면: 경우에 따라 Yes, 그리고 그게 오히려 브라운필드에서 더 현실적입니다. 다만 결정적인 단서가 있습니다.

  1. 시작 질문에 대한 직답

  핵심은 헌팅의 원인입니다. MANUAL+OP로 잡히는 헌팅과 안 잡히는 헌팅이 갈립니다.

  ┌──────────────────────┬────────────────────┬─────────────────────────────────────────────────────────────────────┐
  │      헌팅 원인       │    MANUAL+OP로     │                                설명                                 │
  │                      │      잡히나?       │                                                                     │
  ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
  │ 튜닝 과민(Kc 과대/I  │ ✅ 즉시 잡힘       │ MAN 전환 순간 컨트롤러 피드백이 빠지므로 제어기발 발진이 사라짐.    │
  │ 과속)                │                    │ OP를 천천히·rate제한으로 움직이면 됨                                │
  ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
  │ 상류 외란(원료 헌팅  │ ✅ 잘 잡힘         │ 원본 문서의 "필터 + 부드럽게" 가 곧 MAN 느낌의 피드포워드. 가장     │
  │ 등)                  │                    │ 강력한 케이스                                                       │
  ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
  │ 루프 간 간섭         │ ⚠️ 부분적          │ 이동/시차 조절로 완화                                               │
  ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
  │ 밸브 stiction(고착)  │ ❌ 안 잡힘, 오히려 │ 물리적 결함. MAN에서 작게 보정하면 또 고착·점프. 액추에이터 마모만  │
  │                      │  악화              │ 늘어남 → 정비 대상                                                  │
  └──────────────────────┴────────────────────┴─────────────────────────────────────────────────────────────────────┘

  → 결론: 튜닝·외란발 헌팅은 PID 파라미터를 안 건드리고 MAN+OP로 충분히 안정화됩니다. 단, 한 가지 본질적 사실:

  ▎ MAN으로 가는 순간 DCS PID가 하던 자동 피드백 규제가 사라집니다. OP를 누가 계속 움직여줘야 합니다. 즉 당신은 "튜닝을
  ▎ 안 한" 게 아니라 컨트롤러를 DCS 밖(당신 소프트웨어)으로 옮긴 것입니다. 외부 프로그램이 느린 PI/피드포워드로 OP를
  ▎ 써주는, 사실상 외부 컨트롤러가 됩니다.

  이건 정당한 방식이고, 실제 APC가 하는 일과 같습니다. 그리고 브라운필드에서 매력적인 이유: DCS 로직 변경·변경관리(MoC)
  없이 OPC 쓰기만으로 됩니다(당신은 이미 OPC Write가 있음).

  2. 그래서 두 가지 모드를 구분하세요 — 당신의 1~4단계가 정확히 여기 매핑됩니다

  ┌─────────────────────────┬───────────────────────┬──────────────────────────────────────────┬───────────┐
  │          방식           │ 누가 빠른 규제를 하나 │                   언제                   │ 당신 계획 │
  ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤
  │ (A) SP 쓰기 + AUTO 유지 │ DCS PID (그대로 둠)   │ 평상시 감독·최적화. 기저 PID가 쓸만할 때 │ 1~3단계   │
  ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤
  │ (B) OP 쓰기 + MANUAL    │ 당신 소프트웨어       │ 기저 PID가 헌팅인데 재튜닝 못/안 할 때   │ 4단계     │
  └─────────────────────────┴───────────────────────┴──────────────────────────────────────────┴───────────┘

  (A)는 SP를 AUTO 루프에 쓰는 거라 본질적으로 bumpless하고 가장 안전합니다. (B)는 더 강력하지만 규제·bumpless·폴백을
  전부 당신이 책임집니다.

  → 당신 직관이 정확합니다: 평상시엔 (A)로 신뢰를 쌓고, 헌팅 루프에 한해 (B)로 개입. PID 파라미터 교정은 필수가
  아닙니다.

  3. 4단계의 전제 — "헌팅 원인 진단"이 게이트 (여기가 LLM의 진짜 자리)

  4단계가 성공하려면 MAN 전환 전에 원인을 판별해야 합니다. stiction인데 OP 핸드홀딩하면 헛수고+마모입니다.

  - 헌팅 검출/심각도 판정 = 결정론(진폭·주기·지속성, 오실레이션 인덱스). MAN 전환 트립도 결정론이어야 함(LLM 지연 불가).
  - 원인 분류(튜닝 vs stiction vs 외란) = LLM + 데이터 융합의 고가치 역할. OP-PV 위상, 한계주기 파형, 상류 신호,
  정비이력을 엮어 "이건 stiction → 4단계 말고 정비 플래그" vs "외란 → 4단계 OP 핸드홀딩 유효" 판단.

  즉 LLM은 OP를 직접 흔드는 게 아니라, "이 루프에 4단계를 적용해도 되는가"를 판정합니다. 이게 당신 비전에 LLM이 깔끔하게
   들어가는 지점입니다.

  4. 안전 봉투 — 당신이 든 것 + 빠진 것

  당신이 명시한 것(✅ 다 맞음): rate 제한 · 절대값 제한 · 현재 유량 대비 밸브 변동폭 제한 · ESD/IL 독립 보증. 특히
  ESD/SIS가 BPCS 루프의 MAN/AUTO와 무관하게 독립 동작한다는 점이 이 실험을 봉인된 안전 범위 안에 묶어줍니다 — 정확한
  인식입니다.

  추가로 반드시 넣어야 할 것:

  1. 양방향 Bumpless — AUTO→MAN 시 현재 OP에서 시작, MAN→AUTO 복귀 시 PID가 현재 PV/OP에서 초기화(Experion 기본 지원).
  2. 컴스 워치독 → AUTO로 폴백 (중요한 미묘점): MAN에서 OP 잡고 있다가 외부 프로그램이 죽으면 루프가 마지막 OP에 규제
  없이 방치됨 → 위험. 그래서 "통신 두절 시 MAN 고수가 아니라 AUTO 복귀" 가 안전. 결국 DCS PID는 적당히 튜닝된 채로 두는
  게 폴백 안전망입니다(바이패스해도 AUTO가 늘 안전귀항지여야 함).
  3. PV/품질 가드 — PV가 밴드 이탈하면 4단계 중단→AUTO 또는 안전 OP.
  4. 한 번에 한 루프 — 간섭 루프를 동시에 MAN 두지 않기.
  5. 운전원 최우선 오버라이드 — 항상 즉시 회수 가능.
  6. MoC/문화 — 자동 시스템이 루프를 MAN으로 돌리고 OP를 흔드는 건 현장에서 APC로 간주되어 변경관리·운전원 수용 이슈가
  있음(기술 외 항목).

  5. 기존 인프라와의 매핑 (이미 다 있음)

  - 1~2단계(제안 SP 표시): 루프별 advisory 섀도 포인트(예: FICQ-6101_ADV)를 WriteTagAsync로 쓰고 HMI 그룹/트렌드에 실제
  SP 옆에 표시 → 페이스플레이트 해킹 없이 "제안 vs 실제" 비교. (Experion 디스플레이에 제안값을 어떻게 띄울지가 1~2단계의
   실질 통합 과제)
  - 3단계(SP 주도권): WriteTagAsync(.sp) + AUTO 유지.
  - 4단계(MAN+OP): 바로 그 ControlOp(MD→MAN→OP쓰기→AUTO복귀) 가 4단계의 기본 프리미티브입니다. RestoreAuto=false로 MAN
  유지하며 OP 스트리밍 → 안정되면 AUTO 복귀, 워치독이 비상 복귀.

  ---
  문서로 가기 전에 같이 못 박을 것 세 가지:

  1. 4단계 OP 제어법 — MAN에서 (i) OP 고정 후 가끔 보정인지, (ii) 외부 느린 PI/피드포워드로 OP를 상시 써주는지. 후자면
  "외부 컨트롤러"를 명시적으로 설계해야 합니다(이게 사실상 미니 APC).
  2. 헌팅 임계 정의 — 진폭 몇 %/주기/지속 몇 분에서 4단계 트립? 그리고 stiction 자동 판별을 어디까지 신뢰할지(초기엔 LLM
   진단 → 운전원 확인 권장).
  3. 1~2단계 HMI 표시 방식 — advisory 섀도 포인트로 갈지, Experion 커스텀 디스플레이를 손댈지. 이게 신뢰 구축 단계의
  실현성을 좌우합니다.

  이 세 개에 대한 생각을 주시면, 지금까지의 컨셉·4단계 로드맵·안전봉투·LLM 역할(특히 헌팅 원인 진단)을 플랜 문서에 정식
  섹션으로 정리하겠습니다.

✻ Cooked for 1m 47s

❯ sp는 PID 루프의 RSP 입력을 사용하면, 운전원이 언제든 LOCAL SP로 변경할 수 있으므로, 문제 없슴, 즉, PID LOOP의 SP를
  직접 WRITE하는게 아니고, 별도의 변수에 쓰고, 그게 RSP로 연결, 운전원은 선택권이 있슴

● 맞습니다. RSP(Remote SP)를 쓰는 게 정석이고, 이걸로 권한·bumpless·가역성이 한 번에 깔끔하게 풀립니다. 제가 직전에
  제안한 "advisory 섀도 포인트 + 커스텀 디스플레이"는 이제 필요 없습니다 — 더 나은 길입니다.

  왜 이게 정답인가

  엔진은 루프 SP 레지스터를 절대 건드리지 않고, 자기 변수에만 씁니다. 그 변수가 RSP로 연결되고, 운전원의 LSP↔RSP(=
  Experion 기준 AUTO↔CAS) 전환 스위치가 유일한 권한 손잡이가 됩니다.

  이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다:
  - 1~2단계(제안 표시): 루프는 LSP(AUTO)에 둠. 운전원은 페이스플레이트에서 "원격이 제안하는 SP 후보값"을 그냥 봄. 별도
  화면 개발 불필요 — 네이티브 페이스플레이트가 RSP 후보를 보여줌.
  - 3단계(주도권 이양): 운전원이 신뢰가 생기면 CAS로 한 번 토글 → 그 순간부터 엔진 SP 추종. 코드 추가 0. 되돌리려면 다시
   LSP로 토글하면 끝.

  다만 한 가지 구현 요건 — 외부 추종(tracking)

  여기가 OPC 외부 감독의 미묘점입니다. 정식 Experion 캐스케이드라면 back-calculation 핸드셰이크로 primary가 자동
  추종합니다. 그런데 OPC로 RSP 소스에 쓰는 외부 엔진은 그 핸드셰이크를 못 받습니다. 그래서:

  ▎ 루프가 LSP(미선택) 상태일 때, 엔진은 현재 실작동 SP를 읽어 자기 출력값 = 현재 SP로 추종시켜야 합니다. 그래야
  ▎ 운전원이 CAS로 토글하는 순간 bumpless가 보장됩니다. (선택 안 됐을 때 출력을 현재값에 물려두는 표준 캐스케이드 매너를
  ▎  엔진이 직접 구현)

  이거 하나만 지키면 운전원이 언제 토글해도 충격 없습니다.

  방어 심층 (independent layers)

  1. 엔진 자체 가드 (rate·절대값·변동폭)
  2. DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가.
  3. 운전원 LSP/RSP 토글 (언제든 회수)
  4. ESD/IL/SIS 독립 동작

  구체 작업 항목

  - DCS 구성: 루프별 감독 소스 포인트 생성 → 각 PID의 RSP/X 입력에 control connection. (엔진은 이 포인트에만 OPC write)
  - OPC 타깃 변경: WriteTagAsync 대상이 ...:ficq-6101.sp → 감독 소스 포인트로만 바뀜. 쓰기 인프라는 그대로, 노드 ID만
  교체.
  - 모드 전환은 엔진이 안 함: AUTO↔CAS는 운전원 전유. 엔진은 SP 경로에서 모드를 절대 안 바꿈 → 더 안전.

  한 가지 비대칭 — OP 경로(4단계)는 이만큼 깔끔하지 않음

  RSP 트릭은 SP 경로(방식 A) 를 완벽히 커버합니다. 그런데 4단계(튜닝발 헌팅 → MAN+OP)는 다릅니다:
  - CAS/RSP로 SP를 줘봐야 PID가 루프에 그대로 있으니 튜닝발 헌팅은 안 잡힘.
  - 그래서 4단계는 여전히 MAN으로 내려 OP를 직접 쓰는 "무거운 개입"이고, 이전 단서(엔진이 컨트롤러가 됨 / 워치독→AUTO
  폴백)가 그대로 유효.
  - 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요?
  지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.

  ---
  이제 SP 경로 설계는 깔끔하게 잠겼습니다(RSP + 외부 추종 + 운전원 토글). 직전에 띄운 세 가지 정렬 항목 중 HMI 표시 건은
   RSP로 해결됐고, 남은 건 둘입니다:

  1. 4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부
  OP 입력" 지원 여부.
  2. 헌팅 임계 정의 — 진폭/주기/지속 기준, stiction 자동판별 신뢰 수준.

  이 둘에 대한 방향을 주시면 — 컨셉, RSP 기반 SP 경로, 4단계 OP 경로, 안전봉투, LLM 역할(헌팅 원인 진단 중심), 단계별
  신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다.

✻ Worked for 1m 14s

❯ 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요?
    지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.---> 이것도
  DCS 컨트롤러에 별도의 변수를 만들고, 그걸 우리가 WRITE 하고, SWITCH  기능을 만들어서, PID LOOP OP, LLM OP 를 선택하게
   하면 해결됨

● 정확합니다. 그 셀렉터 방식으로 OP 경로가 RSP와 완전 대칭이 됩니다. 그리고 한 가지 짚으면 — 제대로 하면 이게 기존
  MAN+OP+워치독보다 더 안전해집니다.

  대칭 구조 완성

  ┌──────────────────┬──────────────────────┬────────────────────────┐
  │                  │       SP 경로        │        OP 경로         │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 감독 변수        │ RSP 소스 포인트      │ "LLM OP" 변수          │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 우리가 OPC write │ 그 포인트에만        │ 그 변수에만            │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 운전원 스위치    │ LSP ↔ RSP (AUTO↔CAS) │ PID-OP ↔ LLM-OP 셀렉터 │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 권한             │ 운전원 전유          │ 운전원 전유            │
  └──────────────────┴──────────────────────┴────────────────────────┘

  쓰기 인프라(WriteTagAsync)는 그대로, 노드 ID만 바뀝니다. 양쪽 다 "엔진은 자기 변수에만 쓰고, 운전원이 스위치로
  채택"하는 동일 패턴.

  단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종

  이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면:

  ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이
  ▎ 튀어나옴(bump).

  방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재
  밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로)

  보너스 — 이게 4단계의 위험을 없앱니다

  이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다:

  - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서
  빠졌으니 사라짐.
  - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종
  중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐.

  → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로
  다시 씁니다.

  정직한 단서 — MoC 강도가 다름

  - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험.
  - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 →
  변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱)

  방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립.

  ---
  이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

  LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관)
  피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리
  소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다.

  여기에 + 헌팅 임계 정의(진폭/주기/지속).

  이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단
  역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로
  보수적으로 갈지 알려주세요.

✻ Cooked for 58s

❯  PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이
    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output
  가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고,
  MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 —
   셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만
  씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

  운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로
  올리면 PID가 현재 PV/OP에서 bumpless 재개.

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:

  - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개.
  - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.

  → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다:

  ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 =
  ▎ DCS PID 규제로 fail-safe).

  이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의
  유량/수위 루프는 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 안전합니다.)

  그래서 결론 — 기본값과 예외

  ┌───────────────────────────────────────┬──────────────────────────────────┬──────────────────────────────────────┐
  │               루프 성격               │               방식               │                 이유                 │
  ├───────────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────────┤
  │ 대부분 (유량·수위 등)                 │ MAN+OP쓰기 + DCS 데드맨→AUTO ←   │ 단순·기존인프라·저MoC. 동결이 양성   │
  │                                       │ 당신 안                          │                                      │
  ├───────────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────────┤
  │ 빠르고 위험해 순간 규제 공백도 불가한 │ 선택+back-calc (PID AUTO 추종)   │ 무충격 즉시 폴백 가치가 추가 MoC를   │
  │  소수 루프                            │                                  │ 정당화                               │
  └───────────────────────────────────────┴──────────────────────────────────┴──────────────────────────────────────┘

  즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드.

  ---

  - 섀도/추천 모드 학습: 엔진이 "이렇게 하겠다"를 계산만 하고, 실제 운전원 조치 + 결과를 로깅 → 둘의 격차를 학습.
  "운전원은 항상 P밸브를 우리 모델보다 느리게 연다" → 모델 보정. 탐색 위험 0, 지도학습.
  - CLPM (폐루프 성능 모니터링): Harris 지수(최소분산 대비)·발진 감지·밸브 stiction 진단을 일상 운전 데이터만으로 수행 →
   루프 건강도 점수화 → 튜닝 열화 시 자동 플래그. 이게 재튜닝의 트리거가 되고, LLM이 우선순위를 서술.

  추천 적응 루프 (이 플랜트 기준)

  일상 데이터 → CLPM(Harris·stiction·발진) → LLM이 "열화 루프" 식별·서술
     → 게인 스케줄(L2) 해당 점 벗어남? → Bump Test 재식별(L1)
     → 트윈에서 베이지안 최적화(L4)로 미세조정 → 운전원 승인 → 가드 경유 반영
     → 결과 로깅 → 섀도 학습으로 모델 보정 (순환)

  반드시 지켜야 할 제약 (정직하게)

  - 디지털 트윈 우선 — 현 브랜치 sim/... 활용. L4/L5는 실플랜트 전 트윈 검증 필수.
  - 식별성(Identifiability) — 충분한 가진(excitation) 없으면 모델 못 만듦. 고순도 탑은 비선형·느림 → 작은 선형모델은
  국소적으로만 유효 → 그래서 L2 게인 스케줄링이 핵심.
  - 안전 제약 — 모든 적응은 플랜 §0 가드 레이어 하드 한계 안에서만. 탐색형(L4/L5)엔 trust-region 필수.
  - LLM은 비용함수·실험설계·수렴판정·가드를 담당하고, 최적화 수치는 알고리즘이 낸다 — 여기서도 §0 원칙 유지.
  - 이 C-6111은 품질직결·느림·비선형 = 가장 보수적으로 다뤄야 하는 케이스. L1+L2+섀도부터, L4는 트윈에서만.

  ---
  요약: LLM은 PID 튜닝의 지휘자·진단가·번역가로 강력하고(수치는 결정론 수학이 산출), 플랜트 적응 학습도 가능하되 RL이
  아니라 재식별+게인스케줄링+베이지안최적화+섀도학습+CLPM 조합이 안전하고 현실적인 답입니다.

  이 내용을 자동운전 플랜 문서에 "§10. PID 튜닝 보조 & 적응 학습" 섹션으로 추가해 둘까요?

✻ Crunched for 1m 10s

❯ 좀더 얘기를 하고 문서를 작성하자,

  내가 알고있는것은 밸브의 사이즈, 배관의종류, 컨트롤밸브의 CV 값과 CV 커브, 플로우미터의 유량범위 등의 물리적인
  데이터를 가지고 있다면, 결정론적인 부분을 이것으로 프로그램화 하고, LLM은 실제로 무엇을 할 수있다는거야?

● 아주 정확한 지점을 찌르셨습니다. 솔직하게 답하면 — 그 물리 데이터를 가지고 있다면, 제어 수학에서 LLM이 할 일은 오히려 크게
  줄어듭니다. 그게 맞고, 그게 좋은 겁니다. 하나씩 정리하죠.

  1. 물리 데이터로 결정론화되는 부분 (LLM 불필요)

  말씀하신 데이터는 사실 "데이터 피팅으로 추정"해야 했던 것들을 계산으로 바꿔버립니다:

  ┌───────────────────────────────────┬─────────────────────────────────────────────┬────────────────────┐
  │            물리 데이터            │            계산되는 결정론 모델             │ 이전엔 뭐로 구했나 │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 컨트롤밸브 Cv + Cv 커브(설치특성) │ OP(%) → 유량 관계, 밸브 게인 dQ/dOP         │ Step Test 식별     │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 배관 종류·구경·길이               │ ΔP·마찰, 이송 데드타임 θ = 관내체적/유량    │ Step Test로 θ 측정 │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 드럼/트레이 홀드업 체적           │ 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) │ Step Test로 τ 측정 │
  ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤
  │ 플로우미터 레인지                 │ 스케일링·분해능·노이즈 플로어               │ —                  │
  └───────────────────────────────────┴─────────────────────────────────────────────┴────────────────────┘

  → 즉 자동운전 플랜의 B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업 = 체적/유량 으로 직접 계산됩니다. 밸브 게인도 Cv 커브
  미분으로 나옵니다. 여기에 LLM을 넣을 이유가 없습니다. 모델기반 튜닝(SIMC/Lambda)도 이 물리모델로 바로 Kc·τI가 떨어집니다. 이
  부분은 그냥 프로그램하세요. 제 처음 답에서 "Step Test로 식별"이라던 것의 상당 부분이 당신의 경우 불필요해집니다.

  2. 그런데 물리 데이터가 못 주는 3가지

  여기가 핵심입니다. Cv·배관·유량범위는 하이드롤릭(얼마나 흐르나) 을 줍니다. 그런데 증류탑의 진짜 어려움은 거기가 아닙니다.

  (가) 분리/조성 동특성 — 당신 데이터에 없음.
  원본 문서의 "P(측류)는 15~20분으로 가장 느리다" 는 배관 이송이 아니라 트레이별 물질·열 홀드업 + 기액평형(VLE)으로 새 조성이
  자리잡는 시간입니다. 홀드업 체적은 당신이 알지만, 상대휘발도·트레이 효율·VLE는 Cv 커브에 없습니다. 이 P 지연은 물리
  데이터만으론 안 나오고, 단별(stage) 분리 모델이 필요합니다. → B·D는 물리로 계산되지만, P는 안 됩니다. 이게 경계선입니다.

  (나) 모델-플랜트 불일치(드리프트). Cv 커브는 깨끗한 신품 설계값입니다. 실제론 밸브 stiction·시트 마모, E-6103 파울링, 트레이
  효율 저하로 시간에 따라 어긋납니다. 물리모델은 "어제의 진실"이고 플랜트는 오늘 다릅니다.

  (다) 목적·맥락·예외. 무엇이 "잘 도는" 건지(회수율 최대 vs 에너지 최소 vs 순도 사수), 등급 변경, 기동/정지, 계기 고장, 상류 외란
   — 정적 물리 데이터엔 전혀 없습니다.

  3. 그래서 LLM이 실제로 하는 일 (과장 없이)

  물리모델이 좋을수록 LLM은 제어 경로에서 빠지고 가장자리로 이동합니다. 솔직한 목록:

  ┌──────────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┬───────────────────────────────────────────┐
  │           LLM 역할           │                                                   구체적으로
                    │                정직한 가치                │
  ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┼───────────────────────────────────────────┤
  │ ① 커미셔닝 보조              │ 밸브 데이터시트·Cv 커브·배관 스펙을 파싱해 결정론 엔진의 config/코드로 조립, Cv 값 정합성 점검
                    │ ★★ 즉시 유용. "물리는 결정론" 철학 그대로 │
  ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┼───────────────────────────────────────────┤
  │ ② 데이터 정합(드리프트 진단) │ 물리예측 유량 vs 실측 잔차 계산은 수학, "이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심"
  해석·재교정 트리거는 LLM │ ★★ (나) 해결                              │
  ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┼───────────────────────────────────────────┤
  │ ③ 소프트센서 보조            │ 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간
                    │ ★ (가) 보완(완전 해결 아님)               │
  ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┼───────────────────────────────────────────┤
  │ ④ 감독형 예외 처리           │ 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장)에서 판단·완화
                    │ ★★★ 물리 침묵 영역                        │
  ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┼───────────────────────────────────────────┤
  │ ⑤ 운전원 인터페이스          │ 의도/경제목표 → SV·제약으로 번역, "왜 이렇게 도는지" 설명
                    │ ★★★ 물리 침묵 영역                        │
  ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┼───────────────────────────────────────────┤
  │ ⑥ 교차 데이터 융합           │ 알람+이벤트+랩분석+정비이력+물리잔차를 엮어 진단
                    │ ★★★ 기존 MCP 도구 활용                    │
  └──────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────
  ──────────────────┴───────────────────────────────────────────┘

  4. 핵심 원리 (한 줄)

  ▎ LLM의 가치는 물리모델 품질에 반비례합니다. 당신처럼 물리를 잘 잡을수록 LLM은 제어 산수에서 사라지고 — ③ 못 측정하는 조성, ④
  ▎ 프로그램 안 된 예외, ⑤ 사람 인터페이스, ⑥ 교차 진단, ①커미셔닝으로 옮겨갑니다. 이게 정상이고 안전한 모습입니다.

  ---
  문서로 넘어가기 전에 같이 정리하고 싶은 게 몇 가지 있습니다:

  1. 분리/조성(가) 모델을 어디까지 갈 건가? — P 지연을 (a) 그냥 보수적 고정 τ(15~20분)로 두고 안 건드릴지, (b) 간이 트레이/홀드업
   모델을 세울지, (c) 운전데이터 기반 경험모델로 둘지. 이게 LLM 역할 ③의 깊이를 결정합니다.
  2. 물리 데이터의 형태 — Cv 커브가 표/수식/데이터시트 PDF 중 무엇인가요? 역할 ①(LLM이 config로 조립)의 실현성이 여기 달려
  있습니다.
  3. LLM을 "제어 보조"로 보시는지 "운전 보조(예외·인터페이스)"로 보시는지 — 위 ②④⑤⑥ 중 어디에 무게를 두실지에 따라 문서 구조가
  달라집니다.

  이 세 가지에 대한 생각을 들려주시면, 그걸 반영해서 플랜 문서에 섹션을 작성하겠습니다.

✻ Baked for 1m 17s

❯ 내가 생각하는 방향은 이거야
  1. 결정론이든, llm이든 목표 설정값을 연산---> Experion 서버에 전달
  2. Experion 서버에서 프로그램을 해서, 전달된 값을 화면상(Operator Station 모니터링 HMI)에 PID Loop 표시에 제안한 SP값을 표시
  3. 운전원이 여기에 익숙해지고, 신뢰가 생긴다면, mode 변경, -> Set Point 변경 주도권 가져옴
  4. PID LOOP의 Hunting이 심하다고 판단되는 기준을 넘으면, 매뉴얼 모드로 변경, 제어출력(OP)를 가지고 변경하면서 안정권 유지

  꼭 DCS 컨트롤러의 PID 제어기의 파라미터를 교정하는것이 아니어도 매뉴얼 모드에서, op 변경만 가지고도 가능할까? 하는 의문에서
  시작된 것이 이 세션의 시작 목적이기도 함---> 당연히 안전장치(rate제한, 절대값 제한, 현재 유량 범위 감안 밸브 변동폭 제한, 기본
   컨트롤러에 설정된 ESD, IL 동작 이 보증된 상태에서 임

● 이제 핵심이 명확해졌습니다. 그리고 시작 질문 — "PID 파라미터를 안 건드리고, MANUAL에서 OP만으로 안정화 가능한가?" — 에 정직하게
   답하면: 경우에 따라 Yes, 그리고 그게 오히려 브라운필드에서 더 현실적입니다. 다만 결정적인 단서가 있습니다.

  1. 시작 질문에 대한 직답

  핵심은 헌팅의 원인입니다. MANUAL+OP로 잡히는 헌팅과 안 잡히는 헌팅이 갈립니다.

  ┌───────────────────────────┬─────────────────────────┬────────────────────────────────────────────────────────────────────────
  ───────────────────────────────┐
  │         헌팅 원인         │   MANUAL+OP로 잡히나?   │                                                 설명
                                 │
  ├───────────────────────────┼─────────────────────────┼────────────────────────────────────────────────────────────────────────
  ───────────────────────────────┤
  │ 튜닝 과민(Kc 과대/I 과속) │ ✅ 즉시 잡힘            │ MAN 전환 순간 컨트롤러 피드백이 빠지므로 제어기발 발진이 사라짐. OP를
  천천히·rate제한으로 움직이면 됨 │
  ├───────────────────────────┼─────────────────────────┼────────────────────────────────────────────────────────────────────────
  ───────────────────────────────┤
  │ 상류 외란(원료 헌팅 등)   │ ✅ 잘 잡힘              │ 원본 문서의 "필터 + 부드럽게" 가 곧 MAN 느낌의 피드포워드. 가장 강력한
  케이스                         │
  ├───────────────────────────┼─────────────────────────┼────────────────────────────────────────────────────────────────────────
  ───────────────────────────────┤
  │ 루프 간 간섭              │ ⚠️ 부분적               │ 이동/시차 조절로 완화
                                 │
  ├───────────────────────────┼─────────────────────────┼────────────────────────────────────────────────────────────────────────
  ───────────────────────────────┤
  │ 밸브 stiction(고착)       │ ❌ 안 잡힘, 오히려 악화 │ 물리적 결함. MAN에서 작게 보정하면 또 고착·점프. 액추에이터 마모만
  늘어남 → 정비 대상                 │
  └───────────────────────────┴─────────────────────────┴────────────────────────────────────────────────────────────────────────
  ───────────────────────────────┘

  → 결론: 튜닝·외란발 헌팅은 PID 파라미터를 안 건드리고 MAN+OP로 충분히 안정화됩니다. 단, 한 가지 본질적 사실:

  ▎ MAN으로 가는 순간 DCS PID가 하던 자동 피드백 규제가 사라집니다. OP를 누가 계속 움직여줘야 합니다. 즉 당신은 "튜닝을 안 한" 게
  ▎  아니라 컨트롤러를 DCS 밖(당신 소프트웨어)으로 옮긴 것입니다. 외부 프로그램이 느린 PI/피드포워드로 OP를 써주는, 사실상 외부
  ▎ 컨트롤러가 됩니다.

  이건 정당한 방식이고, 실제 APC가 하는 일과 같습니다. 그리고 브라운필드에서 매력적인 이유: DCS 로직 변경·변경관리(MoC) 없이 OPC
  쓰기만으로 됩니다(당신은 이미 OPC Write가 있음).

  2. 그래서 두 가지 모드를 구분하세요 — 당신의 1~4단계가 정확히 여기 매핑됩니다

  ┌─────────────────────────┬───────────────────────┬──────────────────────────────────────────┬───────────┐
  │          방식           │ 누가 빠른 규제를 하나 │                   언제                   │ 당신 계획 │
  ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤
  │ (A) SP 쓰기 + AUTO 유지 │ DCS PID (그대로 둠)   │ 평상시 감독·최적화. 기저 PID가 쓸만할 때 │ 1~3단계   │
  ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤
  │ (B) OP 쓰기 + MANUAL    │ 당신 소프트웨어       │ 기저 PID가 헌팅인데 재튜닝 못/안 할 때   │ 4단계     │
  └─────────────────────────┴───────────────────────┴──────────────────────────────────────────┴───────────┘

  (A)는 SP를 AUTO 루프에 쓰는 거라 본질적으로 bumpless하고 가장 안전합니다. (B)는 더 강력하지만 규제·bumpless·폴백을 전부 당신이
  책임집니다.

  → 당신 직관이 정확합니다: 평상시엔 (A)로 신뢰를 쌓고, 헌팅 루프에 한해 (B)로 개입. PID 파라미터 교정은 필수가 아닙니다.

  3. 4단계의 전제 — "헌팅 원인 진단"이 게이트 (여기가 LLM의 진짜 자리)

  4단계가 성공하려면 MAN 전환 전에 원인을 판별해야 합니다. stiction인데 OP 핸드홀딩하면 헛수고+마모입니다.

  - 헌팅 검출/심각도 판정 = 결정론(진폭·주기·지속성, 오실레이션 인덱스). MAN 전환 트립도 결정론이어야 함(LLM 지연 불가).
  - 원인 분류(튜닝 vs stiction vs 외란) = LLM + 데이터 융합의 고가치 역할. OP-PV 위상, 한계주기 파형, 상류 신호, 정비이력을 엮어
  "이건 stiction → 4단계 말고 정비 플래그" vs "외란 → 4단계 OP 핸드홀딩 유효" 판단.

  즉 LLM은 OP를 직접 흔드는 게 아니라, "이 루프에 4단계를 적용해도 되는가"를 판정합니다. 이게 당신 비전에 LLM이 깔끔하게 들어가는
   지점입니다.

  4. 안전 봉투 — 당신이 든 것 + 빠진 것

  당신이 명시한 것(✅ 다 맞음): rate 제한 · 절대값 제한 · 현재 유량 대비 밸브 변동폭 제한 · ESD/IL 독립 보증. 특히 ESD/SIS가 BPCS
   루프의 MAN/AUTO와 무관하게 독립 동작한다는 점이 이 실험을 봉인된 안전 범위 안에 묶어줍니다 — 정확한 인식입니다.

  추가로 반드시 넣어야 할 것:

  1. 양방향 Bumpless — AUTO→MAN 시 현재 OP에서 시작, MAN→AUTO 복귀 시 PID가 현재 PV/OP에서 초기화(Experion 기본 지원).
  2. 컴스 워치독 → AUTO로 폴백 (중요한 미묘점): MAN에서 OP 잡고 있다가 외부 프로그램이 죽으면 루프가 마지막 OP에 규제 없이 방치됨
   → 위험. 그래서 "통신 두절 시 MAN 고수가 아니라 AUTO 복귀" 가 안전. 결국 DCS PID는 적당히 튜닝된 채로 두는 게 폴백
  안전망입니다(바이패스해도 AUTO가 늘 안전귀항지여야 함).
  3. PV/품질 가드 — PV가 밴드 이탈하면 4단계 중단→AUTO 또는 안전 OP.
  4. 한 번에 한 루프 — 간섭 루프를 동시에 MAN 두지 않기.
  5. 운전원 최우선 오버라이드 — 항상 즉시 회수 가능.
  6. MoC/문화 — 자동 시스템이 루프를 MAN으로 돌리고 OP를 흔드는 건 현장에서 APC로 간주되어 변경관리·운전원 수용 이슈가 있음(기술
  외 항목).

  5. 기존 인프라와의 매핑 (이미 다 있음)

  - 1~2단계(제안 SP 표시): 루프별 advisory 섀도 포인트(예: FICQ-6101_ADV)를 WriteTagAsync로 쓰고 HMI 그룹/트렌드에 실제 SP 옆에
  표시 → 페이스플레이트 해킹 없이 "제안 vs 실제" 비교. (Experion 디스플레이에 제안값을 어떻게 띄울지가 1~2단계의 실질 통합 과제)
  - 3단계(SP 주도권): WriteTagAsync(.sp) + AUTO 유지.
  - 4단계(MAN+OP): 바로 그 ControlOp(MD→MAN→OP쓰기→AUTO복귀) 가 4단계의 기본 프리미티브입니다. RestoreAuto=false로 MAN 유지하며
  OP 스트리밍 → 안정되면 AUTO 복귀, 워치독이 비상 복귀.

  ---
  문서로 가기 전에 같이 못 박을 것 세 가지:

  1. 4단계 OP 제어법 — MAN에서 (i) OP 고정 후 가끔 보정인지, (ii) 외부 느린 PI/피드포워드로 OP를 상시 써주는지. 후자면 "외부
  컨트롤러"를 명시적으로 설계해야 합니다(이게 사실상 미니 APC).
  2. 헌팅 임계 정의 — 진폭 몇 %/주기/지속 몇 분에서 4단계 트립? 그리고 stiction 자동 판별을 어디까지 신뢰할지(초기엔 LLM 진단 →
  운전원 확인 권장).
  3. 1~2단계 HMI 표시 방식 — advisory 섀도 포인트로 갈지, Experion 커스텀 디스플레이를 손댈지. 이게 신뢰 구축 단계의 실현성을
  좌우합니다.

  이 세 개에 대한 생각을 주시면, 지금까지의 컨셉·4단계 로드맵·안전봉투·LLM 역할(특히 헌팅 원인 진단)을 플랜 문서에 정식 섹션으로
  정리하겠습니다.

✻ Cooked for 1m 47s

❯ sp는 PID 루프의 RSP 입력을 사용하면, 운전원이 언제든 LOCAL SP로 변경할 수 있으므로, 문제 없슴, 즉, PID LOOP의 SP를 직접
  WRITE하는게 아니고, 별도의 변수에 쓰고, 그게 RSP로 연결, 운전원은 선택권이 있슴

● 맞습니다. RSP(Remote SP)를 쓰는 게 정석이고, 이걸로 권한·bumpless·가역성이 한 번에 깔끔하게 풀립니다. 제가 직전에 제안한
  "advisory 섀도 포인트 + 커스텀 디스플레이"는 이제 필요 없습니다 — 더 나은 길입니다.

  왜 이게 정답인가

  엔진은 루프 SP 레지스터를 절대 건드리지 않고, 자기 변수에만 씁니다. 그 변수가 RSP로 연결되고, 운전원의 LSP↔RSP(= Experion 기준
  AUTO↔CAS) 전환 스위치가 유일한 권한 손잡이가 됩니다.

  이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다:
  - 1~2단계(제안 표시): 루프는 LSP(AUTO)에 둠. 운전원은 페이스플레이트에서 "원격이 제안하는 SP 후보값"을 그냥 봄. 별도 화면 개발
  불필요 — 네이티브 페이스플레이트가 RSP 후보를 보여줌.
  - 3단계(주도권 이양): 운전원이 신뢰가 생기면 CAS로 한 번 토글 → 그 순간부터 엔진 SP 추종. 코드 추가 0. 되돌리려면 다시 LSP로
  토글하면 끝.

  다만 한 가지 구현 요건 — 외부 추종(tracking)

  여기가 OPC 외부 감독의 미묘점입니다. 정식 Experion 캐스케이드라면 back-calculation 핸드셰이크로 primary가 자동 추종합니다.
  그런데 OPC로 RSP 소스에 쓰는 외부 엔진은 그 핸드셰이크를 못 받습니다. 그래서:

  ▎ 루프가 LSP(미선택) 상태일 때, 엔진은 현재 실작동 SP를 읽어 자기 출력값 = 현재 SP로 추종시켜야 합니다. 그래야 운전원이 CAS로
  ▎ 토글하는 순간 bumpless가 보장됩니다. (선택 안 됐을 때 출력을 현재값에 물려두는 표준 캐스케이드 매너를 엔진이 직접 구현)

  이거 하나만 지키면 운전원이 언제 토글해도 충격 없습니다.

  방어 심층 (independent layers)

  1. 엔진 자체 가드 (rate·절대값·변동폭)
  2. DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가.
  3. 운전원 LSP/RSP 토글 (언제든 회수)
  4. ESD/IL/SIS 독립 동작

  구체 작업 항목

  - DCS 구성: 루프별 감독 소스 포인트 생성 → 각 PID의 RSP/X 입력에 control connection. (엔진은 이 포인트에만 OPC write)
  - OPC 타깃 변경: WriteTagAsync 대상이 ...:ficq-6101.sp → 감독 소스 포인트로만 바뀜. 쓰기 인프라는 그대로, 노드 ID만 교체.
  - 모드 전환은 엔진이 안 함: AUTO↔CAS는 운전원 전유. 엔진은 SP 경로에서 모드를 절대 안 바꿈 → 더 안전.

  한 가지 비대칭 — OP 경로(4단계)는 이만큼 깔끔하지 않음

  RSP 트릭은 SP 경로(방식 A) 를 완벽히 커버합니다. 그런데 4단계(튜닝발 헌팅 → MAN+OP)는 다릅니다:
  - CAS/RSP로 SP를 줘봐야 PID가 루프에 그대로 있으니 튜닝발 헌팅은 안 잡힘.
  - 그래서 4단계는 여전히 MAN으로 내려 OP를 직접 쓰는 "무거운 개입"이고, 이전 단서(엔진이 컨트롤러가 됨 / 워치독→AUTO 폴백)가
  그대로 유효.
  - 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? 지원하면 OP
  경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.

  ---
  이제 SP 경로 설계는 깔끔하게 잠겼습니다(RSP + 외부 추종 + 운전원 토글). 직전에 띄운 세 가지 정렬 항목 중 HMI 표시 건은 RSP로
  해결됐고, 남은 건 둘입니다:

  1. 4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부 OP 입력"
  지원 여부.
  2. 헌팅 임계 정의 — 진폭/주기/지속 기준, stiction 자동판별 신뢰 수준.

  이 둘에 대한 방향을 주시면 — 컨셉, RSP 기반 SP 경로, 4단계 OP 경로, 안전봉투, LLM 역할(헌팅 원인 진단 중심), 단계별 신뢰 이양
  로드맵 — 전부 플랜 문서로 정리하겠습니다.

✻ Worked for 1m 14s

❯ 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요?
    지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.---> 이것도 DCS
  컨트롤러에 별도의 변수를 만들고, 그걸 우리가 WRITE 하고, SWITCH  기능을 만들어서, PID LOOP OP, LLM OP 를 선택하게 하면 해결됨

● 정확합니다. 그 셀렉터 방식으로 OP 경로가 RSP와 완전 대칭이 됩니다. 그리고 한 가지 짚으면 — 제대로 하면 이게 기존 MAN+OP+워치독보다 더 안전해집니다.

  대칭 구조 완성

  ┌──────────────────┬──────────────────────┬────────────────────────┐
  │                  │       SP 경로        │        OP 경로         │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 감독 변수        │ RSP 소스 포인트      │ "LLM OP" 변수          │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 우리가 OPC write │ 그 포인트에만        │ 그 변수에만            │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 운전원 스위치    │ LSP ↔ RSP (AUTO↔CAS) │ PID-OP ↔ LLM-OP 셀렉터 │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 권한             │ 운전원 전유          │ 운전원 전유            │
  └──────────────────┴──────────────────────┴────────────────────────┘

  쓰기 인프라(WriteTagAsync)는 그대로, 노드 ID만 바뀝니다. 양쪽 다 "엔진은 자기 변수에만 쓰고, 운전원이 스위치로 채택"하는 동일 패턴.

  단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종

  이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면:

  ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 튀어나옴(bump).

  방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로)

  보너스 — 이게 4단계의 위험을 없앱니다

  이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다:

  - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 빠졌으니 사라짐.
  - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐.

  → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 다시 씁니다.

  정직한 단서 — MoC 강도가 다름

  - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험.
  - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱)

  방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립.

  ---
  이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

  LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다.

  여기에 + 헌팅 임계 정의(진폭/주기/지속).

  이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 보수적으로 갈지 알려주세요.

✻ Cooked for 58s

❯  PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이

✻ Cooked for 1m 47s

❯ sp는 PID 루프의 RSP 입력을 사용하면, 운전원이 언제든 LOCAL SP로 변경할 수 있으므로, 문제 없슴, 즉, PID LOOP의 SP를 직접 WRITE하는게 아니고, 별도의 변수에 쓰고, 그게 RSP로 연결, 운전원은 선택권이 있슴                                                                                                                                                                                          

● 맞습니다. RSP(Remote SP)를 쓰는 게 정석이고, 이걸로 권한·bumpless·가역성이 한 번에 깔끔하게 풀립니다. 제가 직전에 제안한 "advisory 섀도 포인트 + 커스텀 디스플레이"는 이제 필요 없습니다 — 더 나은 길입니다.

  왜 이게 정답인가

  엔진은 루프 SP 레지스터를 절대 건드리지 않고, 자기 변수에만 씁니다. 그 변수가 RSP로 연결되고, 운전원의 LSP↔RSP(= Experion 기준 AUTO↔CAS) 전환 스위치가 유일한 권한 손잡이가 됩니다.

  이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다:
  - 1~2단계(제안 표시): 루프는 LSP(AUTO)에 둠. 운전원은 페이스플레이트에서 "원격이 제안하는 SP 후보값"을 그냥 봄. 별도 화면 개발 불필요 — 네이티브 페이스플레이트가 RSP 후보를 보여줌.
  - 3단계(주도권 이양): 운전원이 신뢰가 생기면 CAS로 한 번 토글 → 그 순간부터 엔진 SP 추종. 코드 추가 0. 되돌리려면 다시 LSP로 토글하면 끝.

  다만 한 가지 구현 요건 — 외부 추종(tracking)

  여기가 OPC 외부 감독의 미묘점입니다. 정식 Experion 캐스케이드라면 back-calculation 핸드셰이크로 primary가 자동 추종합니다. 그런데 OPC로 RSP 소스에 쓰는 외부 엔진은 그 핸드셰이크를 못 받습니다. 그래서:

  ▎ 루프가 LSP(미선택) 상태일 때, 엔진은 현재 실작동 SP를 읽어 자기 출력값 = 현재 SP로 추종시켜야 합니다. 그래야 운전원이 CAS로 토글하는 순간 bumpless가 보장됩니다. (선택 안 됐을 때 출력을 현재값에 물려두는 표준 캐스케이드 매너를 엔진이 직접 구현)

  이거 하나만 지키면 운전원이 언제 토글해도 충격 없습니다.

  방어 심층 (independent layers)

  1. 엔진 자체 가드 (rate·절대값·변동폭)
  2. DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가.
  3. 운전원 LSP/RSP 토글 (언제든 회수)
  4. ESD/IL/SIS 독립 동작

  구체 작업 항목

  - DCS 구성: 루프별 감독 소스 포인트 생성 → 각 PID의 RSP/X 입력에 control connection. (엔진은 이 포인트에만 OPC write)
  - OPC 타깃 변경: WriteTagAsync 대상이 ...:ficq-6101.sp → 감독 소스 포인트로만 바뀜. 쓰기 인프라는 그대로, 노드 ID만 교체.
  - 모드 전환은 엔진이 안 함: AUTO↔CAS는 운전원 전유. 엔진은 SP 경로에서 모드를 절대 안 바꿈 → 더 안전.

  한 가지 비대칭 — OP 경로(4단계)는 이만큼 깔끔하지 않음

  RSP 트릭은 SP 경로(방식 A) 를 완벽히 커버합니다. 그런데 4단계(튜닝발 헌팅 → MAN+OP)는 다릅니다:
  - CAS/RSP로 SP를 줘봐야 PID가 루프에 그대로 있으니 튜닝발 헌팅은 안 잡힘.
  - 그래서 4단계는 여전히 MAN으로 내려 OP를 직접 쓰는 "무거운 개입"이고, 이전 단서(엔진이 컨트롤러가 됨 / 워치독→AUTO 폴백)가 그대로 유효.
  - 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? 지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.

  ---
  이제 SP 경로 설계는 깔끔하게 잠겼습니다(RSP + 외부 추종 + 운전원 토글). 직전에 띄운 세 가지 정렬 항목 중 HMI 표시 건은 RSP로 해결됐고, 남은 건 둘입니다:

  1. 4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부 OP 입력" 지원 여부.
  2. 헌팅 임계 정의 — 진폭/주기/지속 기준, stiction 자동판별 신뢰 수준.

  이 둘에 대한 방향을 주시면 — 컨셉, RSP 기반 SP 경로, 4단계 OP 경로, 안전봉투, LLM 역할(헌팅 원인 진단 중심), 단계별 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다.

✻ Worked for 1m 14s

❯ 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요?                                                                                                                                                                                                                                                                                     
    지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.---> 이것도 DCS 컨트롤러에 별도의 변수를 만들고, 그걸 우리가 WRITE 하고, SWITCH  기능을 만들어서, PID LOOP OP, LLM OP 를 선택하게 하면 해결됨                                                                                                                                           

● 정확합니다. 그 셀렉터 방식으로 OP 경로가 RSP와 완전 대칭이 됩니다. 그리고 한 가지 짚으면 — 제대로 하면 이게 기존 MAN+OP+워치독보다 더 안전해집니다.

  대칭 구조 완성

  ┌──────────────────┬──────────────────────┬────────────────────────┐
  │                  │       SP 경로        │        OP 경로         │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 감독 변수        │ RSP 소스 포인트      │ "LLM OP" 변수          │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 우리가 OPC write │ 그 포인트에만        │ 그 변수에만            │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 운전원 스위치    │ LSP ↔ RSP (AUTO↔CAS) │ PID-OP ↔ LLM-OP 셀렉터 │
  ├──────────────────┼──────────────────────┼────────────────────────┤
  │ 권한             │ 운전원 전유          │ 운전원 전유            │
  └──────────────────┴──────────────────────┴────────────────────────┘

  쓰기 인프라(WriteTagAsync)는 그대로, 노드 ID만 바뀝니다. 양쪽 다 "엔진은 자기 변수에만 쓰고, 운전원이 스위치로 채택"하는 동일 패턴.

  단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종

  이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면:

  ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 튀어나옴(bump).

  방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로)

  보너스 — 이게 4단계의 위험을 없앱니다

  이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다:

  - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 빠졌으니 사라짐.
  - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐.

  → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 다시 씁니다.

  정직한 단서 — MoC 강도가 다름

  - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험.
  - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱)

  방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립.

  ---
  이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

  LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다.

  여기에 + 헌팅 임계 정의(진폭/주기/지속).

  이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 보수적으로 갈지 알려주세요.

✻ Cooked for 58s

❯  PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이                                                                                                                                                                                                                                                                                   
    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨                                                                                                                                                                                

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

  단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종

  이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면:

  ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 튀어나옴(bump).

  방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로)

  보너스 — 이게 4단계의 위험을 없앱니다

  이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다:

  - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 빠졌으니 사라짐.
  - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐.

  → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 다시 씁니다.

  정직한 단서 — MoC 강도가 다름

  - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험.
  - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱)

  방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립.

  ---
  이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

  LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다.

  여기에 + 헌팅 임계 정의(진폭/주기/지속).

  이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 보수적으로 갈지 알려주세요.

✻ Cooked for 58s

❯  PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이                 
    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고,
  네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

  운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless 재개.

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:
  소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다.

  여기에 + 헌팅 임계 정의(진폭/주기/지속).

  이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로
  보수적으로 갈지 알려주세요.

✻ Cooked for 58s

❯  PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이                 
    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) /WriteTagAsync(.op) 그대로 —
  셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

  운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless 재개.

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:


❯  PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이
    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을
  변경하면됨

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) /
  WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

  운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless 재개.

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:

  - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개.
  - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.

  → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다:

  ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID 규제로 fail-safe).

  이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히
  안전합니다.)

  그래서 결론 — 기본값과 예외

  ┌─────────────────────────────────────────────────┬────────────────────────────────────────┬───────────────────────────────────────────┐
  │                    루프 성격                    │                  방식                  │                   이유                    │
  ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤
  │ 대부분 (유량·수위 등)                           │ MAN+OP쓰기 + DCS 데드맨→AUTO ← 당신 안 │ 단순·기존인프라·저MoC. 동결이 양성        │

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:

  - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개.
  - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.

  → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다:

  ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID 규제로 fail-safe).

  이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로,
  데드맨→AUTO면 충분히 안전합니다.)

  그래서 결론 — 기본값과 예외

  ┌─────────────────────────────────────────────────┬────────────────────────────────────────┬───────────────────────────────────────────┐
  │                    루프 성격                    │                  방식                  │                   이유                    │
  ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤
  │ 대부분 (유량·수위 등)                           │ MAN+OP쓰기 + DCS 데드맨→AUTO ← 당신 안 │ 단순·기존인프라·저MoC. 동결이 양성        │
  ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤
  │ 빠르고 위험해 순간 규제 공백도 불가한 소수 루프 │ 선택+back-calc (PID AUTO 추종)         │ 무충격 즉시 폴백 가치가 추가 MoC를 정당화 │
  └─────────────────────────────────────────────────┴────────────────────────────────────────┴───────────────────────────────────────────┘

  즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드.
    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은
   값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨                                                                    

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로
  bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로
  가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

  운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless
  재개.

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:

  - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개.
  - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.

  → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다:

  ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID 규제로 fail-safe).

  이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는동결이 한동안 양성이고
  SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 안전합니다.)

  그래서 결론 — 기본값과 예외

  ┌─────────────────────────────────────────────────┬────────────────────────────────────────┬───────────────────────────────────────────┐
  │                    루프 성격                    │                  방식                  │                   이유           │
  ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤
  │ 대부분 (유량·수위 등)                           │ MAN+OP쓰기 + DCS 데드맨→AUTO ← 당신 안 │ 단순·기존인프라·저MoC. 동결이 양 │
  ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤
  │ 빠르고 위험해 순간 규제 공백도 불가한 소수 루프 │ 선택+back-calc (PID AUTO 추종)         │ 무충격 즉시 폴백 가치가 추가 MoC 정당화 │
  └─────────────────────────────────────────────────┴────────────────────────────────────────┴───────────────────────────────────────────┘

  즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드.

    ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) ,
  운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨

● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서
  .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도,
  back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다
  이게 더 나은 기본값입니다.

  운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가
  현재 PV/OP에서 bumpless 재개.

  정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드

  선택+back-calc과 다른 점은 엔진이 죽었을 때입니다:

  - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개.
  - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.

  → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다:

  ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID
  ▎ 규제로 fail-safe).

  이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는
  동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 안전합니다.)

  그래서 결론 — 기본값과 예외

  ┌───────────────────────────────────────────┬────────────────────────────────────┬────────────────────────────────────────┐
  │                 루프 성격                 │                방식                │                  이유                  │
  ├───────────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────────┤
  │ 대부분 (유량·수위 등)                     │ MAN+OP쓰기 + DCS 데드맨→AUTO ←     │ 단순·기존인프라·저MoC. 동결이 양성     │
  │                                           │ 당신 안                            │                                        │
  ├───────────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────────┤
  │ 빠르고 위험해 순간 규제 공백도 불가한     │ 선택+back-calc (PID AUTO 추종)     │ 무충격 즉시 폴백 가치가 추가 MoC를     │
  │ 소수 루프                                 │                                    │ 정당화                                 │
  └───────────────────────────────────────────┴────────────────────────────────────┴────────────────────────────────────────┘

  즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드.

  ---
  이제 SP(RSP)·OP(MAN+OP쓰기+데드맨) 양 경로가 다 잠겼습니다. 남은 마지막 한 가지 — LLM-OP 모드의 제어법 — 에 대한 제 권장은:
  │ 빠르고 위험해 순간 규제 공백도 불가한     │ 선택+back-calc (PID AUTO 추종)     │ 무충격 즉시 폴백 가치가 추가 MoC를     │
  │ 소수 루프                                 │                                    │ 정당화                                 │
  └───────────────────────────────────────────┴────────────────────────────────────┴────────────────────────────────────────┘

  즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드.

  ---
  이제 SP(RSP)·OP(MAN+OP쓰기+데드맨) 양 경로가 다 잠겼습니다. 남은 마지막 한 가지 — LLM-OP 모드의 제어법 — 에 대한 제 권장은:

  ▎ 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI, rate제한. 외란발 헌팅은 FF만으로 잡히고, 약한 PI가 잔차 보정. = "DCS PID가
  ▎ 이랬으면 했던 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 느리게 구동". "고정+간헐 보정"은 규제를 잃어 비권장.

  이 권장안으로 확정하면, 지금까지 합의된 전체를 플랜 문서로 정리하겠습니다:

  - 컨셉 & §0 원칙
  - RSP 기반 SP 경로 (감독소스 포인트 + 외부추종 + 운전원 LSP/RSP)
  - MAN+OP 기반 OP 경로 (ControlOp + DCS 데드맨→AUTO, 선택+back-calc은 임계루프 옵션)
  - 헌팅 검출(결정론) + 원인진단(LLM: 튜닝 vs stiction vs 외란)
  - 안전봉투(rate·절대·변동폭·데드맨·ESD/IL/SIS 독립)
  - 신뢰 이양 로드맵(1~4단계)
  - LLM 역할(물리 결정론 위의 진단·예외·인터페이스·커미셔닝)

  권장 제어법(FF+느린 PI)으로 갈지 알려주시면 바로 문서로 정리하겠습니다. (보수적으로 "고정+간헐 보정"을 원하시면 그걸로
  반영합니다.)

✻ Crunched for 58s

❯ MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.----> 엔진
  WATCHDOG은 당연히 만들어야 할 것이고, WATCHDOG 발생시 , CONTROLLER LOGIC -> PID AUTO MODE 로 하면 해결됨--> OP가 LLM_OP에서
  시작하므로, PID 적산 IMPULSE 출력도 없을 것임, PID LOOP 는 BUMPLESS OUTPUT 설정 되어 있슴

● 정확합니다. 그러면 완전히 닫힙니다. DCS PID가 bumpless output으로 설정돼 있으니, 워치독→AUTO 전환 시 적분항이 현재
  OP(=LLM_OP)에서 back-calc 초기화 → 적분 임펄스 없이 그 자리에서 규제 재개. 셀렉터+back-calc 없이도 동일한 "무충격 즉시 폴백"을
  얻습니다 — 그래서 기본값으로 셀렉터는 아예 불필요합니다.

  확인용 두 가지만 (반론 아님, 설정 체크):

  1. MAN 중 SP 추종/홀드 설정 — 폴백 후 AUTO가 어떤 LSP로 규제할지가 여기서 정해집니다. SP가 PV 추종이면 전환 시점 PV에 머물고,
  SP 홀드면 운전원 목표값으로 복귀(출력은 여전히 bumpless, PI가 천천히 끌고 감). 어느 쪽이 의도인지만 맞춰두면 됩니다.
  2. 이 시나리오 특유의 정직한 단서 — 우리가 OP를 가져온 이유가 그 PID가 헌팅이라서입니다. 따라서 폴백은 헌팅하던 그 PID로
  되돌아갑니다 → 안전(규제됨, SIS가 극단 차단)하지만 엔진 복구/운전원 개입 전까지 헌팅이 재개됩니다. 위험은 아니고 단지 차선 —
  문서에 명시만 해두면 됩니다.

  ---
  이로써 양 경로가 완전히 잠겼습니다:
  - SP: 감독소스 → RSP, 외부추종, 운전원 LSP/RSP 토글
  - OP: MAN + .op write, 엔진 워치독 + DCS 컨트롤러 로직이 stale 감지 → MAN→AUTO(bumpless) 폴백

  남은 마지막 결정은 LLM-OP 모드의 제어법 하나뿐입니다. 제 권장(재확인):

  ▎ 물리 FF(Cv 커브·배관) + 느린 외부 PI, rate제한 — 외란발 헌팅은 FF로, 잔차는 약한 PI로. "고정+간헐 보정"은 규제 상실이라
  ▎ 비권장.

  이걸로 확정해도 될까요? 확정 주시면 — 컨셉/§0 원칙, RSP SP경로, MAN+OP OP경로(+데드맨 폴백), 헌팅 검출(결정론)+원인진단(LLM),
  안전봉투, 1~4단계 신뢰이양, LLM 역할 — 전부 측류추출-자동운전-플랜.md에 정식 섹션으로 추가하겠습니다.

✻ Crunched for 44s

❯ 물리 FF(Cv 커브·배관) + 느린 외부 PI, rate제한 — 외란발 헌팅은 FF로, 잔차는 약한 PI로. "고정+간헐 보정"은 규제 상실이라
    ▎ 비권장. --> 나의 이해가 부족함 좀 더 명확하게 설명해주세요

● 좋습니다, 천천히 직관부터 쌓아가겠습니다. 핵심 상황은 이겁니다: MAN으로 내린 순간부터 밸브 개도(OP%)를 매 순간 "우리"가 정해야
  합니다. DCS PID가 더 이상 규제 안 하니까요. 그럼 OP를 무슨 근거로 정하나? 두 가지 정보원을 씁니다.

  1. 먼저 운전 비유 (정속주행 = cruise control)

  차로 100km/h를 유지한다고 합시다.

  ┌────────────────┬────────────────────────────────────────────────────────────────────────┬────────────────────────────────┐
  │      방법      │                                하는 일                                 │              결과              │
  ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ 피드포워드(FF) │ 언덕이 보이면 차가 느려지기 전에 미리 가속페달을 더 밟음 (이 언덕엔    │ 속도가 거의 안 떨어짐          │
  │                │ 대략 이만큼 필요하다는 걸 앎)                                          │                                │
  ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ 피드백(PI)     │ 계기판이 "98km/h, 2 부족"을 보여주면 그만큼만 살짝 더 밟아 보정        │ 잔차 제거                      │
  ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ 고정+간헐 보정 │ 페달을 한 위치에 고정, 30초마다 한 번씩만 조정                         │ 언덕에서 푹 꺼졌다가 뒤늦게    │
  │                │                                                                        │ 복구 → 출렁임                  │
  ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ rate 제한      │ 페달을 확 밟지 않고 부드럽게 밟음                                      │ 차가 안 울컥거림               │
  └────────────────┴────────────────────────────────────────────────────────────────────────┴────────────────────────────────┘

  FF + PI = 사실상 크루즈컨트롤. 언덕을 미리 보고(FF) + 계기판 잔차를 다듬는다(PI). 이게 우리가 OP에 쓰려는 제어법입니다.

  2. 이 플랜트로 매핑

  - "언덕"(외란) = 원료 F의 헌팅(±5%). 원본 문서의 그 문제.
  - "이 속도엔 가스 이만큼"(물리 지식) = 밸브 Cv 커브. 원하는 유량 Q와 현재 차압 ΔP를 알면 필요한 개도를 직접 계산: 개도% = Cv⁻¹(
   Q / √(ΔP/SG) ). 측정 오차가 쌓이길 기다릴 필요 없이 바로 정답 개도를 압니다.

  FF가 하는 일 (외란발 헌팅을 잡는 핵심)

  1. 원료 F를 필터링(Lag 300s, 플랜의 그것) → F_clean (헌팅 제거된 부드러운 신호)
  2. 물질수지로 목표 발출유량 계산 (B/D/P)
  3. Cv 커브로 각 목표유량 → 정확한 OP% 계산
  4. 플랜의 시간상수(B 1~2분 / D 5분 / P 15~20분)로 부드럽게 그 OP로 이동

  → F가 출렁여도 우리는 필터링된 F로 미리 정답 OP를 계산해 부드럽게 가니까, 밸브가 홱홱 안 움직임 → 헌팅 소멸. (옛 PID는 F
  출렁임을 그대로 받아 밸브를 잡아채서 헌팅했던 것)

  PI가 하는 일 (FF의 오차 청소)

  Cv 커브는 신품 설계값입니다. 밸브 마모·파울링·ΔP 부정확 때문에 FF만으론 살짝 빗나갑니다. 예: 목표 50인데 실제 48.

  → 느린 PI가 잔차(+2)를 보고 OP를 천천히 조금 더 열어 50으로 맞춤.
  "느리게/약하게" 인 이유: ①헌팅을 다시 일으킬 만큼 세게 잡아채면 안 됨 ②큰 일은 FF가 이미 했으니 PI는 자투리만 다듬으면 됨.

  3. 한 줄 공식

  OP = FF(Cv·배관 물리로 계산한 예측 개도)   ← 큰 움직임, 미리, 부드럽게
     + PI(설정값 − 실측 PV, 느린 게인)        ← 작은 잔차만 청소
     → rate 제한 + 절대 min/max + 변동폭 제한  ← 안전 봉투

  4. 왜 "고정+간헐 보정"은 비권장인가

  OP를 고정해두고 가끔만 건드리면, 건드리는 사이사이엔 능동 규제가 0입니다. F가 변하거나 ΔP가 드리프트하면 PV가 흘러가는데 다음
  보정 때까지 아무도 안 잡습니다 → PV 드리프트. 즉 피드백 규제를 통째로 버리는 것. 느린 PI라도 연속적으로 잡아주는 것과
  근본적으로 다릅니다. (= 크루즈컨트롤 vs 페달 고정)

  5. 이미 만든 플랜과의 연결

  새 개념이 아닙니다:
  - FF = 우리가 설계한 결정론 보상 엔진 (필터 → 물질수지 → Cv → OP, 시간상수 적용) 그대로
  - PI = 그 위에 얹는 작은 피드백 트림 하나 추가

  F(헌팅) ─filter→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐
                                                                ├→ OP → rate제한 → 밸브
  설정값 − 실측PV ───────────── 느린 PI ──────────→ OP_pi ┘

  ---
  정리하면: FF는 "물리로 미리 계산한 부드러운 큰 움직임"(헌팅 차단), PI는 "모델 오차만 천천히 청소하는 작은 피드백"(정확도 확보).
   둘이 상호보완이고, 고정+간헐은 피드백을 버려서 PV가 드리프트하므로 안 씁니다.

  이 설명으로 명확해지셨나요? 막히는 부분 있으면 더 풀어드리고, 괜찮으시면 이 제어법을 확정으로 플랜 문서에 반영하겠습니다.

✻ Cooked for 57s

❯ 이해됐어, 이제 플랜 문서에 반영해줘

● 전체 논의를 통합해 플랜 문서를 개정하겠습니다. 먼저 현재 내용을 확인합니다.

  Read 1 file (ctrl+o to expand)

● 전체 논의를 통합해 문서를 전면 개정하겠습니다.

● Write(측류추출-자동운전-플랜.md)

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Overwrite file
 측류추출-자동운전-플랜.md
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
    1  # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜
    2
    3  > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서
    4 -> **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록.
    4 +> 구현하되, **운전원이 단계적으로 신뢰를 쌓아 권한을 넘기는** 감독제어(Supervisory Control) 형태의
    5 +> 자동운전을 설계한다. 결정론 엔진이 제어하고, 로컬 LLM(vLLM Qwen)은 그 위에서 진단·예외·인터페이스를 맡는다.
    6  >
    6 -> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태.
    7 +> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의 완료본. 코드 미작성 상태.
    8
    8 -*작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
    9 +*작성일: 2026-05-22 / 갱신: 2026-05-22 (논의 합의 반영) / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
   10
   11  ---
   12
   12 -## 0. 핵심 원칙 (가장 중요)
   13 +## 0. 핵심 원칙
   14
   14 -**LLM을 빠른 제어 루프에 넣지 않는다.**
   15 +**LLM을 빠른 제어 루프에 넣지 않는다.** 빠른 보상은 결정론 엔진(코드)이, LLM은 분/이벤트 단위 진단·튜닝·인터페이스만.
   16
   16 -`측류추출-시간지연-적용방식.md`가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야
   17 -하는 빠른 루프다. 여기에 LLM을 직접 넣으면:
   18 -
   17  | 문제 | 영향 |
   18  |------|------|
   19  | 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 |
   20  | 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 |
   23 -| 환각 | 잘못된 SV 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 |
   21 +| 환각 | 잘못된 값 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 |
   22
   25 -→ **결론**: 빠른 보상은 **결정론 엔진(코드)** 이 담당하고, **LLM은 분 단위 감독·튜닝·조언만** 한다.
   26 -이것이 LLM을 실공정에 붙이는 유일하게 안전한 형태다.
   23 +따름정리: **헌팅 검출·MAN 전환·OP 산출 등 안전·실시간 판단은 모두 결정론.** LLM은 그 트립을 *설명*하고
   24 +*원인을 진단*할 뿐, 직접 트립시키거나 OP를 쓰지 않는다.
   25
   26  ---
   27
   30 -## 1. 2-Plane 아키텍처
   28 +## 1. 물리 결정론 vs LLM — 역할 경계 (이 플랜의 출발점)
   29
   32 -```
   33 -┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위, 느림) ───────────────┐
   34 -│  · Step Test 곡선 분석 → θ(데드타임)·τ(시상수) 자동 추출      │
   35 -│  · 파라미터(K, τ, 한계값) 튜닝 제안                            │
   36 -│  · 헌팅 / Flooding / 순도 드리프트 이상 감지·자연어 설명       │
   37 -│  · 운전원 Q&A ("왜 제품밸브가 천천히 열려요?")                 │
   38 -│         │ ※ 밸브 직접 쓰기 금지. "엔진 파라미터 저장소"에만    │
   39 -│         │   제안 → 운전원 승인 후 반영                         │
   40 -├─────────┼──────────────────────────────────────────────────────┤
   41 -│  🔒 안전 가드 레이어 (신규, 0순위) ─ 모든 쓰기가 강제 통과     │
   42 -│   hard min/max · 변화율(rate) 제한 · dead band · 태그 화이트   │
   43 -│   리스트 · 통신두절→안전SV 폴백 · 전 쓰기 감사로그            │
   44 -├─────────┼──────────────────────────────────────────────────────┤
   45 -│  Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초 단위)   │
   46 -│   Realtime 구독으로 F(원료유량) 읽기                          │
   47 -│   → Lag(τ=300s) 필터로 헌팅 제거 → F_clean                    │
   48 -│   → B_sv(데드타임 1~2분) / D_sv(5분) / P_sv(15~20분) 계산      │
   49 -│   → 가드 통과 후 WriteTagAsync / ControlOp 로 쓰기            │
   50 -└────────────────────────────────────────────────────────────────┘
   51 -            읽기: ExperionRealtimeService · query_pv_history
   52 -            쓰기: IExperionOpcWriteClient (가드 레이어 경유 필수)
   53 -```
   30 +운영자가 **밸브 사이즈·배관 종류·컨트롤밸브 Cv 값/Cv 커브·플로우미터 유량범위** 등 물리 데이터를
   31 +보유하면, 제어 수학의 상당 부분이 *데이터 피팅 없이 계산*된다.
   32
   55 ----
   33 +### 1.1 물리 데이터로 결정론화되는 것 (LLM 불필요)
   34 +| 물리 데이터 | 계산되는 모델 |
   35 +|------------|--------------|
   36 +| Cv 커브(설치특성) | OP(%) → 유량 관계, 밸브 게인 dQ/dOP |
   37 +| 배관 종류·구경·길이 | ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 |
   38 +| 드럼/트레이 홀드업 체적 | 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) |
   39 +| 플로우미터 레인지 | 스케일링·분해능·노이즈 플로어 |
   40
   57 -## 2. 보상 제어 수식 (Plane 1 — 결정론, LLM 아님)
   41 +→ 자동운전의 **B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업(=체적/유량)으로 직접 계산**된다.
   42 +밸브 게인도 Cv 커브 미분으로 나온다. **이 부분은 그냥 프로그램한다.**
   43
   59 -원본 문서 §2·§4 기준.
   44 +### 1.2 물리 데이터가 못 주는 것
   45 +- **(가) 분리/조성 동특성** — P(측류)의 "15~20분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(VLE)으로
   46 +  새 조성이 자리잡는 시간. 상대휘발도·트레이 효율·VLE는 Cv 커브에 없음. → **B·D는 물리로 계산되지만 P는 별도 모델 필요.**
   47 +- **(나) 모델-플랜트 불일치(드리프트)** — Cv 커브는 신품 설계값. 밸브 stiction·마모, E-6103 파울링, 트레이 효율 저하로 시
      +간에 따라 어긋남.
   48 +- **(다) 목적·맥락·예외** — 회수율 최대 vs 에너지 최소 vs 순도 사수, 등급변경, 기동/정지, 계기고장, 상류 외란.
   49
   61 -- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])`
   62 -- **데드타임(Dead Time)**: 링버퍼로 N틱 지연
   63 -- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** 1개 (원본 §4.1 "1순위 대책")
   50 +### 1.3 따라서 LLM이 실제로 하는 일
   51 +> **LLM의 가치는 물리모델 품질에 반비례.** 물리를 잘 잡을수록 LLM은 제어 산수에서 빠지고 가장자리로 이동.
   52
   65 -| MV | 제어 대상 | τ / 데드타임 | 목적 |
   66 -|----|----------|-------------|------|
   67 -| B | 하부 제거량 | 1~2분 | 탑 넘침(Flooding) 즉시 방지 |
   68 -| D/R | 상부 제거량/환류 | 5분 | 압력/조성 안정화 |
   69 -| P | 측류 제품 추출 | 15~20분 | 초고순도 PGMEA 품질 보호 (가장 보수적) |
   70 -| S | 리보일러 스팀 | 가장 빠름(수초~수분) | 하부 온도 직결 |
   53 +| LLM 역할 | 구체 | 가치 |
   54 +|---------|------|------|
   55 +| ① 커미셔닝 보조 | 밸브 데이터시트·Cv 커브·배관 스펙 파싱 → 엔진 config/코드로 조립, 정합성 점검 | ★★ |
   56 +| ② 드리프트 진단((나)) | 물리예측 vs 실측 잔차는 수학, *"이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심"* 해석·재교정 트리
      +거는 LLM | ★★ |
   57 +| ③ 소프트센서 보조((가)) | 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 | ★ |
   58 +| ④ 감독형 예외 처리((다)) | 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장) 판단·완화 | ★★★ |
   59 +| ⑤ 운전원 인터페이스 | 의도/경제목표 → SV·제약 번역, "왜 이렇게 도는지" 설명 | ★★★ |
   60 +| ⑥ 교차 데이터 융합 | 알람+이벤트+랩분석+정비이력+물리잔차 엮어 진단 (기존 MCP 도구) | ★★★ |
   61 +| ⑦ 헌팅 원인 진단 | 튜닝 vs stiction vs 외란 판별 → 4단계(OP 개입) 적용 여부 게이트 (§4.3) | ★★★ |
   62
   72 -추가 안전요소(원본 §4.2/§4.3): 각 PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑).
   73 -
   63  ---
   64
   76 -## 3. 현 시스템에서 확인된 능력 (재사용 자산)
   65 +## 2. 감독제어 아키텍처 — 운전원이 권한을 쥔다
   66
   78 -### 3.1 쓰기 (이미 구현됨)
   79 -| 기능 | 구현 | 엔드포인트 |
   80 -|------|------|-----------|
   81 -| SP/OP 직접 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, value)` | `POST /api/experion/write` |
   82 -| MAN/AUTO 모드 | `SetModeAsync(cfg, nodeId, "MAN"\|"AUTO")` | `POST /api/experion/mode` |
   83 -| 통합 제어 (MD→MAN → OP쓰기 → AUTO복귀) | `ControlOp(TagName, OpValue, RestoreAuto)` | `POST /api/experion/control` |
   84 -| UI | "OPC UA Write" 탭 (#15) | `index.html #pane-write` |
   67 +핵심 설계 사상: **엔진은 PID 루프의 SP/OP 레지스터를 직접 덮어쓰지 않는다.** 별도 감독변수에 쓰고,
   68 +**운전원이 스위치로 채택**한다. 권한 손잡이는 항상 운전원에게 있다. SP 경로와 OP 경로가 대칭이다.
   69
   86 -### 3.2 읽기
   87 -- `ExperionRealtimeService` — 실시간 PV 구독 (`AddMonitoredItemAsync`), `IHostedService`
   88 -- `query_pv_history` (MCP) / `ExperionHistoryController` — Step Test용 시계열
   70 +| | SP 경로 (평상시) | OP 경로 (헌팅 시) |
   71 +|---|------------------|-------------------|
   72 +| 엔진이 쓰는 곳 | RSP 소스 포인트 (별도 변수) | `.op` (PID MAN 상태에서) |
   73 +| 운전원 스위치 | **LSP ↔ RSP** (Local ↔ Remote SP = AUTO↔CAS) | **PID MODE: AUTO ↔ MAN** |
   74 +| 빠른 규제 담당 | DCS PID (그대로 둠) | 엔진(소프트웨어 컨트롤러) |
   75 +| 폴백(엔진 사망) | 운전원이 LSP로 토글 | 데드맨 → MAN→AUTO (bumpless) |
   76 +| 적용 | 1~3단계 (신뢰 이양) | 4단계 (튜닝발 헌팅 한정) |
   77
   90 -### 3.3 백그라운드 서비스 패턴
   91 -- `IHostedService`/`AddHostedService` 이미 Realtime·History·OpcServer·Mcp에서 사용 중
   92 -  → 신규 `AutoRunService : BackgroundService`가 기존 패턴에 그대로 들어감
   78 +### 2.1 SP 경로 — RSP(Remote Setpoint)
   79 +- 엔진은 **루프 SP를 절대 안 건드림.** 자기 감독소스 포인트에만 OPC write → 그 포인트가 PID의 RSP/X 입력에 control connec
      +tion.
   80 +- 운전원의 **LSP/RSP 토글이 유일한 권한 손잡이.** RSP면 엔진 SP 추종, LSP면 운전원 수동 — 언제든 가역.
   81 +- **bumpless 요건(중요)**: OPC 외부 감독은 DCS의 back-calculation 핸드셰이크를 못 받음.
   82 +  → 루프가 LSP(미선택)일 때 엔진이 **현재 실작동 SP를 읽어 자기 출력=현재 SP로 추종**시켜야 함.
   83 +  그래야 운전원이 RSP로 토글하는 순간 충격 없음.
   84 +- **공짜 안전망**: DCS RSP 한계(SPHILM/SPLOLM, RSP rate)가 엔진과 독립으로 한 겹 더.
   85 +- **장점**: 1~2단계(제안 표시)는 페이스플레이트가 RSP 후보값을 네이티브로 보여줌 → **별도 화면 개발 불필요.**
   86
   94 -### 3.4 LLM 감독용 MCP 도구 (기존)
   95 -- `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`,
   96 -  `summarize_events`, `generate_status_report`, ReAct 에이전트 모드(구현됨)
   87 +### 2.2 OP 경로 — MAN + OP 쓰기 (튜닝발 헌팅 전용)
   88 +- 평상시 RSP로는 **튜닝발 헌팅이 안 잡힘**(PID가 루프에 그대로). 그래서 헌팅 루프에 한해 OP를 직접 잡는다.
   89 +- 방식: PID를 **MAN**으로 → 엔진이 `.op`에 직접 write. **MAN이라 적분이 멈춰 windup 없음, OP 쓰기는 본질적 bumpless.**
   90 +  기존 `ControlOp`(MD→MAN→OP쓰기) / `WriteTagAsync(.op)` 그대로 사용 → **신규 DCS 구성 불필요, 저MoC.**
   91 +- **운전원 회수**: MAN의 OP는 엔진이 쓴 마지막 값 → 운전원이 그 값에서 이어 조정, 또는 AUTO로 올림.
   92 +- **폴백(엔진 사망)**: 엔진 워치독 + **DCS 컨트롤러 로직이 stale(N초 갱신 없음) 감지 → MAN→AUTO 강제 복귀.**
   93 +  PID가 bumpless output 설정이라 **현재 OP(=마지막 LLM_OP)에서 적분 임펄스 없이 규제 재개.**
   94 +  - *정직한 단서*: 폴백은 "헌팅하던 그 PID"로 돌아감 → 안전(규제됨, SIS가 극단 차단)하나 **엔진 복구 전까지 헌팅 재개.**
      +위험 아님, 차선.
   95 +  - 설정 확인: MAN 중 SP 추종/홀드 → 폴백 후 어떤 LSP로 규제할지 결정.
   96 +- **상위 옵션(임계 루프 한정)**: *순간 규제 공백도 불가*한 빠른 루프는 선택+back-calc(PID는 AUTO 추종 유지, 무충격 즉시
      +폴백)을 쓰되, 밸브 출력경로를 변형하므로 MoC가 더 엄격. 기본값은 위 MAN 방식.
   97
   98  ---
   99
  100 -## 4. ⚠️ 안전 관련 발견 사항 (자동운전 전 반드시 처리)
  100 +## 3. LLM-OP 모드의 제어법 — FF + 느린 PI (rate 제한)
  101
  102 -1. **쓰기 경로에 안전 가드가 0건.** `WriteTagAsync`는 들어온 double을 그대로 쓴다 —
  103 -   min/max 클램프·rate limit·범위 검증·변화율 제한 전무. 사람이 UI에서 손으로 쓸 땐 운전원이
  104 -   최종 안전망이지만, **엔진이 자동으로 쓰는 순간 안전망이 사라진다.** → **0순위: 가드 레이어.**
  105 -2. **현재 LLM(MCP)에는 쓰기 도구가 없다.** 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는"
  106 -   상태가 유일한 안전 경계. 자동운전을 붙이면 이 경계를 넘게 됨 → 신중한 권한 설계 필요.
  107 -3. **`ask_iiot_llm`(vLLM 직접 질의) MCP 도구가 빈 응답.** 2회 시도 모두 `(응답 없음)`.
  108 -   vLLM 엔드포인트 상태/연결 점검 필요. (단 `find_tags`/`trace_connections`는 정상 동작.)
  102 +OP 경로로 개입한 동안 엔진이 매 순간 OP에 무엇을 쓰는가. **크루즈컨트롤과 동일 구조**: 미리 예측(FF) + 잔차 청소(PI).
  103
  104 +```
  105 +F(헌팅) ─Lag필터→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐
  106 +                                                              ├→ OP → rate제한 → 절대/변동폭 클램프 → 밸브
  107 +설정값 − 실측PV ───────────────── 느린 PI ───────→ OP_pi ┘
  108 +```
  109 +
  110 +- **FF (피드포워드)**: 물리로 *미리* 정답 개도 계산. `개도% = Cv⁻¹( Q / √(ΔP/SG) )`.
  111 +  필터링된 F_clean로 목표유량(B/D/P)을 물질수지로 구하고 → Cv 커브로 OP 계산 → §5 시간상수로 부드럽게 이동.
  112 +  **외란발 헌팅을 잡는 주역**(반응이 아니라 예측이라 밸브가 안 채인다).
  113 +- **PI (느린 피드백)**: Cv 커브는 신품값이라 마모·파울링·ΔP 부정확으로 살짝 빗나감. 잔차(SP−PV)를
  114 +  **느리게/약하게** 보정. 약한 이유: ①헌팅 재유발 방지 ②큰 일은 FF가 이미 함.
  115 +- **rate 제한**: OP 변화율 제한으로 밸브 부드럽게.
  116 +- **비채택: "고정+간헐 보정"** — 보정 사이 능동 규제 0 → 외란 시 PV 드리프트(피드백 상실). 사용 안 함.
  117 +- **연결**: FF = §5 결정론 보상 엔진 그대로 + 그 위에 작은 PI 트림 하나.
  118 +
  119  ---
  120
  112 -## 5. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections` 기반)
  121 +## 4. 헌팅 검출 & 원인 진단 — 4단계의 게이트
  122
  114 -`trace_connections`가 돌려준 원료 경로:
  115 -```
  116 -P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기
  117 -```
  123 +### 4.1 검출 (결정론)
  124 +- 오실레이션 인덱스: 진폭·주기·지속성. 임계 초과(예: 진폭 > 범위의 X%, 주기 안정, N분 지속) 시 트립.
  125 +- **MAN 전환 트립은 결정론**(LLM 지연 불가). LLM은 트립을 설명만.
  126
  119 -| # | 경로 | 조작변수(MV)/제어 | 유량 | 온도 | 수위/압력 | τ |
  120 -|---|------|------------------|------|------|----------|---|
  121 -| **F** | 원료 투입 | **FICQ-6101**(SP/OP)→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력신호(Lag 300s) |
  122 -| **S** | 리보일러 스팀 | 스팀밸브(리보일러 듀티) | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름
      - |
  123 -| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1~2분 |
  124 -| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), LICA-6113,
      - PI-6111(진공), PICA-6111 | 5분 |
  125 -| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) | 15~20분
      -|
  127 +### 4.2 원인 분류 (LLM + 데이터 융합) — §1.3-⑦
  128 +| 원인 | 4단계(MAN+OP)로 잡히나 | 조치 |
  129 +|------|----------------------|------|
  130 +| 튜닝 과민 | ✅ 즉시 | MAN 전환 → FF+PI로 OP 핸드홀딩 |
  131 +| 상류 외란 | ✅ 잘 잡힘 | 동일(FF가 주역) |
  132 +| 루프 간섭 | ⚠️ 부분 | 시차 조절로 완화 |
  133 +| **밸브 stiction** | ❌ 악화 | **정비 플래그.** OP 핸드홀딩 금지(마모만 늘어남) |
  134
  127 -- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1)
  128 -- 현재 운전 데이터 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종 중, 진공압 PICA-6111 30.4 → 탑 가동 중으로 추정
  135 +→ LLM이 OP-PV 위상·한계주기 파형·상류 신호·정비이력을 엮어 *"이건 stiction → 4단계 말고 정비"* vs
  136 +*"외란 → 4단계 유효"* 판정. **초기엔 LLM 진단 → 운전원 확인 권장.**
  137
  130 -### 5.1 미완료 매핑 (담당 구분)
  131 -- **P(측류 제품 추출) 경로 매핑 — 사용자가 직접 진행 예정** (본 플랜에서는 보류)
  132 -- B(하부 제거) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는
  133 -  C-6111 `trace_connections downstream`로 보강 가능 (착수 시 확정)
  138 +---
  139
  140 +## 5. 보상 제어 수식 (결정론, FF의 본체)
  141 +
  142 +원본 문서 §2·§4 기준.
  143 +- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])`
  144 +- **데드타임**: 링버퍼로 N틱 지연
  145 +- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** (원본 §4.1)
  146 +
  147 +| MV | 제어 대상 | τ / 데드타임 | 근거 | 목적 |
  148 +|----|----------|-------------|------|------|
  149 +| B | 하부 제거량 | 1~2분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 |
  150 +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 |
  151 +| P | 측류 제품 추출 | 15~20분 | **분리/조성 동특성(§1.2-가, 별도 모델)** | 초고순도 PGMEA 품질 보호 |
  152 +| S | 리보일러 스팀 | 가장 빠름 | 압력 즉시 전달 | 하부 온도 직결 |
  153 +
  154 +추가(원본 §4.2/§4.3): PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑).
  155 +
  156  ---
  157
  137 -## 6. 선택사항 (의사결정 대기)
  158 +## 6. 안전 봉투 (Safety Envelope)
  159
  139 -### 6.1 시작 지점 — "무엇부터 구현하나"
  140 -| 옵션 | 내용 | 비고 |
  141 -|------|------|------|
  142 -| **A. 안전 가드 레이어 먼저** | 쓰기 경로에 클램프·변화율·dead band·화이트리스트·감사로그 추가 | **권장**. 자동운전 전제
      -조건이며 수동 쓰기도 즉시 안전해짐 |
  143 -| B. 결정론 보상 엔진(폐루프) | `AutoRunService`: F구독→Lag/데드타임→B/D/P SV 계산→가드 경유 쓰기 | 실제 자동운전 핵심 |
  144 -| C. 조언형(개루프)부터 | 엔진은 권고 SV만 계산·표시, 쓰기는 운전원이 클릭 승인 | 로직 안전검증 후 폐루프 전환 |
  145 -| D. 시뮬레이터 먼저 | FOPDT 증류탑 디지털 트윈으로 실플랜트 전 검증 | 현 브랜치 `sim/...` 와 자연스러움 |
  160 +엔진의 모든 쓰기는 아래를 강제 통과한다(다층 독립 방어):
  161
  147 -### 6.2 LLM 개입 수준 — "LLM 권한 어디까지"
  148 -| 옵션 | 내용 | 비고 |
  149 -|------|------|------|
  150 -| **가. 감독·조언만** | Step Test 분석·이상 설명·파라미터 제안만. 밸브/쓰기 절대 안 함 | **권장**. 가장 안전 |
  151 -| 나. 파라미터 쓰기(승인 게이트) | LLM이 K·τ 등 엔진 파라미터 변경 제안 → 운전원 승인 후 반영. 밸브 직접 제어는 여전히 엔
      -진만 | 적응 튜닝 가능 |
  152 -| 다. MCP 쓰기 도구 추가 | LLM이 MCP로 직접 SV/모드 쓰기(가드 경유) | 유연하나 위험 큼 — 신중 적용 |
  162 +1. **엔진 가드**: rate 제한 · 절대 min/max · **현재 유량범위 대비 밸브 변동폭 제한** · 태그 화이트리스트 · 전 쓰기 감사로
      +그
  163 +2. **DCS 측 한계**: RSP 한계(SPHILM/SPLOLM), 출력 한계(OPHILM/OPLOLM) — 엔진과 독립
  164 +3. **운전원 스위치**: LSP/RSP, AUTO/MAN — 언제든 즉시 회수 (최우선)
  165 +4. **데드맨/워치독**: 엔진 stale → SP경로는 운전원 LSP 회수, OP경로는 DCS 로직이 MAN→AUTO(bumpless) 폴백
  166 +5. **ESD/IL/SIS 독립**: BPCS 루프의 MAN/AUTO·LSP/RSP와 무관하게 최종요소에 독립 동작 → 실험을 봉인된 안전 범위에 묶음
  167 +6. **한 번에 한 루프**: 간섭 루프 동시 MAN 금지
  168 +7. **양방향 bumpless**: 모든 전환에서 충격 없음(PID bumpless output + 엔진 추종)
  169
  154 -> 현재 권장 조합: **6.1-A (가드 먼저) + 6.2-가 (LLM 감독만)** 로 시작 → 검증 후 단계적 확장.
  170 +> ⚠️ **MoC/문화**: 자동 시스템이 SP/OP를 조작하는 것은 현장에서 APC로 간주 → 변경관리·운전원 수용 절차 필요(기술 외 항목)
      +.
  171
  172  ---
  173
  158 -## 7. 단계별 로드맵
  174 +## 7. 단계별 신뢰 이양 로드맵 (운전원 비전)
  175
  160 -- **Phase 0 — 안전 가드 레이어**: 쓰기 경로 클램프/rate/dead band/화이트리스트/폴백/감사로그. (전제조건)
  161 -- **Phase A — 조언형(개루프)**: 보상 엔진이 권고 SV 계산·대시보드 표시 + LLM Step Test 분석기.
  162 -  DCS 쓰기는 운전원 수동 승인. 위험 최소.
  163 -- **Phase B — 감독형 폐루프**: `AutoRunService`가 가드 안에서 SV 자동 쓰기. LLM은 파라미터만 제안(승인 게이트).
  164 -- **Phase C — 자가 튜닝**: LLM이 Step Test 시점 제안 → 자동 피팅 → 시뮬레이터 A/B 검증 후 반영.
  176 +| 단계 | 내용 | 경로 | 권한 |
  177 +|------|------|------|------|
  178 +| **1. 제안 표시** | 엔진이 RSP 소스 포인트에 계산값 write → 운전원이 페이스플레이트에서 "제안 SP"를 봄(LSP 유지) | SP/RS
      +P | 운전원 100% |
  179 +| **2. 관찰·신뢰 형성** | 제안값이 합리적인지 운전원이 일정 기간 관찰 | SP/RSP | 운전원 100% |
  180 +| **3. SP 주도권 이양** | 신뢰 시 운전원이 **RSP로 토글** → 엔진 SP 추종. 언제든 LSP 회수 | SP/RSP | 엔진(가역) |
  181 +| **4. 헌팅 자동 안정화** | 헌팅 임계 초과 + 원인=튜닝/외란 확인 시 PID MAN 전환 → FF+PI로 OP 핸드홀딩 → 안정 후 복귀 | O
      +P/MAN | 엔진(데드맨 폴백) |
  182
  183 +**구현 선행조건(Phase 0)**: §6-1 엔진 가드 레이어 + 데드맨. *(현재 쓰기 경로에 가드 0건 — §10 참조.)*
  184 +
  185  ---
  186
  168 -## 8. LLM이 잘하는 4가지 역할 (Plane 2 상세)
  187 +## 8. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections`)
  188
  170 -1. **Step Test 분석 (강력 추천)** — 원본 §3. 유량 스텝 후 하부/상부/환류드럼/측류 온도·Analyzer 곡선을
  171 -   `query_pv_history`로 뽑아 LLM에 주면 구간별 데드타임 θ·시상수 τ를 읽어냄 (결정론 곡선피팅으로 교차검증)
  172 -   → 그 값이 Plane 1 파라미터가 됨.
  173 -2. **파라미터 튜닝 조언** — 처리량·원료 조성 드리프트 시 K·τ 재조정 제안.
  174 -3. **이상 상황 서술** — "FT 헌팅 5분째 ±5% 지속, 필터 τ 300→420초 권장" 식 자연어 진단.
  175 -4. **운전원 코칭** — 신입에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명.
  189 +원료 경로(trace_connections):
  190 +```
  191 +P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기
  192 +```
  193
  194 +| # | 경로 | MV/제어 | 유량 | 온도 | 수위/압력 | τ |
  195 +|---|------|---------|------|------|----------|---|
  196 +| **F** | 원료 투입 | **FICQ-6101**→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력(Lag 300s) |
  197 +| **S** | 리보일러 스팀 | 스팀밸브 | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름 |
  198 +| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1~2분 |
  199 +| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), LICA-6113,
      + PI-6111(진공), PICA-6111 | 5분 |
  200 +| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) | 15~20분
      +|
  201 +
  202 +- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1).
  203 +  ※ SP 경로 구현 시 write 타깃은 **루프 SP가 아니라 RSP 소스 포인트**로 바뀜(노드 ID만 교체, 쓰기 코드 동일).
  204 +- 현재 운전 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종, 진공압 PICA-6111 30.4 → 가동 중 추정.
  205 +
  206 +### 8.1 미완료 매핑 (담당 구분)
  207 +- **P(측류 제품 추출) 경로 매핑 — 사용자 직접 진행 예정** (본 플랜 보류)
  208 +- B(하부) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 C-6111 `trace_connections downstream`로 보강
  209 +
  210  ---
  211
  179 -## 9. 미해결/확인 필요 항목
  212 +## 9. 현 시스템 재사용 자산
  213
  214 +| 구분 | 자산 |
  215 +|------|------|
  216 +| 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(.sp/.op)`, `SetModeAsync(MAN/AUTO)`, `ControlOp`(MD→MAN→OP→AUTO) / `POST /
      +api/experion/{write,mode,control}` / UI "OPC UA Write" 탭 |
  217 +| 읽기 | `ExperionRealtimeService`(실시간 PV 구독, IHostedService), `query_pv_history`(MCP)/`ExperionHistoryController` |
  218 +| 백그라운드 | `IHostedService`/`AddHostedService` 패턴 기존 사용 → 신규 `AutoRunService : BackgroundService` 그대로 적용
      + |
  219 +| LLM 감독 | `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, `summarize_events`, `
      +generate_status_report`, ReAct 에이전트 모드 |
  220 +
  221 +---
  222 +
  223 +## 10. 미해결/확인 필요 항목
  224 +
  225  - [ ] **P(측류 제품 추출) 경로 매핑** — *사용자 직접 진행*
  226  - [ ] B(하부) 발출 유량계·밸브 태그 확정
  183 -- [ ] 6.1 / 6.2 선택 확정 (시작 지점 / LLM 권한)
  227 +- [ ] **쓰기 경로 안전 가드(§6-1) 신규 구현** — 현재 `WriteTagAsync`에 클램프/rate/변동폭 0건 (Phase 0 선행)
  F(헌팅) ─filter→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐
                                                                ├→ OP → rate제한 → 밸브
  설정값 − 실측PV ───────────── 느린 PI ──────────→ OP_pi ┘

  ---
  정리하면: FF는 "물리로 미리 계산한 부드러운 큰 움직임"(헌팅 차단), PI는 "모델 오차만 천천히 청소하는 작은 피드백"(정확도 확보).
   둘이 상호보완이고, 고정+간헐은 피드백을 버려서 PV가 드리프트하므로 안 씁니다.

  이 설명으로 명확해지셨나요? 막히는 부분 있으면 더 풀어드리고, 괜찮으시면 이 제어법을 확정으로 플랜 문서에 반영하겠습니다.

✻ Cooked for 57s

❯ 이해됐어, 이제 플랜 문서에 반영해줘

● 전체 논의를 통합해 플랜 문서를 개정하겠습니다. 먼저 현재 내용을 확인합니다.

  Read 1 file (ctrl+o to expand)

● 전체 논의를 통합해 문서를 전면 개정하겠습니다.

● Write(측류추출-자동운전-플랜.md)
  ⎿  Added 178 lines, removed 123 lines
        1  # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜
        2
        3  > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서
        4 -> **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록.
        4 +> 구현하되, **운전원이 단계적으로 신뢰를 쌓아 권한을 넘기는** 감독제어(Supervisory Control) 형태의
        5 +> 자동운전을 설계한다. 결정론 엔진이 제어하고, 로컬 LLM(vLLM Qwen)은 그 위에서 진단·예외·인터페이스를 맡는다.
        6  >
        6 -> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태.
        7 +> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의 완료본. 코드 미작성 상태.
        8
        8 -*작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
        9 +*작성일: 2026-05-22 / 갱신: 2026-05-22 (논의 합의 반영) / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)*
       10
       11  ---
       12
       12 -## 0. 핵심 원칙 (가장 중요)
       13 +## 0. 핵심 원칙
       14
       14 -**LLM을 빠른 제어 루프에 넣지 않는다.**
       15 +**LLM을 빠른 제어 루프에 넣지 않는다.** 빠른 보상은 결정론 엔진(코드)이, LLM은 분/이벤트 단위 진단·튜닝·인터페
          +이스만.
       16
       16 -`측류추출-시간지연-적용방식.md`가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야
       17 -하는 빠른 루프다. 여기에 LLM을 직접 넣으면:
       18 -
       17  | 문제 | 영향 |
       18  |------|------|
       19  | 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 |
       20  | 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 |
       23 -| 환각 | 잘못된 SV 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 |
       21 +| 환각 | 잘못된 값 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 |
       22
       25 -→ **결론**: 빠른 보상은 **결정론 엔진(코드)** 이 담당하고, **LLM은 분 단위 감독·튜닝·조언만** 한다.
       26 -이것이 LLM을 실공정에 붙이는 유일하게 안전한 형태다.
       23 +따름정리: **헌팅 검출·MAN 전환·OP 산출 등 안전·실시간 판단은 모두 결정론.** LLM은 그 트립을 *설명*하고
       24 +*원인을 진단*할 뿐, 직접 트립시키거나 OP를 쓰지 않는다.
       25
       26  ---
       27
       30 -## 1. 2-Plane 아키텍처
       28 +## 1. 물리 결정론 vs LLM — 역할 경계 (이 플랜의 출발점)
       29
       32 -```
       33 -┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위, 느림) ───────────────┐
       34 -│  · Step Test 곡선 분석 → θ(데드타임)·τ(시상수) 자동 추출      │
       35 -│  · 파라미터(K, τ, 한계값) 튜닝 제안                            │
       36 -│  · 헌팅 / Flooding / 순도 드리프트 이상 감지·자연어 설명       │
       37 -│  · 운전원 Q&A ("왜 제품밸브가 천천히 열려요?")                 │
       38 -│         │ ※ 밸브 직접 쓰기 금지. "엔진 파라미터 저장소"에만    │
       39 -│         │   제안 → 운전원 승인 후 반영                         │
       40 -├─────────┼──────────────────────────────────────────────────────┤
       41 -│  🔒 안전 가드 레이어 (신규, 0순위) ─ 모든 쓰기가 강제 통과     │
       42 -│   hard min/max · 변화율(rate) 제한 · dead band · 태그 화이트   │
       43 -│   리스트 · 통신두절→안전SV 폴백 · 전 쓰기 감사로그            │
       44 -├─────────┼──────────────────────────────────────────────────────┤
       45 -│  Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초 단위)   │
       46 -│   Realtime 구독으로 F(원료유량) 읽기                          │
       47 -│   → Lag(τ=300s) 필터로 헌팅 제거 → F_clean                    │
       48 -│   → B_sv(데드타임 1~2분) / D_sv(5분) / P_sv(15~20분) 계산      │
       49 -│   → 가드 통과 후 WriteTagAsync / ControlOp 로 쓰기            │
       50 -└────────────────────────────────────────────────────────────────┘
       51 -            읽기: ExperionRealtimeService · query_pv_history
       52 -            쓰기: IExperionOpcWriteClient (가드 레이어 경유 필수)
       53 -```
       30 +운영자가 **밸브 사이즈·배관 종류·컨트롤밸브 Cv 값/Cv 커브·플로우미터 유량범위** 등 물리 데이터를
       31 +보유하면, 제어 수학의 상당 부분이 *데이터 피팅 없이 계산*된다.
       32
       55 ----
       33 +### 1.1 물리 데이터로 결정론화되는 것 (LLM 불필요)
       34 +| 물리 데이터 | 계산되는 모델 |
       35 +|------------|--------------|
       36 +| Cv 커브(설치특성) | OP(%) → 유량 관계, 밸브 게인 dQ/dOP |
       37 +| 배관 종류·구경·길이 | ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 |
       38 +| 드럼/트레이 홀드업 체적 | 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) |
       39 +| 플로우미터 레인지 | 스케일링·분해능·노이즈 플로어 |
       40
       57 -## 2. 보상 제어 수식 (Plane 1 — 결정론, LLM 아님)
       41 +→ 자동운전의 **B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업(=체적/유량)으로 직접 계산**된다.
       42 +밸브 게인도 Cv 커브 미분으로 나온다. **이 부분은 그냥 프로그램한다.**
       43
       59 -원본 문서 §2·§4 기준.
       44 +### 1.2 물리 데이터가 못 주는 것
       45 +- **(가) 분리/조성 동특성** — P(측류)의 "15~20분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(VLE)으로
       46 +  새 조성이 자리잡는 시간. 상대휘발도·트레이 효율·VLE는 Cv 커브에 없음. → **B·D는 물리로 계산되지만 P는 별도 모
          +델 필요.**
       47 +- **(나) 모델-플랜트 불일치(드리프트)** — Cv 커브는 신품 설계값. 밸브 stiction·마모, E-6103 파울링, 트레이 효율
          + 저하로 시간에 따라 어긋남.
       48 +- **(다) 목적·맥락·예외** — 회수율 최대 vs 에너지 최소 vs 순도 사수, 등급변경, 기동/정지, 계기고장, 상류 외란.
       49
       61 -- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])`
       62 -- **데드타임(Dead Time)**: 링버퍼로 N틱 지연
       63 -- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** 1개 (원본 §4.1 "1순위 대책")
       50 +### 1.3 따라서 LLM이 실제로 하는 일
       51 +> **LLM의 가치는 물리모델 품질에 반비례.** 물리를 잘 잡을수록 LLM은 제어 산수에서 빠지고 가장자리로 이동.
       52
       65 -| MV | 제어 대상 | τ / 데드타임 | 목적 |
       66 -|----|----------|-------------|------|
       67 -| B | 하부 제거량 | 1~2분 | 탑 넘침(Flooding) 즉시 방지 |
       68 -| D/R | 상부 제거량/환류 | 5분 | 압력/조성 안정화 |
       69 -| P | 측류 제품 추출 | 15~20분 | 초고순도 PGMEA 품질 보호 (가장 보수적) |
       70 -| S | 리보일러 스팀 | 가장 빠름(수초~수분) | 하부 온도 직결 |
       53 +| LLM 역할 | 구체 | 가치 |
       54 +|---------|------|------|
       55 +| ① 커미셔닝 보조 | 밸브 데이터시트·Cv 커브·배관 스펙 파싱 → 엔진 config/코드로 조립, 정합성 점검 | ★★ |
       56 +| ② 드리프트 진단((나)) | 물리예측 vs 실측 잔차는 수학, *"이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심"* 해석·
          +재교정 트리거는 LLM | ★★ |
       57 +| ③ 소프트센서 보조((가)) | 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 | ★ |
       58 +| ④ 감독형 예외 처리((다)) | 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장) 판단·완화 | ★★★ |
       59 +| ⑤ 운전원 인터페이스 | 의도/경제목표 → SV·제약 번역, "왜 이렇게 도는지" 설명 | ★★★ |
       60 +| ⑥ 교차 데이터 융합 | 알람+이벤트+랩분석+정비이력+물리잔차 엮어 진단 (기존 MCP 도구) | ★★★ |
       61 +| ⑦ 헌팅 원인 진단 | 튜닝 vs stiction vs 외란 판별 → 4단계(OP 개입) 적용 여부 게이트 (§4.3) | ★★★ |
       62
       72 -추가 안전요소(원본 §4.2/§4.3): 각 PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑).
       73 -
       63  ---
       64
       76 -## 3. 현 시스템에서 확인된 능력 (재사용 자산)
       65 +## 2. 감독제어 아키텍처 — 운전원이 권한을 쥔다
       66
       78 -### 3.1 쓰기 (이미 구현됨)
       79 -| 기능 | 구현 | 엔드포인트 |
       80 -|------|------|-----------|
       81 -| SP/OP 직접 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, value)` | `POST /api/experion/write` |
       82 -| MAN/AUTO 모드 | `SetModeAsync(cfg, nodeId, "MAN"\|"AUTO")` | `POST /api/experion/mode` |
       83 -| 통합 제어 (MD→MAN → OP쓰기 → AUTO복귀) | `ControlOp(TagName, OpValue, RestoreAuto)` | `POST /api/experion/con
          -trol` |
       84 -| UI | "OPC UA Write" 탭 (#15) | `index.html #pane-write` |
       67 +핵심 설계 사상: **엔진은 PID 루프의 SP/OP 레지스터를 직접 덮어쓰지 않는다.** 별도 감독변수에 쓰고,
       68 +**운전원이 스위치로 채택**한다. 권한 손잡이는 항상 운전원에게 있다. SP 경로와 OP 경로가 대칭이다.
       69
       86 -### 3.2 읽기
       87 -- `ExperionRealtimeService` — 실시간 PV 구독 (`AddMonitoredItemAsync`), `IHostedService`
       88 -- `query_pv_history` (MCP) / `ExperionHistoryController` — Step Test용 시계열
       70 +| | SP 경로 (평상시) | OP 경로 (헌팅 시) |
       71 +|---|------------------|-------------------|
       72 +| 엔진이 쓰는 곳 | RSP 소스 포인트 (별도 변수) | `.op` (PID MAN 상태에서) |
       73 +| 운전원 스위치 | **LSP ↔ RSP** (Local ↔ Remote SP = AUTO↔CAS) | **PID MODE: AUTO ↔ MAN** |
       74 +| 빠른 규제 담당 | DCS PID (그대로 둠) | 엔진(소프트웨어 컨트롤러) |
       75 +| 폴백(엔진 사망) | 운전원이 LSP로 토글 | 데드맨 → MAN→AUTO (bumpless) |
       76 +| 적용 | 1~3단계 (신뢰 이양) | 4단계 (튜닝발 헌팅 한정) |
       77
       90 -### 3.3 백그라운드 서비스 패턴
       91 -- `IHostedService`/`AddHostedService` 이미 Realtime·History·OpcServer·Mcp에서 사용 중
       92 -  → 신규 `AutoRunService : BackgroundService`가 기존 패턴에 그대로 들어감
       78 +### 2.1 SP 경로 — RSP(Remote Setpoint)
       79 +- 엔진은 **루프 SP를 절대 안 건드림.** 자기 감독소스 포인트에만 OPC write → 그 포인트가 PID의 RSP/X 입력에 cont
          +rol connection.
       80 +- 운전원의 **LSP/RSP 토글이 유일한 권한 손잡이.** RSP면 엔진 SP 추종, LSP면 운전원 수동 — 언제든 가역.
       81 +- **bumpless 요건(중요)**: OPC 외부 감독은 DCS의 back-calculation 핸드셰이크를 못 받음.
       82 +  → 루프가 LSP(미선택)일 때 엔진이 **현재 실작동 SP를 읽어 자기 출력=현재 SP로 추종**시켜야 함.
       83 +  그래야 운전원이 RSP로 토글하는 순간 충격 없음.
       84 +- **공짜 안전망**: DCS RSP 한계(SPHILM/SPLOLM, RSP rate)가 엔진과 독립으로 한 겹 더.
       85 +- **장점**: 1~2단계(제안 표시)는 페이스플레이트가 RSP 후보값을 네이티브로 보여줌 → **별도 화면 개발 불필요.**
       86
       94 -### 3.4 LLM 감독용 MCP 도구 (기존)
       95 -- `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`,
       96 -  `summarize_events`, `generate_status_report`, ReAct 에이전트 모드(구현됨)
       87 +### 2.2 OP 경로 — MAN + OP 쓰기 (튜닝발 헌팅 전용)
       88 +- 평상시 RSP로는 **튜닝발 헌팅이 안 잡힘**(PID가 루프에 그대로). 그래서 헌팅 루프에 한해 OP를 직접 잡는다.
       89 +- 방식: PID를 **MAN**으로 → 엔진이 `.op`에 직접 write. **MAN이라 적분이 멈춰 windup 없음, OP 쓰기는 본질적 bump
          +less.**
       90 +  기존 `ControlOp`(MD→MAN→OP쓰기) / `WriteTagAsync(.op)` 그대로 사용 → **신규 DCS 구성 불필요, 저MoC.**
       91 +- **운전원 회수**: MAN의 OP는 엔진이 쓴 마지막 값 → 운전원이 그 값에서 이어 조정, 또는 AUTO로 올림.
       92 +- **폴백(엔진 사망)**: 엔진 워치독 + **DCS 컨트롤러 로직이 stale(N초 갱신 없음) 감지 → MAN→AUTO 강제 복귀.**
       93 +  PID가 bumpless output 설정이라 **현재 OP(=마지막 LLM_OP)에서 적분 임펄스 없이 규제 재개.**
       94 +  - *정직한 단서*: 폴백은 "헌팅하던 그 PID"로 돌아감 → 안전(규제됨, SIS가 극단 차단)하나 **엔진 복구 전까지 헌
          +팅 재개.** 위험 아님, 차선.
       95 +  - 설정 확인: MAN 중 SP 추종/홀드 → 폴백 후 어떤 LSP로 규제할지 결정.
       96 +- **상위 옵션(임계 루프 한정)**: *순간 규제 공백도 불가*한 빠른 루프는 선택+back-calc(PID는 AUTO 추종 유지, 무
          +충격 즉시 폴백)을 쓰되, 밸브 출력경로를 변형하므로 MoC가 더 엄격. 기본값은 위 MAN 방식.
       97
       98  ---
       99
      100 -## 4. ⚠️ 안전 관련 발견 사항 (자동운전 전 반드시 처리)
      100 +## 3. LLM-OP 모드의 제어법 — FF + 느린 PI (rate 제한)
      101
      102 -1. **쓰기 경로에 안전 가드가 0건.** `WriteTagAsync`는 들어온 double을 그대로 쓴다 —
      103 -   min/max 클램프·rate limit·범위 검증·변화율 제한 전무. 사람이 UI에서 손으로 쓸 땐 운전원이
      104 -   최종 안전망이지만, **엔진이 자동으로 쓰는 순간 안전망이 사라진다.** → **0순위: 가드 레이어.**
      105 -2. **현재 LLM(MCP)에는 쓰기 도구가 없다.** 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는"
      106 -   상태가 유일한 안전 경계. 자동운전을 붙이면 이 경계를 넘게 됨 → 신중한 권한 설계 필요.
      107 -3. **`ask_iiot_llm`(vLLM 직접 질의) MCP 도구가 빈 응답.** 2회 시도 모두 `(응답 없음)`.
      108 -   vLLM 엔드포인트 상태/연결 점검 필요. (단 `find_tags`/`trace_connections`는 정상 동작.)
      102 +OP 경로로 개입한 동안 엔진이 매 순간 OP에 무엇을 쓰는가. **크루즈컨트롤과 동일 구조**: 미리 예측(FF) + 잔차 청
          +소(PI).
      103
      104 +```
      105 +F(헌팅) ─Lag필터→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐
      106 +                                                              ├→ OP → rate제한 → 절대/변동폭 클램프 → 밸브
      107 +설정값 − 실측PV ───────────────── 느린 PI ───────→ OP_pi ┘
      108 +```
      109 +
      110 +- **FF (피드포워드)**: 물리로 *미리* 정답 개도 계산. `개도% = Cv⁻¹( Q / √(ΔP/SG) )`.
      111 +  필터링된 F_clean로 목표유량(B/D/P)을 물질수지로 구하고 → Cv 커브로 OP 계산 → §5 시간상수로 부드럽게 이동.
      112 +  **외란발 헌팅을 잡는 주역**(반응이 아니라 예측이라 밸브가 안 채인다).
      113 +- **PI (느린 피드백)**: Cv 커브는 신품값이라 마모·파울링·ΔP 부정확으로 살짝 빗나감. 잔차(SP−PV)를
      114 +  **느리게/약하게** 보정. 약한 이유: ①헌팅 재유발 방지 ②큰 일은 FF가 이미 함.
      115 +- **rate 제한**: OP 변화율 제한으로 밸브 부드럽게.
      116 +- **비채택: "고정+간헐 보정"** — 보정 사이 능동 규제 0 → 외란 시 PV 드리프트(피드백 상실). 사용 안 함.
      117 +- **연결**: FF = §5 결정론 보상 엔진 그대로 + 그 위에 작은 PI 트림 하나.
      118 +
      119  ---
      120
      112 -## 5. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections` 기반)
      121 +## 4. 헌팅 검출 & 원인 진단 — 4단계의 게이트
      122
      114 -`trace_connections`가 돌려준 원료 경로:
      115 -```
      116 -P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기
      117 -```
      123 +### 4.1 검출 (결정론)
      124 +- 오실레이션 인덱스: 진폭·주기·지속성. 임계 초과(예: 진폭 > 범위의 X%, 주기 안정, N분 지속) 시 트립.
      125 +- **MAN 전환 트립은 결정론**(LLM 지연 불가). LLM은 트립을 설명만.
      126
      119 -| # | 경로 | 조작변수(MV)/제어 | 유량 | 온도 | 수위/압력 | τ |
      120 -|---|------|------------------|------|------|----------|---|
      121 -| **F** | 원료 투입 | **FICQ-6101**(SP/OP)→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력신호(Lag 300s) |
      122 -| **S** | 리보일러 스팀 | 스팀밸브(리보일러 듀티) | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) |
          - 가장 빠름 |
      123 -| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1
          -~2분 |
      124 -| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼),
          -LICA-6113, PI-6111(진공), PICA-6111 | 5분 |
      125 -| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크)
          -| 15~20분 |
      127 +### 4.2 원인 분류 (LLM + 데이터 융합) — §1.3-⑦
      128 +| 원인 | 4단계(MAN+OP)로 잡히나 | 조치 |
      129 +|------|----------------------|------|
      130 +| 튜닝 과민 | ✅ 즉시 | MAN 전환 → FF+PI로 OP 핸드홀딩 |
      131 +| 상류 외란 | ✅ 잘 잡힘 | 동일(FF가 주역) |
      132 +| 루프 간섭 | ⚠️ 부분 | 시차 조절로 완화 |
      133 +| **밸브 stiction** | ❌ 악화 | **정비 플래그.** OP 핸드홀딩 금지(마모만 늘어남) |
      134
      127 -- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1)
      128 -- 현재 운전 데이터 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종 중, 진공압 PICA-6111 30.4 → 탑 가동 중으로 추정
      135 +→ LLM이 OP-PV 위상·한계주기 파형·상류 신호·정비이력을 엮어 *"이건 stiction → 4단계 말고 정비"* vs
      136 +*"외란 → 4단계 유효"* 판정. **초기엔 LLM 진단 → 운전원 확인 권장.**
      137
      130 -### 5.1 미완료 매핑 (담당 구분)
      131 -- **P(측류 제품 추출) 경로 매핑 — 사용자가 직접 진행 예정** (본 플랜에서는 보류)
      132 -- B(하부 제거) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는
      133 -  C-6111 `trace_connections downstream`로 보강 가능 (착수 시 확정)
      138 +---
      139
      140 +## 5. 보상 제어 수식 (결정론, FF의 본체)
      141 +
      142 +원본 문서 §2·§4 기준.
      143 +- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])`
      144 +- **데드타임**: 링버퍼로 N틱 지연
      145 +- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** (원본 §4.1)
      146 +
      147 +| MV | 제어 대상 | τ / 데드타임 | 근거 | 목적 |
      148 +|----|----------|-------------|------|------|
      149 +| B | 하부 제거량 | 1~2분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 |
      150 +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 |
      151 +| P | 측류 제품 추출 | 15~20분 | **분리/조성 동특성(§1.2-가, 별도 모델)** | 초고순도 PGMEA 품질 보호 |
      152 +| S | 리보일러 스팀 | 가장 빠름 | 압력 즉시 전달 | 하부 온도 직결 |
      153 +
      154 +추가(원본 §4.2/§4.3): PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑).
      155 +
      156  ---
      157
      137 -## 6. 선택사항 (의사결정 대기)
      158 +## 6. 안전 봉투 (Safety Envelope)
      159
      139 -### 6.1 시작 지점 — "무엇부터 구현하나"
      140 -| 옵션 | 내용 | 비고 |
      141 -|------|------|------|
      142 -| **A. 안전 가드 레이어 먼저** | 쓰기 경로에 클램프·변화율·dead band·화이트리스트·감사로그 추가 | **권장**. 자
          -동운전 전제조건이며 수동 쓰기도 즉시 안전해짐 |
      143 -| B. 결정론 보상 엔진(폐루프) | `AutoRunService`: F구독→Lag/데드타임→B/D/P SV 계산→가드 경유 쓰기 | 실제 자동운
          -전 핵심 |
      144 -| C. 조언형(개루프)부터 | 엔진은 권고 SV만 계산·표시, 쓰기는 운전원이 클릭 승인 | 로직 안전검증 후 폐루프 전환
          -|
      145 -| D. 시뮬레이터 먼저 | FOPDT 증류탑 디지털 트윈으로 실플랜트 전 검증 | 현 브랜치 `sim/...` 와 자연스러움 |
      160 +엔진의 모든 쓰기는 아래를 강제 통과한다(다층 독립 방어):
      161
      147 -### 6.2 LLM 개입 수준 — "LLM 권한 어디까지"
      148 -| 옵션 | 내용 | 비고 |
      149 -|------|------|------|
      150 -| **가. 감독·조언만** | Step Test 분석·이상 설명·파라미터 제안만. 밸브/쓰기 절대 안 함 | **권장**. 가장 안전 |
      151 -| 나. 파라미터 쓰기(승인 게이트) | LLM이 K·τ 등 엔진 파라미터 변경 제안 → 운전원 승인 후 반영. 밸브 직접 제어는
          - 여전히 엔진만 | 적응 튜닝 가능 |
      152 -| 다. MCP 쓰기 도구 추가 | LLM이 MCP로 직접 SV/모드 쓰기(가드 경유) | 유연하나 위험 큼 — 신중 적용 |
      162 +1. **엔진 가드**: rate 제한 · 절대 min/max · **현재 유량범위 대비 밸브 변동폭 제한** · 태그 화이트리스트 · 전
          +쓰기 감사로그
      163 +2. **DCS 측 한계**: RSP 한계(SPHILM/SPLOLM), 출력 한계(OPHILM/OPLOLM) — 엔진과 독립
      164 +3. **운전원 스위치**: LSP/RSP, AUTO/MAN — 언제든 즉시 회수 (최우선)
      165 +4. **데드맨/워치독**: 엔진 stale → SP경로는 운전원 LSP 회수, OP경로는 DCS 로직이 MAN→AUTO(bumpless) 폴백
      166 +5. **ESD/IL/SIS 독립**: BPCS 루프의 MAN/AUTO·LSP/RSP와 무관하게 최종요소에 독립 동작 → 실험을 봉인된 안전 범위
          +에 묶음
      167 +6. **한 번에 한 루프**: 간섭 루프 동시 MAN 금지
      168 +7. **양방향 bumpless**: 모든 전환에서 충격 없음(PID bumpless output + 엔진 추종)
      169
      154 -> 현재 권장 조합: **6.1-A (가드 먼저) + 6.2-가 (LLM 감독만)** 로 시작 → 검증 후 단계적 확장.
      170 +> ⚠️ **MoC/문화**: 자동 시스템이 SP/OP를 조작하는 것은 현장에서 APC로 간주 → 변경관리·운전원 수용 절차 필요(기
          +술 외 항목).
      171
      172  ---
      173
      158 -## 7. 단계별 로드맵
      174 +## 7. 단계별 신뢰 이양 로드맵 (운전원 비전)
      175
      160 -- **Phase 0 — 안전 가드 레이어**: 쓰기 경로 클램프/rate/dead band/화이트리스트/폴백/감사로그. (전제조건)
      161 -- **Phase A — 조언형(개루프)**: 보상 엔진이 권고 SV 계산·대시보드 표시 + LLM Step Test 분석기.
      162 -  DCS 쓰기는 운전원 수동 승인. 위험 최소.
      163 -- **Phase B — 감독형 폐루프**: `AutoRunService`가 가드 안에서 SV 자동 쓰기. LLM은 파라미터만 제안(승인 게이트).
      164 -- **Phase C — 자가 튜닝**: LLM이 Step Test 시점 제안 → 자동 피팅 → 시뮬레이터 A/B 검증 후 반영.
      176 +| 단계 | 내용 | 경로 | 권한 |
      177 +|------|------|------|------|
      178 +| **1. 제안 표시** | 엔진이 RSP 소스 포인트에 계산값 write → 운전원이 페이스플레이트에서 "제안 SP"를 봄(LSP 유
          +지) | SP/RSP | 운전원 100% |
      179 +| **2. 관찰·신뢰 형성** | 제안값이 합리적인지 운전원이 일정 기간 관찰 | SP/RSP | 운전원 100% |
      180 +| **3. SP 주도권 이양** | 신뢰 시 운전원이 **RSP로 토글** → 엔진 SP 추종. 언제든 LSP 회수 | SP/RSP | 엔진(가역)
          + |
      181 +| **4. 헌팅 자동 안정화** | 헌팅 임계 초과 + 원인=튜닝/외란 확인 시 PID MAN 전환 → FF+PI로 OP 핸드홀딩 → 안정
          +후 복귀 | OP/MAN | 엔진(데드맨 폴백) |
      182
      183 +**구현 선행조건(Phase 0)**: §6-1 엔진 가드 레이어 + 데드맨. *(현재 쓰기 경로에 가드 0건 — §10 참조.)*
      184 +
      185  ---
      186
      168 -## 8. LLM이 잘하는 4가지 역할 (Plane 2 상세)
      187 +## 8. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections`)
      188
      170 -1. **Step Test 분석 (강력 추천)** — 원본 §3. 유량 스텝 후 하부/상부/환류드럼/측류 온도·Analyzer 곡선을
      171 -   `query_pv_history`로 뽑아 LLM에 주면 구간별 데드타임 θ·시상수 τ를 읽어냄 (결정론 곡선피팅으로 교차검증)
      172 -   → 그 값이 Plane 1 파라미터가 됨.
      173 -2. **파라미터 튜닝 조언** — 처리량·원료 조성 드리프트 시 K·τ 재조정 제안.
      174 -3. **이상 상황 서술** — "FT 헌팅 5분째 ±5% 지속, 필터 τ 300→420초 권장" 식 자연어 진단.
      175 -4. **운전원 코칭** — 신입에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명.
      189 +원료 경로(trace_connections):
      190 +```
      191 +P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기
      192 +```
      193
      194 +| # | 경로 | MV/제어 | 유량 | 온도 | 수위/압력 | τ |
      195 +|---|------|---------|------|------|----------|---|
      196 +| **F** | 원료 투입 | **FICQ-6101**→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력(Lag 300s) |
      197 +| **S** | 리보일러 스팀 | 스팀밸브 | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름 |
      198 +| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1
          +~2분 |
      199 +| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼),
          +LICA-6113, PI-6111(진공), PICA-6111 | 5분 |
      200 +| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크)
          +| 15~20분 |
      201 +
      202 +- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1).
      203 +  ※ SP 경로 구현 시 write 타깃은 **루프 SP가 아니라 RSP 소스 포인트**로 바뀜(노드 ID만 교체, 쓰기 코드 동일).
      204 +- 현재 운전 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종, 진공압 PICA-6111 30.4 → 가동 중 추정.
      205 +
      206 +### 8.1 미완료 매핑 (담당 구분)
      207 +- **P(측류 제품 추출) 경로 매핑 — 사용자 직접 진행 예정** (본 플랜 보류)
      208 +- B(하부) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 C-6111 `trace_connections downstream`로
          +보강
      209 +
      210  ---
      211
      179 -## 9. 미해결/확인 필요 항목
      212 +## 9. 현 시스템 재사용 자산
      213
      214 +| 구분 | 자산 |
      215 +|------|------|
      216 +| 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(.sp/.op)`, `SetModeAsync(MAN/AUTO)`, `ControlOp`(MD→MAN→OP→AUTO)
          + / `POST /api/experion/{write,mode,control}` / UI "OPC UA Write" 탭 |
      217 +| 읽기 | `ExperionRealtimeService`(실시간 PV 구독, IHostedService), `query_pv_history`(MCP)/`ExperionHistoryCon
          +troller` |
      218 +| 백그라운드 | `IHostedService`/`AddHostedService` 패턴 기존 사용 → 신규 `AutoRunService : BackgroundService`
          +그대로 적용 |
      219 +| LLM 감독 | `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, `summarize_
          +events`, `generate_status_report`, ReAct 에이전트 모드 |
      220 +
      221 +---
      222 +
      223 +## 10. 미해결/확인 필요 항목
      224 +
      225  - [ ] **P(측류 제품 추출) 경로 매핑** — *사용자 직접 진행*
      226  - [ ] B(하부) 발출 유량계·밸브 태그 확정
      183 -- [ ] 6.1 / 6.2 선택 확정 (시작 지점 / LLM 권한)
      227 +- [ ] **쓰기 경로 안전 가드(§6-1) 신규 구현** — 현재 `WriteTagAsync`에 클램프/rate/변동폭 0건 (Phase 0 선행)
      228 +- [ ] **DCS 구성**: RSP 소스 포인트 생성·연결, OP 데드맨(stale→MAN→AUTO) 로직, RSP 추종/홀드 설정
      229 +- [ ] 헌팅 임계 정의(진폭/주기/지속) 및 stiction 자동판별 신뢰 수준
      230 +- [ ] 각 MV의 hard min/max·변화율·밸브 변동폭 한계(공정 안전 범위) + Cv 커브·배관 물리 데이터 수집 형태
      231 +- [ ] P(측류) 분리/조성 모델(§1.2-가) 깊이 결정: 고정 τ vs 간이 트레이모델 vs 경험모델
      232  - [ ] `ask_iiot_llm`(vLLM) 빈 응답 — vLLM 엔드포인트 상태 점검
      185 -- [ ] 각 MV의 hard min/max·변화율 한계값(공정 안전 범위) 수집
      233  - [ ] Step Test 수행 가능 시점/조건 (가동 중 5~10% 스텝)
      187 -- [ ] APC 블록 내장 여부 vs 일반 PID 환경 (원본 §"현재 시스템 확인 사항")
      234 +- [ ] APC 블록 내장 여부 vs 일반 PID 환경 / MoC 절차
      235
      236  ---
      237
     ...
      241  - 실시간 읽기: `src/Infrastructure/OpcUa/ExperionRealtimeService.cs`
      242  - UI: `src/Web/wwwroot/index.html` (#pane-write)
      243  - MCP 도구: `mcp-server/server.py` (find_tags, trace_connections, query_pv_history, ask_iiot_llm 등)
      244 +
      245 +## 부록 B. 합의된 핵심 결정 (요약)
      246 +1. 감독제어 — 엔진은 별도 변수에만 쓰고 운전원이 스위치로 채택(권한은 운전원).
      247 +2. SP는 **RSP** 경로(LSP/RSP 토글), 외부 추종으로 bumpless.
      248 +3. OP는 **MAN+`.op` 쓰기** 경로(기존 ControlOp), 엔진 워치독 + **DCS 데드맨→MAN→AUTO bumpless** 폴백.
      249 +4. OP 제어법은 **물리 FF(Cv·배관) + 느린 PI + rate제한** (고정+간헐 보정 비채택).
      250 +5. PID 파라미터 재튜닝은 **필수 아님** — MAN에서 OP 대체로 헌팅 안정화 가능(stiction 제외).
      251 +6. LLM은 물리 결정론 위에서 ①커미셔닝 ②드리프트진단 ③소프트센서 ④예외처리 ⑤인터페이스 ⑥교차융합 ⑦헌팅원인진단.

● 플랜 문서를 전면 개정했습니다. 이번 세션에서 합의한 내용을 모두 반영했습니다. 향후 세션을 위해 핵심 발견을 메모리에
  남겨두겠습니다.

  Read 1 file, recalled 1 memory, wrote 2 memories (ctrl+o to expand)

● 플랜 문서 개정과 메모리 기록을 완료했습니다.

  측류추출-자동운전-플랜.md 개정 내역

  처음 작성본(2-Plane 일반론)에서 → 이번 세션에서 합의한 감독제어 구체 설계로 전면 개편했습니다.

  새로 추가/확정된 핵심 섹션:

  ┌────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │   §    │                                                       내용                                                       │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ §1     │ 물리 결정론 vs LLM 역할 경계 — Cv·배관으로 B·D는 계산되나 P(측류)는 분리/조성 모델 필요, LLM은 ①~⑦ 가장자리 역할 │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ §2     │ 감독제어 아키텍처 — SP=RSP / OP=MAN+OP쓰기 대칭 표, 운전원이 권한 쥠, bumpless 요건, 데드맨 폴백                 │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ §3     │ LLM-OP 제어법 — FF(Cv) + 느린 PI + rate제한, 크루즈컨트롤 다이어그램, "고정+간헐" 비채택                         │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ §4     │ 헌팅 검출(결정론) + 원인진단(LLM: 튜닝/외란/stiction) — 4단계 게이트                                             │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ §6     │ 안전 봉투 — 엔진가드·DCS한계·운전원스위치·데드맨·ESD/IL/SIS 독립·한루프·bumpless 7층                             │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ §7     │ 1~4단계 신뢰 이양 로드맵 (운전원 비전)                                                                           │
  ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ 부록 B │ 합의된 6대 핵심 결정 요약                                                                                        │
  └────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  §8 태그 매핑은 P 경로 = 사용자 직접 진행으로 유지했습니다.

  메모리

  project_autopilot_plan.md를 추가하고 인덱스에 등록했습니다. 향후 세션이 자동운전 작업에 들어가기 전 알아야 할 두 가지 — 쓰기
  경로 가드 0건(Phase 0 선행), ask_iiot_llm 빈 응답(vLLM 점검) — 을 명시해 두었습니다.

  플랜 §10에 미해결 항목(가드 구현, DCS 구성, 헌팅 임계 정의, P 분리모델 깊이 등)을 체크리스트로 정리해 두었으니, 다음에 어느
  항목부터 착수할지 정하시면 됩니다.

✻ Churned for 2m 28s

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ 쓰기 경로 안전 가드부터 구현해줘
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  ⏵⏵ accept edits on (shift+tab to cycle)



