ExperionCrawler/측류추출-자동운전-플랜-컨셉회의.md at 50705ab0e83541ca6f66de0c8341e4f7e1b549ab

Files

windpacer 87ab8adfe0 docs: 측류추출 자동운전 플랜 문서 추가

C-6111 측류추출탑 자동운전 관련 플랜·관계식·운전 주의점 문서.

- 측류추출-자동운전-플랜-byOpus.md / -컨셉회의.md(.docx)
- 측류추출-관계식.md, PGMEA_측류추출운전방식_주의점.md
- 측류추출-시간지연-적용방식.md(박스 정렬 수정)

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

2026-05-24 06:31:58 +09:00

247 KiB

Raw Blame History

▐▛███▜▌ 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 자동운전"의 설계를 결정합니다.

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

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

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

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

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, 12분) │ │ ├─ 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# 어느 쪽이든 수십 줄.

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

현 시스템이 읽기 전용이므로, 밸브를 직접 안 여는 "조언형 자동운전(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 쓰기 없이 안전.

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

단계별 로드맵

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

안전 가드 (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가지

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

쓰기 경로에 안전 가드가 0건입니다. WriteTagAsync는 들어온 double 값을 그대로 씁니다 — min/max 클램프, rate limit, 범위 검증, 변화율 제한이 전혀 없습니다. 사람이 UI에서 손으로 쓸 땐 운전원이 최종 안전망이지만, 엔진이 자동으로 쓰는 순간 이 안전망이 사라집니다. 잘못된 SV 한 줄이 바로 밸브로 갑니다.
현재 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(하부수위) │ 12분 │ │ │ 제거 │ │ │ │ │ │ ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤ │ │ 상부/환 │ 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(제품탱 │ 1520분 │ │ │ 제품 │ │ 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칸 (엔진 만들기 전 확정 필요)

B(하부 제거) 유량계·밸브 태그 — LI-6111 수위는 있는데 발출 유량/밸브 태그가 안 잡힙니다.
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분/1520분 지연 보상"은 초 단위로 결정론적으로 돌아야 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초(35분)** 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(제품탱크) | 1520분 | 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) 그걸 학습으로 플랜트에 맞게 적응시키는 게 현실적인가.

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 진공 │ 비교적 빠름 │ — │ └────────────────────────┴───────────────────────────────────┴──────────────────────────────┘

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

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

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

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

가능합니다. 하지만 "강화학습으로 증류탑을 학습"은 실플랜트에선 위험·비현실적입니다(샘플 비효율 + 탐색 = 나쁜 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이 할 일은 오히려 크게 줄어듭니다. 그게 맞고, 그게 좋은 겁니다. 하나씩 정리하죠.

물리 데이터로 결정론화되는 부분 (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로 식별"이라던 것의 상당 부분이 당신의 경우 불필요해집니다.

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

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

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

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

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

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

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

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

핵심 원리 (한 줄)

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

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

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

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

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

✻ Baked for 1m 17s

❯ 내가 생각하는 방향은 이거야

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

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

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

시작 질문에 대한 직답

핵심은 헌팅의 원인입니다. 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가 있음).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4단계 OP 제어법 — MAN에서 (i) OP 고정 후 가끔 보정인지, (ii) 외부 느린 PI/피드포워드로 OP를 상시 써주는지. 후자면 "외부 컨트롤러"를 명시적으로 설계해야 합니다(이게 사실상 미니 APC).
헌팅 임계 정의 — 진폭 몇 %/주기/지속 몇 분에서 4단계 트립? 그리고 stiction 자동 판별을 어디까지 신뢰할지(초기엔 LLM 진단 → 운전원 확인 권장).
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)

엔진 자체 가드 (rate·절대값·변동폭)
DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가.
운전원 LSP/RSP 토글 (언제든 회수)
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로 해결됐고, 남은 건 둘입니다:

4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부 OP 입력" 지원 여부.
헌팅 임계 정의 — 진폭/주기/지속 기준, 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이 우선순위를 서술.

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

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

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

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

✻ Crunched for 1m 10s

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

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

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

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

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

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

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

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

핵심 원리 (한 줄)

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

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

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

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

✻ Baked for 1m 17s

❯ 내가 생각하는 방향은 이거야

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

시작 질문에 대한 직답

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

✻ Cooked for 1m 47s

왜 이게 정답인가

이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다:

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

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

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

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

방어 심층 (independent layers)

엔진 자체 가드 (rate·절대값·변동폭)
DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가.
운전원 LSP/RSP 토글 (언제든 회수)
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쓰기+워치독으로 남습니다.

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

✻ Worked for 1m 14s

대칭 구조 완성

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

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

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

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

보너스 — 이게 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 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

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

✻ Cooked for 58s

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

✻ Cooked for 1m 47s

왜 이게 정답인가

이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다:

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

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

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

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

방어 심층 (independent layers)

엔진 자체 가드 (rate·절대값·변동폭)
DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가.
운전원 LSP/RSP 토글 (언제든 회수)
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쓰기+워치독으로 남습니다.

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

✻ Worked for 1m 14s

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

대칭 구조 완성

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

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

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

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

보너스 — 이게 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 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

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

✻ Cooked for 58s

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

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

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

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

보너스 — 이게 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 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐:

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

✻ Cooked for 58s

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

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

선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: 소프트웨어에서 구동". 헌팅 원인이 외란이면 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 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다.

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

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

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

선택+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).

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

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

선택+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).

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

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

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

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

선택+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 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨

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

선택+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).

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

┌───────────────────────────────────────────┬────────────────────────────────────┬────────────────────────────────────────┐ │ 루프 성격 │ 방식 │ 이유 │ ├───────────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────────┤ │ 대부분 (유량·수위 등) │ 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 없이도 동일한 "무충격 즉시 폴백"을 얻습니다 — 그래서 기본값으로 셀렉터는 아예 불필요합니다.

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

MAN 중 SP 추종/홀드 설정 — 폴백 후 AUTO가 어떤 LSP로 규제할지가 여기서 정해집니다. SP가 PV 추종이면 전환 시점 PV에 머물고, SP 홀드면 운전원 목표값으로 복귀(출력은 여전히 bumpless, PI가 천천히 끌고 감). 어느 쪽이 의도인지만 맞춰두면 됩니다.
이 시나리오 특유의 정직한 단서 — 우리가 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를 무슨 근거로 정하나? 두 가지 정보원을 씁니다.

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

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

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

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

이 플랜트로 매핑

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

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

원료 F를 필터링(Lag 300s, 플랜의 그것) → F_clean (헌팅 제거된 부드러운 신호)
물질수지로 목표 발출유량 계산 (B/D/P)
Cv 커브로 각 목표유량 → 정확한 OP% 계산
플랜의 시간상수(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는 자투리만 다듬으면 됨.

한 줄 공식

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

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

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

이미 만든 플랜과의 연결

새 개념이 아닙니다:

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분/1520분 지연 보상"은 초 단위로 결정론적으로 돌아야 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(측류)의 "1520분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(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.51.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 +| 적용 | 13단계 (신뢰 이양) | 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 +- 장점: 12단계(제안 표시)는 페이스플레이트가 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(하부수위) | 12분 | 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(제품탱크) | 1520분 -| 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 | 하부 제거량 | 12분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 | 150 +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 | 151 +| P | 측류 제품 추출 | 1520분 | 분리/조성 동특성(§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(하부수위) | 12분 | 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(제품탱크) | 1520분 +| 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 ┘

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

✻ 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분/1520분 지연 보상"은 초 단위로 결정론적으로 돌아야 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(측류)의 "1520분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(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.51.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 +| 적용 | 13단계 (신뢰 이양) | 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 +- 장점: 12단계(제안 표시)는 페이스플레이트가 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(제품탱크) -| 1520분 | 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 | 하부 제거량 | 12분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 | 150 +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 | 151 +| P | 측류 제품 추출 | 1520분 | 분리/조성 동특성(§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(제품탱크) +| 1520분 | 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 │ 14단계 신뢰 이양 로드맵 (운전원 비전) │ ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 부록 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)

247 KiB Raw Blame History Unescape Escape

247 KiB

Raw Blame History