diff --git a/PGMEA_측류추출운전방식_주의점.md b/PGMEA_측류추출운전방식_주의점.md new file mode 100644 index 0000000..81a11f8 --- /dev/null +++ b/PGMEA_측류추출운전방식_주의점.md @@ -0,0 +1,75 @@ +# 반도체 신너(PGMEA) 증류탑 측류 추출(Side-stream) 운전 방식 및 주의점 + +본 문서는 반도체 공정용 초고순도 PGMEA 정제 과정에서 사용되는 '측류 추출 방식(Side-stream Draw)'의 원리, 2기 직렬 탑 대비 단점, 그리고 정밀 운전을 위한 최우선 관리 항목에 대해 정리한 엔지니어링 가이드입니다. + +--- + +## 1. 측류 추출 운전 방식의 개요 및 목적 + +단일 증류탑에서 탑 상부(Top) 환류 라인 일부와 탑 하부(Bottom) 리보일러 유량 일부를 제거(Purge/Blowdown)하고, 탑 중간(Middle)에서 제품을 추출하는 이유는 **하나의 증류탑 내에서 PGMEA보다 끓는점이 낮은 물질(경비물)과 높은 물질(중비물)을 동시에 완벽히 분리**하기 위함입니다. + +``` + [ 탑 상부 (Top) ] + ---> 경비물 제거 (수분, 메탄올, PGME 등) + | (리플럭스 라인 일부 Purge) + | + |===| + | | + Feed | | ---> [ 탑 중간 (Middle) ] + ------> | | 초고순도 PGMEA 제품 측류 추출 (Side-stream Draw) + | | + |===| + | + |---> [ 탑 하부 (Bottom) ] + 중비물 제거 (DPGMEA, 금속 불순물, 중합물 등) + (열교환 유량 일부 Blowdown) +``` + +* **탑 상부(Top) 리플럭스일부 제거:** 수분, 메탄올, PGME 등 끓는점이 낮은 가벼운 불순물을 계 외로 배출하여 탑 내 농축 및 제품단으로의 하강을 차단합니다. +* **탑 하부(Bottom) 유량 일부 제거:** DPGMEA, 고분자 중합물, 금속 성분 등 끓는점이 높은 무거운 불순물을 배출하여 리보일러 파울링(Fouling)을 방지하고 기류를 통한 제품단 오염을 방지합니다. +* **탑 중간(Middle) 제품 추출:** 가벼운 물질과 무거운 물질이 모두 최소화된 탑 중간의 '최고 순도 구간(Sweet Spot)'에서 측류로 제품을 뽑아내어 반도체급 스펙을 만족시킵니다. +* **경제적 이점:** 2개의 증류탑을 직렬로 연결하는 대신 1개의 증류탑만 사용하여 설비 투자비(CAPEX) 및 에너지 비용(OPEX)을 극적으로 절감할 수 있습니다. + +--- + +## 2. 2개 탑 직렬 연결 방식 대비 단점 + +측류 추출 방식은 경제성이 우수한 반면, 기술적·운전 측면에서 다음과 같은 명확한 단점과 한계를 가집니다. + +### ① 운전 및 제어의 극악한 난이도 (Process Coupling) +* **직렬 방식:** 1번 탑(경비물 제거)과 2번 탑(중비물 제거)의 제어 루프가 독립적입니다. +* **측류 추출 방식:** 모든 운전 변수가 하나로 복잡하게 얽혀 있습니다. 예를 들어, 상부 환류량을 미세하게 조정하더라도 탑 전체의 온도 및 조성 프로파일이 흔들려 중간 제품의 순도가 동시에 출렁이게 되므로 고도의 고급 공정 제어(APC)가 요구됩니다. + +### ② 원료 조성 및 공급 조건 변화에 대한 취약성 +* 증류탑 내부에서 순도가 가장 높은 '최적의 추출 지점'은 고정되어 있지 않고, 유입되는 원료의 불순물 농도 및 유량에 따라 위아래로 계속 이동합니다. +* 실제 운전 중에는 물리적인 추출단 배관 위치를 바꿀 수 없으므로, 피드(Feed) 조건이 조금만 흔들려도 경비물이나 중비물이 제품단으로 쉽게 유입됩니다. + +### ③ 초고순도(Electronic Grade) 달성의 구조적 한계 +* 탑 내부의 격렬한 기-액 접촉 과정에서 발생하는 미세한 액적 비산(Entrainment)이나 급격한 증기 흐름으로 인해, 경비물이나 중비물이 제품 측류에 미량 혼입될 위험이 늘 존재합니다. +* ppb(parts per billion) 단위의 극단적인 불순물 제어가 필요한 반도체 최고 등급 품질 관리에서는 안정성 면에서 직렬 방식보다 불리할 수 있습니다. + +### ④ 운전 유연성(Turndown Ratio) 저하 +* 시장 수요 감소 등으로 인해 공장 생산량을 낮추어 저부하(Low Load) 운전을 할 때, 탑 내부의 유체역학적 균형(기-액 밸런스)이 쉽게 깨집니다. +* 기류 유속이 떨어지면 상부 불순물이 하강하고, 액체 흐름이 약해지면 하부 불순물이 축적되어 생산량을 줄였을 때 오히려 순도가 저하되는 역설적인 상황이 발생할 수 있습니다. + +--- + +## 3. 측류 추출 운전 시 최우선 제어 관리 항목 (우선순위) + +단일 측류 추출탑의 운전 성패는 **"탑 내부의 온도 및 조성 프로파일을 설정된 제어 위치에 완벽하게 고정하는 것"**에 달려 있습니다. + +### 1순위 | 감도 트레이(Sensitive Tray) 온도의 정밀 제어 +* **개념:** 외부 외란에 의해 탑 내부 조성 분포가 흔들리는 것을 막기 위해, 온도가 가장 민감하게 변하는 특정 트레이(Tray)를 지정합니다. +* **조치:** 감도 트레이의 온도를 소수점 단위로 실시간 감시하고, 이 온도와 상부 환류량(Reflux) 또는 리보일러 열량을 연동(Cascaded Control)시켜 탑 전체의 온도 경계선이 위아래로 출렁이지 않도록 묶어두어야 합니다. + +### 2순위 | 측류 추출량(Draw Rate)과 내부 물질 수지의 밸런스 +* **개념:** 중간에서 제품을 지나치게 많이 뽑아내면(Over-draw), 제품단 아래쪽으로 내려가야 할 액체 환류량이 부족해져 상부의 경비물이 제품단으로 빨려 내려오게 됩니다. +* **조치:** 측류 추출량은 독립 제어하기보다 피드(Feed) 유량 및 상부 환류량과 일정 비율을 유지하도록 비율 제어(Ratio Control)를 적용해야 합니다. + +### 3순위 | 피드(Feed) 조건의 외란 원천 차단 +* **개념:** 유입되는 원료의 온도, 유량, 조성(수분 등)이 흔들리면 탑 내부 밸런스가 즉시 붕괴됩니다. +* **조치:** 증류탑 전단에 피드 예열기(Preheater)를 설치하여 입조 온도를 항시 일정하게 유지하고, 원료 탱크 내 조성을 균일화하는 완충(Buffering) 시스템을 철저히 관리해야 합니다. + +### 4순위 | 물리적 비산(Entrainment) 및 플러딩(Flooding) 방지 +* **개념:** 탑 내부의 증기 유속이 임계치를 넘으면 하부의 무거운 불순물(금속, 고분자 중합물)이 기류를 타고 튀어 올라와 제품을 오염시킵니다. +* **조치:** 제품 추출단 하부에 데미스터(Demister) 등 물리적 차단 장치를 점검하고, 탑 내부 차압(Delta P)을 모니터링하여 상한선을 엄격히 통제해야 합니다. diff --git a/측류추출-관계식.md b/측류추출-관계식.md new file mode 100644 index 0000000..63f7575 --- /dev/null +++ b/측류추출-관계식.md @@ -0,0 +1,100 @@ +# 반도체 신너(PGMEA) 측류 추출 운전 - 전방먹임 비례 제어(Feedforward Ratio Control) 관계식 + +본 문서는 실제 석유화학 및 반도체 소재 공장의 DCS(분산제어시스템)나 APC(고급공정제어)에서 사용하는 '전방먹임 비례 제어(Feedforward Ratio Control)' 모델의 핵심 공식을 물질수지(Material Balance)와 열수지(Energy Balance) 관점에서 정리한 자료입니다. + +--- + +## 0. 기호 정의 (Variables) + +관계식의 명확성을 위해 다음과 같이 변수를 정의합니다. (단위: kg/h 또는 ton/h) + +* F : 원료 투입량 (Feed) +* D : 탑 상부 제거량 (Distillate / Light Purge) +* B : 탑 하부 제거량 (Bottom / Heavy Blowdown) +* P : 탑 중간 제품 추출량 (Side Product) +* R : 탑 상부 환류량 (Reflux) +* S : 리보일러 스팀 공급량 (Steam) + +--- + +## 1. 총 물질수지 관계식 (Total Material Balance) + +증류탑으로 유입되는 총 질량과 유출되는 총 질량은 같아야 한다는 기본 법칙입니다. + +F = D + P + B + +이를 원료 투입량(F) 기준으로 제어하기 위해 각각의 **추출 비율 계수(K)**를 도입하여 DCS 제어식을 도출합니다. + +* K_D : 원료 대비 상부 제거 비율 (D/F) +* K_P : 원료 대비 제품 수율 (P/F) +* K_B : 원료 대비 하부 제거 비율 (B/F) + +### [DCS 제어 설정식] + +D = K_D × F +P = K_P × F +B = K_B × F + +> 💡 **추출 비율 계수(K) 산정 팁:** +> 원료(Feed) 내의 불순물 분석 데이터에 따라 결정됩니다. 예를 들어 원료 내 경비물(수분 등)이 1%, 중비물이 1%이고 목표 PGMEA 회수율이 98%라면, K_D = 0.01, K_B = 0.01, K_P = 0.98로 초기 세팅 후 품질을 보며 미세 조정합니다. (단, K_D + K_P + K_B = 1을 만족해야 합니다.) + +--- + +## 2. 환류량(Reflux) 관계식 + +환류량(R)은 상부 제거량(D)과 연동하며, 기-액 평형 조건을 유지하기 위한 **설계 환류비(R_f = R/D)**를 이용합니다. + +R = R_f × D + +위의 물질수지 제어식(D = K_D × F)을 대입하여, 최종적으로 원료 투입량(F)에 대한 관계식으로 풀면 다음과 같습니다. + +### [DCS 제어 설정식] + +R = R_f × K_D × F + +* 원료 투입량이 변하면 상부로 나가는 가스/액체 유량도 변하므로, 이에 비례하여 환류량(R)도 자동으로 조절되도록 로직을 구성합니다. + +--- + +## 3. 스팀량(Steam) 관계식 + +스팀량(S)은 탑 내부에서 끓어 올라가야 하는 **총 증기량(V, Vapor Load)**과 직결됩니다. +PGMEA를 액체(Liquid) 상태로 측류 추출한다고 가정할 때, 탑 상부로 올라가는 대략적인 필요 증기량은 다음과 같습니다. + +V ≈ R + D + +리보일러 스팀 공급량(S)은 이 증기량(V)을 만드는 데 필요한 잠열을 공급해야 하므로, 스팀-증기 비례 상수(α)를 적용합니다. + +S = α × V = α × (R + D) + +이 식에 앞서 구한 R과 D의 제어식을 대입하면, 최종적으로 **원료 투입량(F) 기준의 스팀량 공식**이 완성됩니다. + +S = α × (R_f × K_D × F + K_D × F) = α × K_D × (R_f + 1) × F + +상수들을 하나로 묶어 **K_S (스팀/피드 비례 계수)**로 단순화하면 DCS 식은 매우 간결해집니다. + +### [DCS 제어 설정식] + +S = K_S × F + +--- + +## 4. DCS 실제 적용을 위한 최종 로직 요약 + +실제 공장 제어실(DCS)에 알고리즘을 구현할 때는 원료 유량 계측기(FT)의 값을 실시간으로 받아 각 제어 밸브의 유량 설정치(SV)를 아래와 같이 자동 계산(Feedforward Ratio)하도록 연동합니다. + +1. **상부 Purge 밸브 설정치 (Distillate SV):** D_SV = K_D × F +2. **중간 제품 밸브 설정치 (Side Product SV):** P_SV = K_P × F +3. **하부 Blowdown 밸브 설정치 (Bottom SV):** B_SV = K_B × F +4. **상부 환류 밸브 설정치 (Reflux SV):** R_SV = R_f × D +5. **리보일러 스팀 밸브 설정치 (Steam SV):** S_SV = K_S × F + f(ΔP) + Bias + +--- + +## ⚠️ 현업 운전 시 필독 주의점 (Bias의 필요성) + +이론적인 비례 관계식은 위와 같으나, 실제 현장에서는 **탑 자체의 열손실(Heat Loss), 외기 온도 변화, 계측기 오차, 원료 공급 온도의 미세한 흔들림**이 발생합니다. + +따라서 DCS 로직을 설계할 때는 완전 비례식만 적용하기보다, 운전원이 공정 상태를 보며 미세 조정할 수 있도록 **보정값(Bias)** 튜닝 탭을 반드시 확보해야 합니다. + +특히 스팀 제어의 경우, 앞서 언급한 **탑 내부 차압[f(ΔP)]에 따른 감쇄(Override) 제어 알고리즘**을 상기 스팀 설정식에 더하여(Cascade/Override 구조) 안전성을 이중으로 확보해야 합니다. diff --git a/측류추출-시간지연-적용방식.md b/측류추출-시간지연-적용방식.md index 4b596c6..b633139 100644 --- a/측류추출-시간지연-적용방식.md +++ b/측류추출-시간지연-적용방식.md @@ -153,7 +153,7 @@ DCS 로직을 수정하실 수 있다면 **[1번 대책: 5분짜리 시상수를 │ ▼ ┌─────────────────────┐ -│ Filter Block (300초) │ +│ Filter Block (300초)│ └─────────┬───────────┘ │ ▼ @@ -161,7 +161,7 @@ DCS 로직을 수정하실 수 있다면 **[1번 대책: 5분짜리 시상수를 │ ▼ ┌─────────────────────┐ -│ 각종 밸브 연동 공식 │ +│ 각종 밸브 연동 공식 │ └─────────────────────┘ ``` diff --git a/측류추출-자동운전-플랜-byOpus.md b/측류추출-자동운전-플랜-byOpus.md new file mode 100644 index 0000000..6a1c046 --- /dev/null +++ b/측류추출-자동운전-플랜-byOpus.md @@ -0,0 +1,251 @@ +# 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜 + +> **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서 +> 구현하되, **운전원이 단계적으로 신뢰를 쌓아 권한을 넘기는** 감독제어(Supervisory Control) 형태의 +> 자동운전을 설계한다. 결정론 엔진이 제어하고, 로컬 LLM(vLLM Qwen)은 그 위에서 진단·예외·인터페이스를 맡는다. +> +> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의 완료본. 코드 미작성 상태. + +*작성일: 2026-05-22 / 갱신: 2026-05-22 (논의 합의 반영) / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + +--- + +## 0. 핵심 원칙 + +**LLM을 빠른 제어 루프에 넣지 않는다.** 빠른 보상은 결정론 엔진(코드)이, LLM은 분/이벤트 단위 진단·튜닝·인터페이스만. + +| 문제 | 영향 | +|------|------| +| 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 | +| 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 | +| 환각 | 잘못된 값 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 | + +따름정리: **헌팅 검출·MAN 전환·OP 산출 등 안전·실시간 판단은 모두 결정론.** LLM은 그 트립을 *설명*하고 +*원인을 진단*할 뿐, 직접 트립시키거나 OP를 쓰지 않는다. + +--- + +## 1. 물리 결정론 vs LLM — 역할 경계 (이 플랜의 출발점) + +운영자가 **밸브 사이즈·배관 종류·컨트롤밸브 Cv 값/Cv 커브·플로우미터 유량범위** 등 물리 데이터를 +보유하면, 제어 수학의 상당 부분이 *데이터 피팅 없이 계산*된다. + +### 1.1 물리 데이터로 결정론화되는 것 (LLM 불필요) +| 물리 데이터 | 계산되는 모델 | +|------------|--------------| +| Cv 커브(설치특성) | OP(%) → 유량 관계, 밸브 게인 dQ/dOP | +| 배관 종류·구경·길이 | ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 | +| 드럼/트레이 홀드업 체적 | 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) | +| 플로우미터 레인지 | 스케일링·분해능·노이즈 플로어 | + +→ 자동운전의 **B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업(=체적/유량)으로 직접 계산**된다. +밸브 게인도 Cv 커브 미분으로 나온다. **이 부분은 그냥 프로그램한다.** + +### 1.2 물리 데이터가 못 주는 것 +- **(가) 분리/조성 동특성** — P(측류)의 "15~20분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(VLE)으로 + 새 조성이 자리잡는 시간. 상대휘발도·트레이 효율·VLE는 Cv 커브에 없음. → **B·D는 물리로 계산되지만 P는 별도 모델 필요.** +- **(나) 모델-플랜트 불일치(드리프트)** — Cv 커브는 신품 설계값. 밸브 stiction·마모, E-6103 파울링, 트레이 효율 저하로 시간에 따라 어긋남. +- **(다) 목적·맥락·예외** — 회수율 최대 vs 에너지 최소 vs 순도 사수, 등급변경, 기동/정지, 계기고장, 상류 외란. + +### 1.3 따라서 LLM이 실제로 하는 일 +> **LLM의 가치는 물리모델 품질에 반비례.** 물리를 잘 잡을수록 LLM은 제어 산수에서 빠지고 가장자리로 이동. + +| LLM 역할 | 구체 | 가치 | +|---------|------|------| +| ① 커미셔닝 보조 | 밸브 데이터시트·Cv 커브·배관 스펙 파싱 → 엔진 config/코드로 조립, 정합성 점검 | ★★ | +| ② 드리프트 진단((나)) | 물리예측 vs 실측 잔차는 수학, *"이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심"* 해석·재교정 트리거는 LLM | ★★ | +| ③ 소프트센서 보조((가)) | 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 | ★ | +| ④ 감독형 예외 처리((다)) | 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장) 판단·완화 | ★★★ | +| ⑤ 운전원 인터페이스 | 의도/경제목표 → SV·제약 번역, "왜 이렇게 도는지" 설명 | ★★★ | +| ⑥ 교차 데이터 융합 | 알람+이벤트+랩분석+정비이력+물리잔차 엮어 진단 (기존 MCP 도구) | ★★★ | +| ⑦ 헌팅 원인 진단 | 튜닝 vs stiction vs 외란 판별 → 4단계(OP 개입) 적용 여부 게이트 (§4.3) | ★★★ | + +--- + +## 2. 감독제어 아키텍처 — 운전원이 권한을 쥔다 + +핵심 설계 사상: **엔진은 PID 루프의 SP/OP 레지스터를 직접 덮어쓰지 않는다.** 별도 감독변수에 쓰고, +**운전원이 스위치로 채택**한다. 권한 손잡이는 항상 운전원에게 있다. SP 경로와 OP 경로가 대칭이다. + +| | SP 경로 (평상시) | OP 경로 (헌팅 시) | +|---|------------------|-------------------| +| 엔진이 쓰는 곳 | RSP 소스 포인트 (별도 변수) | `.op` (PID MAN 상태에서) | +| 운전원 스위치 | **LSP ↔ RSP** (Local ↔ Remote SP = AUTO↔CAS) | **PID MODE: AUTO ↔ MAN** | +| 빠른 규제 담당 | DCS PID (그대로 둠) | 엔진(소프트웨어 컨트롤러) | +| 폴백(엔진 사망) | 운전원이 LSP로 토글 | 데드맨 → MAN→AUTO (bumpless) | +| 적용 | 1~3단계 (신뢰 이양) | 4단계 (튜닝발 헌팅 한정) | + +### 2.1 SP 경로 — RSP(Remote Setpoint) +- 엔진은 **루프 SP를 절대 안 건드림.** 자기 감독소스 포인트에만 OPC write → 그 포인트가 PID의 RSP/X 입력에 control connection. +- 운전원의 **LSP/RSP 토글이 유일한 권한 손잡이.** RSP면 엔진 SP 추종, LSP면 운전원 수동 — 언제든 가역. +- **bumpless 요건(중요)**: OPC 외부 감독은 DCS의 back-calculation 핸드셰이크를 못 받음. + → 루프가 LSP(미선택)일 때 엔진이 **현재 실작동 SP를 읽어 자기 출력=현재 SP로 추종**시켜야 함. + 그래야 운전원이 RSP로 토글하는 순간 충격 없음. +- **공짜 안전망**: DCS RSP 한계(SPHILM/SPLOLM, RSP rate)가 엔진과 독립으로 한 겹 더. +- **장점**: 1~2단계(제안 표시)는 페이스플레이트가 RSP 후보값을 네이티브로 보여줌 → **별도 화면 개발 불필요.** + +### 2.2 OP 경로 — MAN + OP 쓰기 (튜닝발 헌팅 전용) +- 평상시 RSP로는 **튜닝발 헌팅이 안 잡힘**(PID가 루프에 그대로). 그래서 헌팅 루프에 한해 OP를 직접 잡는다. +- 방식: PID를 **MAN**으로 → 엔진이 `.op`에 직접 write. **MAN이라 적분이 멈춰 windup 없음, OP 쓰기는 본질적 bumpless.** + 기존 `ControlOp`(MD→MAN→OP쓰기) / `WriteTagAsync(.op)` 그대로 사용 → **신규 DCS 구성 불필요, 저MoC.** +- **운전원 회수**: MAN의 OP는 엔진이 쓴 마지막 값 → 운전원이 그 값에서 이어 조정, 또는 AUTO로 올림. +- **폴백(엔진 사망)**: 엔진 워치독 + **DCS 컨트롤러 로직이 stale(N초 갱신 없음) 감지 → MAN→AUTO 강제 복귀.** + PID가 bumpless output 설정이라 **현재 OP(=마지막 LLM_OP)에서 적분 임펄스 없이 규제 재개.** + - *정직한 단서*: 폴백은 "헌팅하던 그 PID"로 돌아감 → 안전(규제됨, SIS가 극단 차단)하나 **엔진 복구 전까지 헌팅 재개.** 위험 아님, 차선. + - 설정 확인: MAN 중 SP 추종/홀드 → 폴백 후 어떤 LSP로 규제할지 결정. +- **상위 옵션(임계 루프 한정)**: *순간 규제 공백도 불가*한 빠른 루프는 선택+back-calc(PID는 AUTO 추종 유지, 무충격 즉시 폴백)을 쓰되, 밸브 출력경로를 변형하므로 MoC가 더 엄격. 기본값은 위 MAN 방식. + +--- + +## 3. LLM-OP 모드의 제어법 — FF + 느린 PI (rate 제한) + +OP 경로로 개입한 동안 엔진이 매 순간 OP에 무엇을 쓰는가. **크루즈컨트롤과 동일 구조**: 미리 예측(FF) + 잔차 청소(PI). + +``` +F(헌팅) ─Lag필터→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐ + ├→ OP → rate제한 → 절대/변동폭 클램프 → 밸브 +설정값 − 실측PV ───────────────── 느린 PI ───────→ OP_pi ┘ +``` + +- **FF (피드포워드)**: 물리로 *미리* 정답 개도 계산. `개도% = Cv⁻¹( Q / √(ΔP/SG) )`. + 필터링된 F_clean로 목표유량(B/D/P)을 물질수지로 구하고 → Cv 커브로 OP 계산 → §5 시간상수로 부드럽게 이동. + **외란발 헌팅을 잡는 주역**(반응이 아니라 예측이라 밸브가 안 채인다). +- **PI (느린 피드백)**: Cv 커브는 신품값이라 마모·파울링·ΔP 부정확으로 살짝 빗나감. 잔차(SP−PV)를 + **느리게/약하게** 보정. 약한 이유: ①헌팅 재유발 방지 ②큰 일은 FF가 이미 함. +- **rate 제한**: OP 변화율 제한으로 밸브 부드럽게. +- **비채택: "고정+간헐 보정"** — 보정 사이 능동 규제 0 → 외란 시 PV 드리프트(피드백 상실). 사용 안 함. +- **연결**: FF = §5 결정론 보상 엔진 그대로 + 그 위에 작은 PI 트림 하나. + +--- + +## 4. 헌팅 검출 & 원인 진단 — 4단계의 게이트 + +### 4.1 검출 (결정론) +- 오실레이션 인덱스: 진폭·주기·지속성. 임계 초과(예: 진폭 > 범위의 X%, 주기 안정, N분 지속) 시 트립. +- **MAN 전환 트립은 결정론**(LLM 지연 불가). LLM은 트립을 설명만. + +### 4.2 원인 분류 (LLM + 데이터 융합) — §1.3-⑦ +| 원인 | 4단계(MAN+OP)로 잡히나 | 조치 | +|------|----------------------|------| +| 튜닝 과민 | ✅ 즉시 | MAN 전환 → FF+PI로 OP 핸드홀딩 | +| 상류 외란 | ✅ 잘 잡힘 | 동일(FF가 주역) | +| 루프 간섭 | ⚠️ 부분 | 시차 조절로 완화 | +| **밸브 stiction** | ❌ 악화 | **정비 플래그.** OP 핸드홀딩 금지(마모만 늘어남) | + +→ LLM이 OP-PV 위상·한계주기 파형·상류 신호·정비이력을 엮어 *"이건 stiction → 4단계 말고 정비"* vs +*"외란 → 4단계 유효"* 판정. **초기엔 LLM 진단 → 운전원 확인 권장.** + +--- + +## 5. 보상 제어 수식 (결정론, FF의 본체) + +원본 문서 §2·§4 기준. +- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])` +- **데드타임**: 링버퍼로 N틱 지연 +- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** (원본 §4.1) + +| MV | 제어 대상 | τ / 데드타임 | 근거 | 목적 | +|----|----------|-------------|------|------| +| B | 하부 제거량 | 1~2분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 | +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 | +| P | 측류 제품 추출 | 15~20분 | **분리/조성 동특성(§1.2-가, 별도 모델)** | 초고순도 PGMEA 품질 보호 | +| S | 리보일러 스팀 | 가장 빠름 | 압력 즉시 전달 | 하부 온도 직결 | + +추가(원본 §4.2/§4.3): PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑). + +--- + +## 6. 안전 봉투 (Safety Envelope) + +엔진의 모든 쓰기는 아래를 강제 통과한다(다층 독립 방어): + +1. **엔진 가드**: rate 제한 · 절대 min/max · **현재 유량범위 대비 밸브 변동폭 제한** · 태그 화이트리스트 · 전 쓰기 감사로그 +2. **DCS 측 한계**: RSP 한계(SPHILM/SPLOLM), 출력 한계(OPHILM/OPLOLM) — 엔진과 독립 +3. **운전원 스위치**: LSP/RSP, AUTO/MAN — 언제든 즉시 회수 (최우선) +4. **데드맨/워치독**: 엔진 stale → SP경로는 운전원 LSP 회수, OP경로는 DCS 로직이 MAN→AUTO(bumpless) 폴백 +5. **ESD/IL/SIS 독립**: BPCS 루프의 MAN/AUTO·LSP/RSP와 무관하게 최종요소에 독립 동작 → 실험을 봉인된 안전 범위에 묶음 +6. **한 번에 한 루프**: 간섭 루프 동시 MAN 금지 +7. **양방향 bumpless**: 모든 전환에서 충격 없음(PID bumpless output + 엔진 추종) + +> ⚠️ **MoC/문화**: 자동 시스템이 SP/OP를 조작하는 것은 현장에서 APC로 간주 → 변경관리·운전원 수용 절차 필요(기술 외 항목). + +--- + +## 7. 단계별 신뢰 이양 로드맵 (운전원 비전) + +| 단계 | 내용 | 경로 | 권한 | +|------|------|------|------| +| **1. 제안 표시** | 엔진이 RSP 소스 포인트에 계산값 write → 운전원이 페이스플레이트에서 "제안 SP"를 봄(LSP 유지) | SP/RSP | 운전원 100% | +| **2. 관찰·신뢰 형성** | 제안값이 합리적인지 운전원이 일정 기간 관찰 | SP/RSP | 운전원 100% | +| **3. SP 주도권 이양** | 신뢰 시 운전원이 **RSP로 토글** → 엔진 SP 추종. 언제든 LSP 회수 | SP/RSP | 엔진(가역) | +| **4. 헌팅 자동 안정화** | 헌팅 임계 초과 + 원인=튜닝/외란 확인 시 PID MAN 전환 → FF+PI로 OP 핸드홀딩 → 안정 후 복귀 | OP/MAN | 엔진(데드맨 폴백) | + +**구현 선행조건(Phase 0)**: §6-1 엔진 가드 레이어 + 데드맨. *(현재 쓰기 경로에 가드 0건 — §10 참조.)* + +--- + +## 8. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections`) + +원료 경로(trace_connections): +``` +P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 +``` + +| # | 경로 | MV/제어 | 유량 | 온도 | 수위/압력 | τ | +|---|------|---------|------|------|----------|---| +| **F** | 원료 투입 | **FICQ-6101**→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력(Lag 300s) | +| **S** | 리보일러 스팀 | 스팀밸브 | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름 | +| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1~2분 | +| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), LICA-6113, PI-6111(진공), PICA-6111 | 5분 | +| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) | 15~20분 | + +- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1). + ※ SP 경로 구현 시 write 타깃은 **루프 SP가 아니라 RSP 소스 포인트**로 바뀜(노드 ID만 교체, 쓰기 코드 동일). +- 현재 운전 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종, 진공압 PICA-6111 30.4 → 가동 중 추정. + +### 8.1 미완료 매핑 (담당 구분) +- **P(측류 제품 추출) 경로 매핑 — 사용자 직접 진행 예정** (본 플랜 보류) +- B(하부) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 C-6111 `trace_connections downstream`로 보강 + +--- + +## 9. 현 시스템 재사용 자산 + +| 구분 | 자산 | +|------|------| +| 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(.sp/.op)`, `SetModeAsync(MAN/AUTO)`, `ControlOp`(MD→MAN→OP→AUTO) / `POST /api/experion/{write,mode,control}` / UI "OPC UA Write" 탭 | +| 읽기 | `ExperionRealtimeService`(실시간 PV 구독, IHostedService), `query_pv_history`(MCP)/`ExperionHistoryController` | +| 백그라운드 | `IHostedService`/`AddHostedService` 패턴 기존 사용 → 신규 `AutoRunService : BackgroundService` 그대로 적용 | +| LLM 감독 | `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, `summarize_events`, `generate_status_report`, ReAct 에이전트 모드 | + +--- + +## 10. 미해결/확인 필요 항목 + +- [ ] **P(측류 제품 추출) 경로 매핑** — *사용자 직접 진행* +- [ ] B(하부) 발출 유량계·밸브 태그 확정 +- [ ] **쓰기 경로 안전 가드(§6-1) 신규 구현** — 현재 `WriteTagAsync`에 클램프/rate/변동폭 0건 (Phase 0 선행) +- [ ] **DCS 구성**: RSP 소스 포인트 생성·연결, OP 데드맨(stale→MAN→AUTO) 로직, RSP 추종/홀드 설정 +- [ ] 헌팅 임계 정의(진폭/주기/지속) 및 stiction 자동판별 신뢰 수준 +- [ ] 각 MV의 hard min/max·변화율·밸브 변동폭 한계(공정 안전 범위) + Cv 커브·배관 물리 데이터 수집 형태 +- [ ] P(측류) 분리/조성 모델(§1.2-가) 깊이 결정: 고정 τ vs 간이 트레이모델 vs 경험모델 +- [ ] `ask_iiot_llm`(vLLM) 빈 응답 — vLLM 엔드포인트 상태 점검 +- [ ] Step Test 수행 가능 시점/조건 (가동 중 5~10% 스텝) +- [ ] APC 블록 내장 여부 vs 일반 PID 환경 / MoC 절차 + +--- + +## 부록 A. 참조 +- 원본 개념 문서: `측류추출-시간지연-적용방식.md` +- 쓰기 구현: `src/Infrastructure/OpcUa/ExperionOpcWriteClient.cs`, `src/Web/Controllers/ExperionControllers.cs`(ExperionWriteController) +- 실시간 읽기: `src/Infrastructure/OpcUa/ExperionRealtimeService.cs` +- UI: `src/Web/wwwroot/index.html` (#pane-write) +- MCP 도구: `mcp-server/server.py` (find_tags, trace_connections, query_pv_history, ask_iiot_llm 등) + +## 부록 B. 합의된 핵심 결정 (요약) +1. 감독제어 — 엔진은 별도 변수에만 쓰고 운전원이 스위치로 채택(권한은 운전원). +2. SP는 **RSP** 경로(LSP/RSP 토글), 외부 추종으로 bumpless. +3. OP는 **MAN+`.op` 쓰기** 경로(기존 ControlOp), 엔진 워치독 + **DCS 데드맨→MAN→AUTO bumpless** 폴백. +4. OP 제어법은 **물리 FF(Cv·배관) + 느린 PI + rate제한** (고정+간헐 보정 비채택). +5. PID 파라미터 재튜닝은 **필수 아님** — MAN에서 OP 대체로 헌팅 안정화 가능(stiction 제외). +6. LLM은 물리 결정론 위에서 ①커미셔닝 ②드리프트진단 ③소프트센서 ④예외처리 ⑤인터페이스 ⑥교차융합 ⑦헌팅원인진단. diff --git a/측류추출-자동운전-플랜-컨셉회의.docx b/측류추출-자동운전-플랜-컨셉회의.docx new file mode 100644 index 0000000..39dacb5 Binary files /dev/null and b/측류추출-자동운전-플랜-컨셉회의.docx differ diff --git a/측류추출-자동운전-플랜-컨셉회의.md b/측류추출-자동운전-플랜-컨셉회의.md new file mode 100644 index 0000000..06eb3dd --- /dev/null +++ b/측류추출-자동운전-플랜-컨셉회의.md @@ -0,0 +1,2774 @@ + + + ▐▛███▜▌ Claude Code v2.1.143 +▝▜█████▛▘ Opus 4.7 · Claude Pro + ▘▘ ▝▝ ~/projects/ExperionCrawler + + +❯ 측류추출-시간지연-적용방식.md 을 읽고, 이걸 로컬 LLM에서 자동운전 할 수 있는 방법을 제시해줘 + +● 파일을 먼저 찾아서 읽어보겠습니다. + + Searched for 1 pattern, read 1 file (ctrl+o to expand) + +● 문서를 읽었습니다. 이제 이 시스템이 실제로 무엇을 할 수 있는지(특히 DCS 쓰기/제어 능력이 있는지) 파악해서 현실적인 + 자동운전 방안을 제시하겠습니다. 기존 MCP 도구와 아키텍처를 빠르게 확인하겠습니다. + + Searched for 2 patterns (ctrl+o to expand) + +● Bash(grep -nA2 "@mcp.tool" mcp-server/server.py | grep -E "^.*def " | sed -E 's/.*def ([a-zA-Z0-9_]+).*/\1/' | sort | + tr '\n' ' '; echo; echo "=== query_pv_history s…) + ⎿  active_alarms analyze_pid_impact ask_iiot_llm build_pid_graph_parallel classify_intent extract_pid_tags find_t + ags generate_status_report get_tag_metadata infer_field_instruments list_drawings match_pid_tags parse_documen + t parse_pid_drawing parse_pid_dxf parse_pid_pdf query_events query_pv_history query_with_nl rag_query run_sql + … +18 lines (ctrl+o to expand) + +● 문서와 코드베이스를 다 확인했습니다. 핵심 사실부터 정리하면: + + - 이 문서의 방법 A/B(데드타임 블록, 1차 지연 필터, 무빙애버리지)는 결정론적 제어 수학입니다 — 매 스캔(약 1초)마다 도는 + PID/필터 로직. + - 현재 ExperionCrawler MCP 도구는 전부 읽기 전용입니다 (query_pv_history, get_tag_metadata, active_alarms, + query_events, run_sql …). 밸브/SV 쓰기, OPC write, 셋포인트 명령 도구는 하나도 없습니다. + + 이 두 사실이 "로컬 LLM 자동운전"의 설계를 결정합니다. + + --- + 0. 가장 중요한 원칙 — LLM을 제어 루프에 넣지 마세요 + + 문서가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야 하는 빠른 루프입니다. 여기에 LLM을 직접 + 넣으면: + + - 비결정성 — 같은 입력에 다른 출력. 밸브 제어엔 치명적. + - 지연(latency) — 토큰 생성 수 초. 탑 넘침(Flooding) 방지 같은 즉시 대응 불가. + - 환각 — 잘못된 SV 한 번이 측류 순도 영역을 파괴. + + → 결론: 빠른 보상 로직은 코드(결정론 엔진)가, LLM은 그 위의 감독·조언·튜닝(분 단위/이벤트 단위) 만 맡습니다. 이게 + 업계에서 LLM을 공정에 붙이는 유일하게 안전한 형태입니다. + + --- + 1. 2-Plane 아키텍처 + + ┌─────────────────────────────────────────────────────────────┐ + │ Plane 2: 인지/감독 (LLM, 분~이벤트 단위, 느림) │ + │ - Step Test 곡선 분석 → θ(데드타임)·τ 자동 추출 │ + │ - 파라미터(K, τ) 튜닝 제안 │ + │ - 헌팅/Flooding/순도드리프트 이상 감지 + 운전원 설명 │ + │ - "왜 제품밸브가 천천히 열려요?" 운전원 Q&A │ + │ │ (파라미터/권고만 전달, 직접 밸브 X) │ + │ ▼ │ + │ ┌──────────────────── 안전 게이트 ─────────────────────┐ │ + │ │ Hard min/max clamp · rate limit · dead band · 감사로그│ │ + │ └──────────────────────────┬───────────────────────────┘ │ + ├─────────────────────────────┼───────────────────────────────┤ + │ Plane 1: 결정론 보상 엔진 (코드, 초 단위, 빠름) │ + │ F_raw → [Lag τ=300s 필터] → F_clean │ + │ ├─ B_sv = K_B × deadtime(F_clean, 1~2분) │ + │ ├─ D_sv = K_D × lag(F_clean, 5분) │ + │ └─ P_sv = K_P × lag(F_clean, 15~20분) │ + └─────────────────────────────────────────────────────────────┘ + │ + 읽기: query_pv_history (현 시스템 OK) + 쓰기: OPC write (Phase B에서 신규 — 현재 없음) + + Plane 1은 LLM이 아니라 순수 수학입니다. 1차 지연은 y[k] = y[k-1] + (Δt/τ)(x[k]-y[k-1]), 데드타임은 링버퍼 한 줄. + 파이썬/C# 어느 쪽이든 수십 줄. + + --- + 2. 현 시스템에 매핑 — 지금 코드로 "당장 가능한 것" + + 현 시스템이 읽기 전용이므로, 밸브를 직접 안 여는 "조언형 자동운전(Advisory)" 이 즉시 구현 가능합니다: + + ┌───────────────────────┬───────────────────────────────────────────────┬──────────────────────┐ + │ 기능 │ 사용하는 기존 도구 │ 신규 필요 │ + ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤ + │ 원료 유량 읽기·필터링 │ query_pv_history(["ficq-6113.pv"]) │ 필터 계산기 │ + ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤ + │ 권고 SV 계산·표시 │ (위 + 메타데이터) │ 보상 엔진(읽기 전용) │ + ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤ + │ Step Test 곡선 분석 │ query_pv_history(온도/수위/분석기) │ LLM 분석 프롬프트 │ + ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤ + │ 이상 감지·설명 │ active_alarms, query_events, summarize_events │ 에이전트 루프 │ + ├───────────────────────┼───────────────────────────────────────────────┼──────────────────────┤ + │ 운전원 Q&A │ 기존 채팅 + ReAct 에이전트 모드(이미 있음) │ 시스템 프롬프트 │ + └───────────────────────┴───────────────────────────────────────────────┴──────────────────────┘ + + 즉 Plane 2 전체와 Plane 1의 "계산·표시" 는 지금 코드 위에서 만들 수 있고, 운전원이 권고값을 보고 손으로 적용합니다. + DCS 쓰기 없이 안전. + + --- + 3. LLM이 진짜 잘하는 4가지 역할 + + 1. Step Test 분석 (강력 추천) — 문서 §3의 그 작업. 유량 스텝 후 하부온도/상부온도/환류드럼수위/측류 Analyzer 곡선을 + query_pv_history로 뽑아 LLM에 주면 각 구간의 데드타임 θ와 τ를 읽어냅니다. (결정론적 곡선 피팅으로 교차검증) → 그 값이 + Plane 1 파라미터가 됩니다. + 2. 파라미터 튜닝 조언 — 처리량·원료 조성이 드리프트할 때 K·τ 재조정 제안. + 3. 이상 상황 서술 — "FT 헌팅이 5분째 ±5% 지속, 필터 τ를 300→420초 권장" 같은 자연어 진단. + 4. 운전원 코칭 — 신입 운전원에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명. + + --- + 4. 단계별 로드맵 + + - Phase A — 조언형 (현 코드로 가능, 위험 0): 보상 엔진(읽기 전용) + 권고 SV 대시보드 + LLM Step Test 분석기. DCS 쓰기 + 없음, 운전원 수동 적용. + - Phase B — 감독형 폐루프: OPC 쓰기 채널 신규 추가(가장 큰 작업·안전심사 필요). Plane 1이 SV를 직접 쓰되 하드 클램프 + 안에서만. LLM은 여전히 밸브 직접 X — 파라미터만 제안하고 변경은 운전원 승인. + - Phase C — 자가 튜닝: LLM이 Step Test 시점을 제안 → 자동 피팅 → 시뮬레이터에서 A/B 검증 후 반영. (현 브랜치가 sim/... + 이므로 디지털 트윈으로 실플랜트 전에 검증 권장) + + --- + 5. 안전 가드 (Phase B 이상 필수) + + - Plane 1의 하드 min/max·rate limit·dead band는 LLM 출력과 무관하게 항상 강제. + - LLM 권고는 기본 "표시", 자동 적용 경로는 별도 게이트 + 전 변경 감사 로그. + - 통신 두절/이상 시 마지막 안전 SV로 폴백. + + --- + 핵심은 "LLM이 운전하는" 게 아니라 "결정론 엔진이 운전하고 LLM이 감독·튜닝한다" 입니다. 그래야 안전하면서도 LLM의 + 가치(Step Test 해석, 적응 튜닝, 운전원 보조)를 다 살립니다. + + 어디까지 진행할지에 따라 다음 작업이 달라져서 한 가지만 확인하겠습니다. + +● User declined to answer questions + ⎿  · 어느 범위부터 실제로 구현해 드릴까요? (Phase A 조언형부터 / Step Test 분석기만 먼저 / 결정론 보상 엔진 코드만 / + 설계 문서만 작성) + +● 무엇을 명확히 하고 싶으신가요? 위 제안 중 궁금하거나 다르게 가져가고 싶은 부분을 말씀해 주세요. + + 몇 가지 짚어볼 만한 지점을 미리 적어두면: + + - "자동운전"의 의미 — (a) 증류탑이 원료 변화에 스스로 보상하며 도는 것(=결정론 엔진이 운전, LLM 감독)인지, 아니면 (b) + LLM이 운전원처럼 자율 판단·조치하는 것(=ReAct 에이전트)을 원하시는지. 제 제안은 (a)를 중심에 뒀습니다. + - 실제 DCS 쓰기 가능 여부 — 현 시스템은 읽기 전용이라 폐루프(밸브 직접 조작)는 OPC 쓰기 채널 신설 + 안전 심사가 + 전제입니다. 실제 Experion에 쓰기 접근이 가능한 환경인지. + - 대상 범위 — 이 측류추출 증류탑 한 기에 한정인지, 일반화 가능한 프레임워크로 만들 것인지. + - 검증 환경 — 현 브랜치가 sim/... 인데, 실플랜트 전에 시뮬레이터/디지털 트윈으로 먼저 검증할 생각이신지. + + 어떤 점을 더 풀어서 다룰지, 또는 위 범위 질문 자체를 어떻게 바꾸면 좋을지 알려주세요. + +✻ Worked for 2m 21s + +❯ 이미 쓰기 기능은 추가되어 있어, UI OPC UA Write 탭을 살펴봐 + +● 쓰기 기능이 이미 있군요. 확인하겠습니다. + + Searched for 2 patterns, read 2 files (ctrl+o to expand) + +● 쓰기 채널이 실제로 있군요. 컨트롤러와 통합 제어 시퀀스, 그리고 안전 가드 유무를 확인하겠습니다. + + Searched for 2 patterns (ctrl+o to expand) + +● 핵심을 파악했습니다. 쓰기 채널이 실제로 다 갖춰져 있네요. 마지막으로 백그라운드 서비스 패턴과 안전 가드 유무만 + 확인하겠습니다. + +● Bash(cd /home/windpacer/projects/ExperionCrawler; echo "=== ControlOpRequest fields ==="; sed -n '1385,1410p' + src/Web/Controllers/ExperionControllers.cs; echo "=== B…) + ⎿  === ControlOpRequest fields === + public class ControlOpRequest + { + … +25 lines (ctrl+o to expand) + +● 확인 완료했습니다. 제가 처음에 "읽기 전용"이라고 한 건 틀렸고, 정정합니다. 쓰기 채널이 온전히 갖춰져 있습니다. + + 실제로 있는 쓰기 능력 + + ┌────────────────────────────────┬─────────────────────────────────────────────────────┬──────────────────────────┐ + │ 기능 │ 구현 │ 엔드포인트 │ + ├────────────────────────────────┼─────────────────────────────────────────────────────┼──────────────────────────┤ + │ SP/OP 직접 쓰기 │ ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, │ POST /api/experion/write │ + │ │ value) │ │ + ├────────────────────────────────┼─────────────────────────────────────────────────────┼──────────────────────────┤ + │ MAN/AUTO 모드 변경 │ SetModeAsync(cfg, nodeId, "MAN"|"AUTO") │ POST /api/experion/mode │ + ├────────────────────────────────┼─────────────────────────────────────────────────────┼──────────────────────────┤ + │ 통합 제어 (MD→MAN → OP 쓰기 → │ ControlOp(TagName, OpValue, RestoreAuto) │ POST │ + │ AUTO 복귀) │ │ /api/experion/control │ + └────────────────────────────────┴─────────────────────────────────────────────────────┴──────────────────────────┘ + + 게다가 백그라운드 서비스 패턴(IHostedService/AddHostedService)도 이미 Realtime·History·OpcServer·Mcp에서 쓰고 있고, + 실시간 PV 구독(ExperionRealtimeService.AddMonitoredItemAsync)도 있습니다. 즉, 폐루프 자동운전이 신규 인프라 없이 기존 + 코드 위에서 실제로 구현 가능합니다. + + ⚠️ 그런데 자동운전 전에 반드시 알아야 할 2가지 + + 코드를 읽다가 발견한 위험 지점입니다: + + 1. 쓰기 경로에 안전 가드가 0건입니다. WriteTagAsync는 들어온 double 값을 그대로 씁니다 — min/max 클램프, rate limit, + 범위 검증, 변화율 제한이 전혀 없습니다. 사람이 UI에서 손으로 쓸 땐 운전원이 최종 안전망이지만, 엔진이 자동으로 쓰는 + 순간 이 안전망이 사라집니다. 잘못된 SV 한 줄이 바로 밸브로 갑니다. + 2. 현재 LLM(MCP)에는 쓰기 도구가 없습니다. 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는" 상태가 유일한 안전 + 경계입니다. 자동운전을 붙이면 이 경계를 넘게 됩니다. + + → 따라서 0순위 작업은 쓰기 가드 레이어입니다. 자동운전 엔진보다 먼저. + + 업데이트된 아키텍처 (폐루프 가능 버전) + + ┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위) ──────────────────┐ + │ Step Test 곡선 분석 → θ·τ 추출 │ 파라미터(K,τ) 튜닝 제안 │ + │ 헌팅/Flooding/순도 이상 감지·설명 │ 운전원 Q&A │ + │ │ ※ 밸브 직접 쓰기 X. "엔진 파라미터 저장소"에만 │ + │ │ 제안→운전원 승인 후 반영 │ + ├─────────┼──────────────────────────────────────────────────┤ + │ 🔒 안전 가드 레이어 (신규 0순위) ─ 모든 쓰기 강제 통과 │ + │ hard min/max · 변화율 제한 · dead band · 화이트리스트 │ + │ · 자동 폴백(통신두절→안전SV) · 전 쓰기 감사로그 │ + ├─────────┼──────────────────────────────────────────────────┤ + │ Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초단위) │ + │ Realtime 구독으로 F 읽기 → Lag(300s) 필터 │ + │ → B_sv(데드타임 1~2분)/D_sv(5분)/P_sv(15~20분) 계산 │ + │ → WriteTagAsync / ControlOp 로 쓰기 (가드 통과 후) │ + └─────────────────────────────────────────────────────────────┘ + + 기존 코드 매핑: + - 읽기: ExperionRealtimeService(실시간 F·온도·수위) + query_pv_history(Step Test 곡선) + - 엔진: 신규 AutoRunService : BackgroundService — 기존 IHostedService 패턴 그대로 + - 쓰기: 기존 IExperionOpcWriteClient — 단, 신규 가드 레이어를 반드시 경유 + - LLM 감독: 기존 MCP 도구 + ReAct 에이전트 모드(이미 있음) + + 핵심 원칙은 그대로입니다 — 빠른 보상은 결정론 엔진(코드)이, LLM은 분 단위 감독·튜닝만. LLM은 밸브를 직접 건드리지 + 않고, 엔진의 파라미터(K·τ·한계값)만 제안하며 그것도 운전원 승인 게이트를 거칩니다. + + 쓰기가 된다는 사실이 그림을 바꿨으니, 무엇부터 만들지 다시 여쭙겠습니다. + +● User declined to answer questions + ⎿  · 추가 쓰기 능력을 확인했습니다. 무엇부터 구현할까요? (순서 조정 가능) (안전 가드 레이어 먼저 (권장) / 결정론 보상 + 엔진 (폐루프) / 조언형(개루프)부터 / 시뮬레이터 먼저) + · LLM이 자동운전에 개입하는 수준은 어디까지 허용할까요? (감독·조언만 (권장) / 파라미터 쓰기(승인 게이트) / MCP 쓰기 + 도구 추가) + +● 어떤 점을 더 명확히 하고 싶으신가요? 편하게 말씀해 주세요. + + 참고로, 제가 질문으로 가두기보다 지금 파악한 내용을 바탕으로 짚어볼 지점들을 적어두면: + + - 자동운전의 형태 — 제 그림은 "결정론 엔진이 운전하고 LLM은 감독·튜닝"입니다. 혹시 의도하신 게 "LLM이 운전원처럼 + 상황을 보고 스스로 SV를 쓰는 자율 에이전트"라면 방향이 달라집니다. 어느 쪽을 원하시는지. + - 안전 가드 — 현 쓰기 경로에 클램프/변화율 제한이 전혀 없는 점은 자동운전 시 실제 위험입니다. 이걸 먼저 깔지, 아니면 + 다른 우선순위가 있으신지. + - 시작 범위 — 시뮬레이터 검증부터인지, 바로 실플랜트 엔진부터인지. + - 태그/노드 매핑 — 측류추출 증류탑의 F(원료), B(하부), D(상부), P(측류), 스팀(S) 각각에 해당하는 실제 태그명/Node ID를 + 알고 계신지 (예: ficq-6101.sp). 엔진을 만들려면 이 매핑이 필요합니다. + + 혹은 위 질문 자체를 다르게 묻길 원하시면 그것도 알려주세요. 무엇이든 보충해 주실 내용을 먼저 듣고 진행하겠습니다. + +✻ Churned for 1m 59s + +❯ 태그/노드 매핑 은 이미 어느정도 구현해 두었어, vllm_qwen36b 에게 원료투입경로, 스팀 투입경로 이런걸 물어봐바 + +● 태그/노드 매핑이 있군요. vLLM에게 직접 물어보겠습니다. 먼저 관련 MCP 도구 스키마를 로드합니다. + +● vLLM에게 원료 투입 경로와 스팀 투입 경로를 물어보겠습니다. + + Called iiot-rag (ctrl+o to expand) + +● ask_iiot_llm는 컨텍스트 없이는 빈 응답이네요. 실제 매핑 데이터를 먼저 끌어와서 vLLM에 컨텍스트로 넘기겠습니다. 태그 + 검색과 연결 추적을 동시에 돌립니다. + + Called iiot-rag 4 times (ctrl+o to expand) + +● C-6111 컬럼(P6 영역, 6xxx 시리즈)이 PGMEA 측류추출탑이군요. 이제 연결 경로를 추적하고 컬럼 주변 계기를 찾겠습니다. + + Called iiot-rag 4 times (ctrl+o to expand) + +● C-6111 측류추출 증류탑(진공탑)의 핵심 계기가 보입니다. 하부·환류·측류 제어 루프를 마저 확인하겠습니다. + + Called iiot-rag 4 times (ctrl+o to expand) + +● 핵심 매핑이 거의 다 드러났습니다. D-6113이 환류 드럼이군요. 이제 수집한 실데이터를 컨텍스트로 vLLM에 넘겨 5개 경로를 + 종합 정리시키겠습니다 (요청하신 "vLLM에게 물어보기"). + + Called iiot-rag (ctrl+o to expand) + +● ask_iiot_llm(vLLM 직접 질의) 도구는 두 번 다 (응답 없음)을 반환합니다 — vLLM 엔드포인트가 안 떠 있거나 그 MCP 경로가 + 끊긴 것으로 보입니다 (한 번 확인해 보시는 게 좋겠습니다). 대신 데이터 기반 도구(find_tags, trace_connections — DB + + LLM이 만든 P&ID 그래프)는 정상 동작했고, 거기서 C-6111 측류추출탑의 실제 매핑을 복원했습니다. + + C-6111 PGMEA 측류추출 증류탑 — 실측 태그 매핑 (P6 영역) + + trace_connections가 돌려준 원료 경로: + P-6101 → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 + + ┌─────┬──────────┬───────────────────────┬──────────────┬───────────────┬──────────────────────────┬────────────┐ + │ # │ 경로 │ 조작변수(MV)/제어 │ 유량 │ 온도 │ 수위/압력 │ 문서상 τ │ + ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤ + │ │ 원료 │ FICQ-6101(SP/OP) → │ │ TI-6111? │ │ 입력신호(L │ + │ F │ 투입 │ FCV-6101 │ FT-6101 │ (예열 E-6103) │ — │ ag 300s │ + │ │ │ │ │ │ │ 필터) │ + ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤ + │ S │ 리보일러 │ 스팀밸브(리보일러 │ FI-6115 │ TI-6111A(BOT) │ PI-6700(스팀압) │ 가장 빠름 │ + │ │ 스팀 │ 듀티) │ │ , TICA-6111A │ │ │ + ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤ + │ B │ 하부 │ 하부 발출 밸브 │ (미확인) │ TI-6111A(BOT) │ LI-6111(하부수위) │ 1~2분 │ + │ │ 제거 │ │ │ │ │ │ + ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤ + │ │ 상부/환 │ FICQ-6113(PV29.9/SP36 │ │ │ LI-6113(D-6113 │ │ + │ D/R │ 류 │ .4) │ FI-6113 │ TI-6111D(TOP) │ 환류드럼), LICA-6113, │ 5분 │ + │ │ │ │ │ │ PI-6111(진공) │ │ + ├─────┼──────────┼───────────────────────┼──────────────┼───────────────┼──────────────────────────┼────────────┤ + │ P │ 측류 │ 측류 추출 밸브 │ FI-6120(PGME │ TI-6111B/C(MI │ LI-6121/6122/6123(제품탱 │ 15~20분 │ + │ │ 제품 │ │ A) │ D) │ 크) │ │ + └─────┴──────────┴───────────────────────┴──────────────┴───────────────┴──────────────────────────┴────────────┘ + + OPC Node 형식: ns=1;s=sinamserver:ficq-6101.sp / .op / .md(MAN=0/AUTO=1) — UI 기본값과 일치. + + 자동운전 엔진에 그대로 꽂히는 그림 + + - 입력(외란/피드): FICQ-6101 원료 유량 → Lag(300s) 필터 → F_clean + - MV 1 (B, τ 1~2분): F_clean → 하부 발출 밸브, LI-6111 수위 제약(Flooding 방지) + - MV 2 (D/R, τ 5분): F_clean → FICQ-6113.sp, LI-6113 드럼 수위 연동 + - MV 3 (P, τ 15~20분): F_clean → 측류 추출 밸브, TI-6111B/C 중간단 온도/순도 보호 + - S: 하부 온도(TI-6111A/TICA-6111A)에 직결 — 가장 빠른 응답 + + 흥미로운 현재 상태: FICQ-6113 PV 29.9 / SP 36.4로 추종 중이고 진공압 PICA-6111 30.4 — 탑이 실제 운전 중인 데이터로 + 보입니다. + + 아직 비어 있는 2칸 (엔진 만들기 전 확정 필요) + + 1. B(하부 제거) 유량계·밸브 태그 — LI-6111 수위는 있는데 발출 유량/밸브 태그가 안 잡힙니다. + 2. P(측류) 추출 밸브 태그 — FI-6120(유량 측정)은 있으나 추출 제어밸브가 미확인. + + 이 두 개는 find_tags로 6112/6114/6116번대를 더 훑거나, C-6111에서 trace_connections downstream를 돌리면 채울 수 + 있습니다. + + 지금 매핑을 (a) 더 파서 빈 칸 2개를 채울까요, 아니면 (b) 이 매핑을 자동운전 엔진 설계 문서/태그 설정으로 정리해 + 드릴까요? 그리고 ask_iiot_llm이 빈 응답인 건 vLLM 서버 상태를 확인해 보시는 걸 권합니다. + +✻ Cooked for 2m 38s + +❯ 아니, 제품 추출 부분은 아직 매핑을 완료하지 않았어, 이건 내가 할거고, 일단, 측류추출-자동운전-플랜.md에 컨셉과 + 선택사항을 모두 기록해줘 + +● 플랜 문서를 작성하겠습니다. 원본 문서와 같은 위치(루트)에 두고, 제품 추출(P) 매핑은 사용자 담당 TODO로 표시하겠습니다. + +● Write(측류추출-자동운전-플랜.md) + +──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── + Create file + 측류추출-자동운전-플랜.md +╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ + 1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜 + 2 + 3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서 + 4 > **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록. + 5 > + 6 > 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태. + 7 + 8 *작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 9 + 10 --- + 11 + 12 ## 0. 핵심 원칙 (가장 중요) + 13 + 14 **LLM을 빠른 제어 루프에 넣지 않는다.** + 15 + 16 `측류추출-시간지연-적용방식.md`가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야 + 17 하는 빠른 루프다. 여기에 LLM을 직접 넣으면: + 18 + 19 | 문제 | 영향 | + 20 |------|------| + 21 | 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 | + 22 | 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 | + 23 | 환각 | 잘못된 SV 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 | + 24 + 25 → **결론**: 빠른 보상은 **결정론 엔진(코드)** 이 담당하고, **LLM은 분 단위 감독·튜닝·조언만** 한다. + 26 이것이 LLM을 실공정에 붙이는 유일하게 안전한 형태다. + 27 + 28 --- + 29 + 30 ## 1. 2-Plane 아키텍처 + 31 + 32 ``` + 33 ┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위, 느림) ───────────────┐ + 34 │ · Step Test 곡선 분석 → θ(데드타임)·τ(시상수) 자동 추출 │ + 35 │ · 파라미터(K, τ, 한계값) 튜닝 제안 │ + 36 │ · 헌팅 / Flooding / 순도 드리프트 이상 감지·자연어 설명 │ + 37 │ · 운전원 Q&A ("왜 제품밸브가 천천히 열려요?") │ + 38 │ │ ※ 밸브 직접 쓰기 금지. "엔진 파라미터 저장소"에만 │ + 39 │ │ 제안 → 운전원 승인 후 반영 │ + 40 ├─────────┼──────────────────────────────────────────────────────┤ + 41 │ 🔒 안전 가드 레이어 (신규, 0순위) ─ 모든 쓰기가 강제 통과 │ + 42 │ hard min/max · 변화율(rate) 제한 · dead band · 태그 화이트 │ + 43 │ 리스트 · 통신두절→안전SV 폴백 · 전 쓰기 감사로그 │ + 44 ├─────────┼──────────────────────────────────────────────────────┤ + 45 │ Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초 단위) │ + 46 │ Realtime 구독으로 F(원료유량) 읽기 │ + 47 │ → Lag(τ=300s) 필터로 헌팅 제거 → F_clean │ + 48 │ → B_sv(데드타임 1~2분) / D_sv(5분) / P_sv(15~20분) 계산 │ + 49 │ → 가드 통과 후 WriteTagAsync / ControlOp 로 쓰기 │ + 50 └────────────────────────────────────────────────────────────────┘ + 51 읽기: ExperionRealtimeService · query_pv_history + 52 쓰기: IExperionOpcWriteClient (가드 레이어 경유 필수) + 53 ``` + 54 + 55 --- + 56 + 57 ## 2. 보상 제어 수식 (Plane 1 — 결정론, LLM 아님) + 58 + 59 원본 문서 §2·§4 기준. + 60 + 61 - **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])` + 62 - **데드타임(Dead Time)**: 링버퍼로 N틱 지연 + 63 - **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** 1개 (원본 §4.1 "1순위 대책") + 64 + 65 | MV | 제어 대상 | τ / 데드타임 | 목적 | + 66 |----|----------|-------------|------| + 67 | B | 하부 제거량 | 1~2분 | 탑 넘침(Flooding) 즉시 방지 | + 68 | D/R | 상부 제거량/환류 | 5분 | 압력/조성 안정화 | + 69 | P | 측류 제품 추출 | 15~20분 | 초고순도 PGMEA 품질 보호 (가장 보수적) | + 70 | S | 리보일러 스팀 | 가장 빠름(수초~수분) | 하부 온도 직결 | + 71 + 72 추가 안전요소(원본 §4.2/§4.3): 각 PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑). + 73 + 74 --- + 75 + 76 ## 3. 현 시스템에서 확인된 능력 (재사용 자산) + 77 + 78 ### 3.1 쓰기 (이미 구현됨) + 79 | 기능 | 구현 | 엔드포인트 | + 80 |------|------|-----------| + 81 | SP/OP 직접 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, value)` | `POST /api/experion/write` | + 82 | MAN/AUTO 모드 | `SetModeAsync(cfg, nodeId, "MAN"\|"AUTO")` | `POST /api/experion/mode` | + 83 | 통합 제어 (MD→MAN → OP쓰기 → AUTO복귀) | `ControlOp(TagName, OpValue, RestoreAuto)` | `POST /api/experion/con + trol` | + 84 | UI | "OPC UA Write" 탭 (#15) | `index.html #pane-write` | + 85 + 86 ### 3.2 읽기 + 87 - `ExperionRealtimeService` — 실시간 PV 구독 (`AddMonitoredItemAsync`), `IHostedService` + 88 - `query_pv_history` (MCP) / `ExperionHistoryController` — Step Test용 시계열 + 89 + 90 ### 3.3 백그라운드 서비스 패턴 + 91 - `IHostedService`/`AddHostedService` 이미 Realtime·History·OpcServer·Mcp에서 사용 중 + 92 → 신규 `AutoRunService : BackgroundService`가 기존 패턴에 그대로 들어감 + 93 + 94 ### 3.4 LLM 감독용 MCP 도구 (기존) + 95 - `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, + 96 `summarize_events`, `generate_status_report`, ReAct 에이전트 모드(구현됨) + 97 + 98 --- + 99 + 100 ## 4. ⚠️ 안전 관련 발견 사항 (자동운전 전 반드시 처리) + 101 + 102 1. **쓰기 경로에 안전 가드가 0건.** `WriteTagAsync`는 들어온 double을 그대로 쓴다 — + 103 min/max 클램프·rate limit·범위 검증·변화율 제한 전무. 사람이 UI에서 손으로 쓸 땐 운전원이 + 104 최종 안전망이지만, **엔진이 자동으로 쓰는 순간 안전망이 사라진다.** → **0순위: 가드 레이어.** + 105 2. **현재 LLM(MCP)에는 쓰기 도구가 없다.** 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는" + 106 상태가 유일한 안전 경계. 자동운전을 붙이면 이 경계를 넘게 됨 → 신중한 권한 설계 필요. + 107 3. **`ask_iiot_llm`(vLLM 직접 질의) MCP 도구가 빈 응답.** 2회 시도 모두 `(응답 없음)`. + 108 vLLM 엔드포인트 상태/연결 점검 필요. (단 `find_tags`/`trace_connections`는 정상 동작.) + 109 + 110 --- + 111 + 112 ## 5. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections` 기반) + 113 + 114 `trace_connections`가 돌려준 원료 경로: + 115 ``` + 116 P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 + 117 ``` + 118 + 119 | # | 경로 | 조작변수(MV)/제어 | 유량 | 온도 | 수위/압력 | τ | + 120 |---|------|------------------|------|------|----------|---| + 121 | **F** | 원료 투입 | **FICQ-6101**(SP/OP)→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력신호(Lag 300s) | + 122 | **S** | 리보일러 스팀 | 스팀밸브(리보일러 듀티) | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | + 가장 빠름 | + 123 | **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1 + ~2분 | + 124 | **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), + LICA-6113, PI-6111(진공), PICA-6111 | 5분 | + 125 | **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) + | 15~20분 | + 126 + 127 - OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1) + 128 - 현재 운전 데이터 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종 중, 진공압 PICA-6111 30.4 → 탑 가동 중으로 추정 + 129 + 130 ### 5.1 미완료 매핑 (담당 구분) + 131 - **P(측류 제품 추출) 경로 매핑 — 사용자가 직접 진행 예정** (본 플랜에서는 보류) + 132 - B(하부 제거) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 + 133 C-6111 `trace_connections downstream`로 보강 가능 (착수 시 확정) + 134 + 135 --- + 136 + 137 ## 6. 선택사항 (의사결정 대기) + 138 + 139 ### 6.1 시작 지점 — "무엇부터 구현하나" + 140 | 옵션 | 내용 | 비고 | + 141 |------|------|------| + 142 | **A. 안전 가드 레이어 먼저** | 쓰기 경로에 클램프·변화율·dead band·화이트리스트·감사로그 추가 | **권장**. 자 + 동운전 전제조건이며 수동 쓰기도 즉시 안전해짐 | + 143 | B. 결정론 보상 엔진(폐루프) | `AutoRunService`: F구독→Lag/데드타임→B/D/P SV 계산→가드 경유 쓰기 | 실제 자동운 + 전 핵심 | + 144 | C. 조언형(개루프)부터 | 엔진은 권고 SV만 계산·표시, 쓰기는 운전원이 클릭 승인 | 로직 안전검증 후 폐루프 전환 + | + 145 | D. 시뮬레이터 먼저 | FOPDT 증류탑 디지털 트윈으로 실플랜트 전 검증 | 현 브랜치 `sim/...` 와 자연스러움 | + 146 + 147 ### 6.2 LLM 개입 수준 — "LLM 권한 어디까지" + 148 | 옵션 | 내용 | 비고 | + 149 |------|------|------| + 150 | **가. 감독·조언만** | Step Test 분석·이상 설명·파라미터 제안만. 밸브/쓰기 절대 안 함 | **권장**. 가장 안전 | + 151 | 나. 파라미터 쓰기(승인 게이트) | LLM이 K·τ 등 엔진 파라미터 변경 제안 → 운전원 승인 후 반영. 밸브 직접 제어는 + 여전히 엔진만 | 적응 튜닝 가능 | + 152 | 다. MCP 쓰기 도구 추가 | LLM이 MCP로 직접 SV/모드 쓰기(가드 경유) | 유연하나 위험 큼 — 신중 적용 | + 153 + 154 > 현재 권장 조합: **6.1-A (가드 먼저) + 6.2-가 (LLM 감독만)** 로 시작 → 검증 후 단계적 확장. + 155 + 156 --- + 157 + 158 ## 7. 단계별 로드맵 + 159 + 160 - **Phase 0 — 안전 가드 레이어**: 쓰기 경로 클램프/rate/dead band/화이트리스트/폴백/감사로그. (전제조건) + 161 - **Phase A — 조언형(개루프)**: 보상 엔진이 권고 SV 계산·대시보드 표시 + LLM Step Test 분석기. + 162 DCS 쓰기는 운전원 수동 승인. 위험 최소. + 163 - **Phase B — 감독형 폐루프**: `AutoRunService`가 가드 안에서 SV 자동 쓰기. LLM은 파라미터만 제안(승인 게이트). + 164 - **Phase C — 자가 튜닝**: LLM이 Step Test 시점 제안 → 자동 피팅 → 시뮬레이터 A/B 검증 후 반영. + 165 + 166 --- + 167 + 168 ## 8. LLM이 잘하는 4가지 역할 (Plane 2 상세) + 169 + 170 1. **Step Test 분석 (강력 추천)** — 원본 §3. 유량 스텝 후 하부/상부/환류드럼/측류 온도·Analyzer 곡선을 + 171 `query_pv_history`로 뽑아 LLM에 주면 구간별 데드타임 θ·시상수 τ를 읽어냄 (결정론 곡선피팅으로 교차검증) + 172 → 그 값이 Plane 1 파라미터가 됨. + 173 2. **파라미터 튜닝 조언** — 처리량·원료 조성 드리프트 시 K·τ 재조정 제안. + 174 3. **이상 상황 서술** — "FT 헌팅 5분째 ±5% 지속, 필터 τ 300→420초 권장" 식 자연어 진단. + 175 4. **운전원 코칭** — 신입에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명. +✻ Cooked for 2m 38s + +❯ 아니, 제품 추출 부분은 아직 매핑을 완료하지 않았어, 이건 내가 할거고, 일단, 측류추출-자동운전-플랜.md에 컨셉과 + 선택사항을 모두 기록해줘 + +● 플랜 문서를 작성하겠습니다. 원본 문서와 같은 위치(루트)에 두고, 제품 추출(P) 매핑은 사용자 담당 TODO로 표시하겠습니다. + +● Write(측류추출-자동운전-플랜.md) + ⎿  Wrote 196 lines to 측류추출-자동운전-플랜.md + 1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜 + 2 + 3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서 + 4 > **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록. + 5 > + 6 > 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태. + 7 + 8 *작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 9 + 10 --- + … +200 lines (ctrl+o to expand) + +● 측류추출-자동운전-플랜.md를 루트(측류추출-시간지연-적용방식.md 옆)에 작성했습니다. + + 기록된 내용: + + - §0 핵심 원칙 — LLM을 빠른 제어 루프에 넣지 않음 + - §1 2-Plane 아키텍처 — 결정론 엔진(초 단위) + LLM 감독(분 단위) + 안전 가드 레이어 다이어그램 + +──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── + Settings Status Config Usage Stats + + Session + + + Total cost: $2.01 + Total duration (API): 7m 3s + Total duration (wall): 21m 49s + Total code changes: 197 lines added, 0 lines removed + Usage by model: + Usage by model: + Usage by model: + 1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜 + 2 + 3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서 + 4 > **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록. + 5 > + 6 > 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태. + 7 + 8 *작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 9 + 10 --- + … +200 lines (ctrl+o to expand) + +❯ /usage + ⎿ Settings dialog dismissed + +● 측류추출-자동운전-플랜.md를 루트(측류추출-시간지연-적용방식.md 옆)에 작성했습니다. + + 기록된 내용: + - §0 핵심 원칙 — LLM을 빠른 제어 루프에 넣지 않음 + - §1 2-Plane 아키텍처 — 결정론 엔진(초 단위) + LLM 감독(분 단위) + 안전 가드 레이어 다이어그램 + - §2 보상 수식 — Lag 필터/데드타임, MV별 τ(B 1~2분 / D 5분 / P 15~20분 / S 가장 빠름) + - §3 재사용 자산 — 기존 쓰기 클라이언트·엔드포인트·BackgroundService 패턴·MCP 도구 + - §4 안전 발견 — 쓰기 가드 0건, LLM 쓰기 도구 없음, ask_iiot_llm 빈 응답 + - §5 실측 태그 매핑 — F/S/B/D·R 매핑 표 + P는 "🔲 사용자 매핑 예정"으로 보류 표시 + - §6 선택사항 — 6.1 시작 지점(A~D), 6.2 LLM 권한(가~다), 권장 조합 명시 + - §7 로드맵 — Phase 0/A/B/C + - §8 LLM 4대 역할, §9 미해결 항목(P 매핑 = 사용자 담당으로 명기) + + 말씀대로 제품 추출(P) 경로 매핑은 사용자 진행 예정으로 §5.1과 §9에 담당 구분해 두었습니다. P 매핑을 마치시면 + 알려주시면 표의 해당 칸을 채우겠습니다. + +✻ Sautéed for 1m 11s + +❯ PID loop의 튜닝을 LLM이 보조할 수 있는 방법은?, 이걸 학습으로 플랜트 상황에 맞게 튜닝 가능할까? + +● 좋은 질문입니다. 두 부분으로 나눠서 — (1) LLM이 PID 튜닝을 어떻게 보조하나, (2) 그걸 학습으로 플랜트에 맞게 적응시키는 + 게 현실적인가. + + 1. LLM의 PID 튜닝 보조 — 역할 분담이 핵심 + + 자동운전 플랜의 §0 원칙과 동일합니다: LLM은 숫자를 만들지 않습니다. 정확한 산수와 결정성이 필요한 부분(모델 식별, 튜닝 + 공식 계산)은 결정론 수학이 하고, LLM은 그 위에서 판단·진단·번역·오케스트레이션을 합니다. + + ┌──────────────────────────────────────────────────┬─────────────────────────┬────────────────────────────────────┐ + │ 작업 │ 담당 │ 이유 │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ Bump/Step Test 응답에서 FOPDT 모델(K, τ, θ) 식별 │ 수학(최소제곱 곡선피팅) │ LLM 산수는 부정확·비결정 │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ 튜닝 공식 적용 → Kc, τI, τD 계산 │ 수학(SIMC/Lambda 등) │ 동일 │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ 어떤 튜닝 규칙·목표(λ)를 쓸지 결정 │ LLM │ 루프 용도·강건성 트레이드오프 판단 │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ 루프 분류 (유량/수위/온도/압력) → 튜닝 철학 선택 │ LLM │ 도메인 지식 매칭 │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ 트렌드에서 병증 진단 (발진/둔감/stiction/windup) │ LLM │ 패턴 해석·서술 │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ 운전원 언어 ↔ 파라미터 번역 │ LLM │ "오버슈트가 심해" → "Kc↓ 또는 τI↑" │ + ├──────────────────────────────────────────────────┼─────────────────────────┼────────────────────────────────────┤ + │ 재튜닝 시점 판단·근거 로깅 │ LLM │ 이벤트 단위 의사결정 │ + └──────────────────────────────────────────────────┴─────────────────────────┴────────────────────────────────────┘ + + 표준 워크플로우 (LLM이 지휘) + + ① LLM: 이 루프는 무엇? (예: TICA-6111A = 온도, 품질직결, 느림) + → 튜닝 철학 결정 (Lambda/SIMC, λ 보수적으로) + ② 수학: Bump Test 수행 → 응답곡선 → FOPDT (K,τ,θ) 최소제곱 피팅 + ③ LLM: 피팅 품질 검증 ("R²낮음, 노이즈/외란 의심 → 재시험 권고") + ④ 수학: SIMC 공식으로 Kc,τI,τD 산출 + ⑤ LLM: 결과 설명 + 안전범위 점검 → 운전원 승인 게이트 + ⑥ 가드 레이어 경유 적용 (플랜 §1 그대로) + + 루프별로 튜닝 철학이 다른데, 이게 LLM의 진짜 가치 + + ┌────────────────────────┬───────────────────────────────────┬──────────────────────────────┐ + │ 루프 (이 플랜트) │ 철학 │ LLM이 자동 선택 │ + ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤ + │ FICQ-6101 유량 │ 빠름, Lambda 작게, P+I만 (D 금지) │ 노이즈 많음 → 적극적 D 배제 │ + ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤ + │ LI-6111 / LI-6113 수위 │ Averaging/Surge (느슨하게) │ 원본 문서 §4.3과 직결 — 완충 │ + ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤ + │ TICA-6111A 온도 │ 지배동특성, 보수적 λ │ 품질직결 → 강건성 우선 │ + ├────────────────────────┼───────────────────────────────────┼──────────────────────────────┤ + │ PICA-6111 진공 │ 비교적 빠름 │ — │ + └────────────────────────┴───────────────────────────────────┴──────────────────────────────┘ + + 그리고 "튜닝 대상"이 둘이라는 점 + + 1. 기저 PID 루프 (Kc, τI, τD) — 위 고전 튜닝 + 2. 피드포워드 보상 파라미터 (Lag τ, 데드타임, 게인 K_D/K_B/K_P) — 자동운전 플랜의 Step Test 분석이 바로 이걸 식별 + + LLM은 둘 다 보조하며, Step Test 곡선 해석은 두 작업의 공통 입력입니다. + + --- + 2. "학습으로 플랜트에 맞게" — 가능하다, 단 메커니즘 선택이 전부 + + 가능합니다. 하지만 "강화학습으로 증류탑을 학습"은 실플랜트에선 위험·비현실적입니다(샘플 비효율 + 탐색 = 나쁜 SV 투입). + 안전한 것부터 야심찬 것 순으로 사다리를 제시합니다: + + ┌──────┬──────────────────────────────────────────────────────────┬──────────────┬────────────────────────────────┐ + │ 레벨 │ 방법 │ "학습" 성격 │ 현실성 │ + ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤ + │ L1 │ 주기적 재식별 (Bump Test 재실행 → FOPDT 재피팅 → 재튜닝) │ ML 아님, │ ★★★ 가장 실용·안전 │ + │ │ │ 적응 │ │ + ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤ + │ L2 │ 게인 스케줄링 (처리량·등급별 다점 튜닝 후 보간) │ 룩업 학습 │ ★★★ 비선형 대응 정석 │ + ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤ + │ L3 │ 고전 적응제어 (RLS 온라인 추정 → Self-Tuning) │ 온라인 추정 │ ★★ 검증됨(Åström), 진동주의 │ + ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤ + │ L4 │ 베이지안 최적화 (성능비용 IAE/오버슈트를 소수 실험으로 │ 데이터기반 │ ★★ 트윈 우선, 샘플효율 최고 │ + │ │ 최소화) │ ML │ │ + ├──────┼──────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────┤ + │ L5 │ 강화학습(RL) │ 정책학습 │ ★ 시뮬레이터 전용, 실플랜트 │ + │ │ │ │ 금지 │ + └──────┴──────────────────────────────────────────────────────────┴──────────────┴────────────────────────────────┘ + + 추가로 탐색 없이 안전하게 학습하는 두 가지가 이 시스템에 특히 잘 맞습니다: + + - 섀도/추천 모드 학습: 엔진이 "이렇게 하겠다"를 계산만 하고, 실제 운전원 조치 + 결과를 로깅 → 둘의 격차를 학습. + "운전원은 항상 P밸브를 우리 모델보다 느리게 연다" → 모델 보정. 탐색 위험 0, 지도학습. + - CLPM (폐루프 성능 모니터링): Harris 지수(최소분산 대비)·발진 감지·밸브 stiction 진단을 일상 운전 데이터만으로 수행 → + 루프 건강도 점수화 → 튜닝 열화 시 자동 플래그. 이게 재튜닝의 트리거가 되고, LLM이 우선순위를 서술. + + 추천 적응 루프 (이 플랜트 기준) + + 일상 데이터 → CLPM(Harris·stiction·발진) → LLM이 "열화 루프" 식별·서술 + → 게인 스케줄(L2) 해당 점 벗어남? → Bump Test 재식별(L1) + → 트윈에서 베이지안 최적화(L4)로 미세조정 → 운전원 승인 → 가드 경유 반영 + → 결과 로깅 → 섀도 학습으로 모델 보정 (순환) + + 반드시 지켜야 할 제약 (정직하게) + + - 디지털 트윈 우선 — 현 브랜치 sim/... 활용. L4/L5는 실플랜트 전 트윈 검증 필수. + - 식별성(Identifiability) — 충분한 가진(excitation) 없으면 모델 못 만듦. 고순도 탑은 비선형·느림 → 작은 선형모델은 + 국소적으로만 유효 → 그래서 L2 게인 스케줄링이 핵심. + - 안전 제약 — 모든 적응은 플랜 §0 가드 레이어 하드 한계 안에서만. 탐색형(L4/L5)엔 trust-region 필수. + - LLM은 비용함수·실험설계·수렴판정·가드를 담당하고, 최적화 수치는 알고리즘이 낸다 — 여기서도 §0 원칙 유지. + - 이 C-6111은 품질직결·느림·비선형 = 가장 보수적으로 다뤄야 하는 케이스. L1+L2+섀도부터, L4는 트윈에서만. + + --- + 요약: LLM은 PID 튜닝의 지휘자·진단가·번역가로 강력하고(수치는 결정론 수학이 산출), 플랜트 적응 학습도 가능하되 RL이 + 아니라 재식별+게인스케줄링+베이지안최적화+섀도학습+CLPM 조합이 안전하고 현실적인 답입니다. + + 이 내용을 자동운전 플랜 문서에 "§10. PID 튜닝 보조 & 적응 학습" 섹션으로 추가해 둘까요? + +✻ Brewed for 1m 10s + +❯ 좀더 얘기를 하고 문서를 작성하자, + + 내가 알고있는것은 밸브의 사이즈, 배관의종류, 컨트롤밸브의 CV 값과 CV 커브, 플로우미터의 유량범위 등의 물리적인 + 데이터를 가지고 있다면, 결정론적인 부분을 이것으로 프로그램화 하고, LLM은 실제로 무엇을 할 수있다는거야? + +● 아주 정확한 지점을 찌르셨습니다. 솔직하게 답하면 — 그 물리 데이터를 가지고 있다면, 제어 수학에서 LLM이 할 일은 오히려 + 크게 줄어듭니다. 그게 맞고, 그게 좋은 겁니다. 하나씩 정리하죠. + + 1. 물리 데이터로 결정론화되는 부분 (LLM 불필요) + + 말씀하신 데이터는 사실 "데이터 피팅으로 추정"해야 했던 것들을 계산으로 바꿔버립니다: + + ┌───────────────────────────────────┬─────────────────────────────────────────────┬────────────────────┐ + │ 물리 데이터 │ 계산되는 결정론 모델 │ 이전엔 뭐로 구했나 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 컨트롤밸브 Cv + Cv 커브(설치특성) │ OP(%) → 유량 관계, 밸브 게인 dQ/dOP │ Step Test 식별 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 배관 종류·구경·길이 │ ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 │ Step Test로 θ 측정 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 드럼/트레이 홀드업 체적 │ 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) │ Step Test로 τ 측정 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 플로우미터 레인지 │ 스케일링·분해능·노이즈 플로어 │ — │ + └───────────────────────────────────┴─────────────────────────────────────────────┴────────────────────┘ + + → 즉 자동운전 플랜의 B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업 = 체적/유량 으로 직접 계산됩니다. 밸브 게인도 Cv + 커브 미분으로 나옵니다. 여기에 LLM을 넣을 이유가 없습니다. 모델기반 튜닝(SIMC/Lambda)도 이 물리모델로 바로 Kc·τI가 + 떨어집니다. 이 부분은 그냥 프로그램하세요. 제 처음 답에서 "Step Test로 식별"이라던 것의 상당 부분이 당신의 경우 + 불필요해집니다. + + 2. 그런데 물리 데이터가 못 주는 3가지 + + 여기가 핵심입니다. Cv·배관·유량범위는 하이드롤릭(얼마나 흐르나) 을 줍니다. 그런데 증류탑의 진짜 어려움은 거기가 + 아닙니다. + + (가) 분리/조성 동특성 — 당신 데이터에 없음. + 원본 문서의 "P(측류)는 15~20분으로 가장 느리다" 는 배관 이송이 아니라 트레이별 물질·열 홀드업 + 기액평형(VLE)으로 새 + 조성이 자리잡는 시간입니다. 홀드업 체적은 당신이 알지만, 상대휘발도·트레이 효율·VLE는 Cv 커브에 없습니다. 이 P 지연은 + 물리 데이터만으론 안 나오고, 단별(stage) 분리 모델이 필요합니다. → B·D는 물리로 계산되지만, P는 안 됩니다. 이게 + 경계선입니다. + + (나) 모델-플랜트 불일치(드리프트). Cv 커브는 깨끗한 신품 설계값입니다. 실제론 밸브 stiction·시트 마모, E-6103 파울링, + 트레이 효율 저하로 시간에 따라 어긋납니다. 물리모델은 "어제의 진실"이고 플랜트는 오늘 다릅니다. + + (다) 목적·맥락·예외. 무엇이 "잘 도는" 건지(회수율 최대 vs 에너지 최소 vs 순도 사수), 등급 변경, 기동/정지, 계기 고장, + 상류 외란 — 정적 물리 데이터엔 전혀 없습니다. + + 3. 그래서 LLM이 실제로 하는 일 (과장 없이) + + 물리모델이 좋을수록 LLM은 제어 경로에서 빠지고 가장자리로 이동합니다. 솔직한 목록: + + ┌────────────────────┬───────────────────────────────────────────────────────────────────┬───────────────────────┐ + │ LLM 역할 │ 구체적으로 │ 정직한 가치 │ + ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤ + │ ① 커미셔닝 보조 │ 밸브 데이터시트·Cv 커브·배관 스펙을 파싱해 결정론 엔진의 │ ★★ 즉시 유용. "물리는 │ + │ │ config/코드로 조립, Cv 값 정합성 점검 │ 결정론" 철학 그대로 │ + ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤ + │ ② 데이터 │ 물리예측 유량 vs 실측 잔차 계산은 수학, "이 OP·ΔP에서 8% 미달 → │ │ + │ 정합(드리프트 │ 밸브 파울링/마모 의심" 해석·재교정 트리거는 LLM │ ★★ (나) 해결 │ + │ 진단) │ │ │ + ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤ + │ ③ 소프트센서 보조 │ 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 │ ★ (가) 보완(완전 해결 │ + │ │ │ 아님) │ + ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤ + │ ④ 감독형 예외 처리 │ 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장)에서 │ ★★★ 물리 침묵 영역 │ + │ │ 판단·완화 │ │ + ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤ + │ ⑤ 운전원 │ 의도/경제목표 → SV·제약으로 번역, "왜 이렇게 도는지" 설명 │ ★★★ 물리 침묵 영역 │ + │ 인터페이스 │ │ │ + ├────────────────────┼───────────────────────────────────────────────────────────────────┼───────────────────────┤ + │ ⑥ 교차 데이터 융합 │ 알람+이벤트+랩분석+정비이력+물리잔차를 엮어 진단 │ ★★★ 기존 MCP 도구 │ + │ │ │ 활용 │ + └────────────────────┴───────────────────────────────────────────────────────────────────┴───────────────────────┘ + + 4. 핵심 원리 (한 줄) + + ▎ LLM의 가치는 물리모델 품질에 반비례합니다. 당신처럼 물리를 잘 잡을수록 LLM은 제어 산수에서 사라지고 — ③ 못 측정하는 + ▎ 조성, ④ 프로그램 안 된 예외, ⑤ 사람 인터페이스, ⑥ 교차 진단, ①커미셔닝으로 옮겨갑니다. 이게 정상이고 안전한 + ▎ 모습입니다. + + --- + 문서로 넘어가기 전에 같이 정리하고 싶은 게 몇 가지 있습니다: + ▎ 모습입니다. + + --- + 문서로 넘어가기 전에 같이 정리하고 싶은 게 몇 가지 있습니다: + + 1. 분리/조성(가) 모델을 어디까지 갈 건가? — P 지연을 (a) 그냥 보수적 고정 τ(15~20분)로 두고 안 건드릴지, (b) 간이 + 트레이/홀드업 모델을 세울지, (c) 운전데이터 기반 경험모델로 둘지. 이게 LLM 역할 ③의 깊이를 결정합니다. + 2. 물리 데이터의 형태 — Cv 커브가 표/수식/데이터시트 PDF 중 무엇인가요? 역할 ①(LLM이 config로 조립)의 실현성이 여기 + 달려 있습니다. + 3. LLM을 "제어 보조"로 보시는지 "운전 보조(예외·인터페이스)"로 보시는지 — 위 ②④⑤⑥ 중 어디에 무게를 두실지에 따라 문서 + 구조가 달라집니다. + + 이 세 가지에 대한 생각을 들려주시면, 그걸 반영해서 플랜 문서에 섹션을 작성하겠습니다. + +✻ Baked for 1m 17s + +❯ 내가 생각하는 방향은 이거야 + 1. 결정론이든, llm이든 목표 설정값을 연산---> Experion 서버에 전달 + 2. Experion 서버에서 프로그램을 해서, 전달된 값을 화면상(Operator Station 모니터링 HMI)에 PID Loop 표시에 제안한 + SP값을 표시 + 3. 운전원이 여기에 익숙해지고, 신뢰가 생긴다면, mode 변경, -> Set Point 변경 주도권 가져옴 + 4. PID LOOP의 Hunting이 심하다고 판단되는 기준을 넘으면, 매뉴얼 모드로 변경, 제어출력(OP)를 가지고 변경하면서 안정권 + 유지 + + 꼭 DCS 컨트롤러의 PID 제어기의 파라미터를 교정하는것이 아니어도 매뉴얼 모드에서, op 변경만 가지고도 가능할까? 하는 + 의문에서 시작된 것이 이 세션의 시작 목적이기도 함---> 당연히 안전장치(rate제한, 절대값 제한, 현재 유량 범위 감안 밸브 + 변동폭 제한, 기본 컨트롤러에 설정된 ESD, IL 동작 이 보증된 상태에서 임 + +● 이제 핵심이 명확해졌습니다. 그리고 시작 질문 — "PID 파라미터를 안 건드리고, MANUAL에서 OP만으로 안정화 가능한가?" — 에 + 정직하게 답하면: 경우에 따라 Yes, 그리고 그게 오히려 브라운필드에서 더 현실적입니다. 다만 결정적인 단서가 있습니다. + + 1. 시작 질문에 대한 직답 + + 핵심은 헌팅의 원인입니다. MANUAL+OP로 잡히는 헌팅과 안 잡히는 헌팅이 갈립니다. + + ┌──────────────────────┬────────────────────┬─────────────────────────────────────────────────────────────────────┐ + │ 헌팅 원인 │ MANUAL+OP로 │ 설명 │ + │ │ 잡히나? │ │ + ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤ + │ 튜닝 과민(Kc 과대/I │ ✅ 즉시 잡힘 │ MAN 전환 순간 컨트롤러 피드백이 빠지므로 제어기발 발진이 사라짐. │ + │ 과속) │ │ OP를 천천히·rate제한으로 움직이면 됨 │ + ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤ + │ 상류 외란(원료 헌팅 │ ✅ 잘 잡힘 │ 원본 문서의 "필터 + 부드럽게" 가 곧 MAN 느낌의 피드포워드. 가장 │ + │ 등) │ │ 강력한 케이스 │ + ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤ + │ 루프 간 간섭 │ ⚠️ 부분적 │ 이동/시차 조절로 완화 │ + ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤ + │ 밸브 stiction(고착) │ ❌ 안 잡힘, 오히려 │ 물리적 결함. MAN에서 작게 보정하면 또 고착·점프. 액추에이터 마모만 │ + │ │ 악화 │ 늘어남 → 정비 대상 │ + └──────────────────────┴────────────────────┴─────────────────────────────────────────────────────────────────────┘ + + → 결론: 튜닝·외란발 헌팅은 PID 파라미터를 안 건드리고 MAN+OP로 충분히 안정화됩니다. 단, 한 가지 본질적 사실: + + ▎ MAN으로 가는 순간 DCS PID가 하던 자동 피드백 규제가 사라집니다. OP를 누가 계속 움직여줘야 합니다. 즉 당신은 "튜닝을 + ▎ 안 한" 게 아니라 컨트롤러를 DCS 밖(당신 소프트웨어)으로 옮긴 것입니다. 외부 프로그램이 느린 PI/피드포워드로 OP를 + ▎ 써주는, 사실상 외부 컨트롤러가 됩니다. + + 이건 정당한 방식이고, 실제 APC가 하는 일과 같습니다. 그리고 브라운필드에서 매력적인 이유: DCS 로직 변경·변경관리(MoC) + 없이 OPC 쓰기만으로 됩니다(당신은 이미 OPC Write가 있음). + + 2. 그래서 두 가지 모드를 구분하세요 — 당신의 1~4단계가 정확히 여기 매핑됩니다 + + ┌─────────────────────────┬───────────────────────┬──────────────────────────────────────────┬───────────┐ + │ 방식 │ 누가 빠른 규제를 하나 │ 언제 │ 당신 계획 │ + ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤ + │ (A) SP 쓰기 + AUTO 유지 │ DCS PID (그대로 둠) │ 평상시 감독·최적화. 기저 PID가 쓸만할 때 │ 1~3단계 │ + ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤ + │ (B) OP 쓰기 + MANUAL │ 당신 소프트웨어 │ 기저 PID가 헌팅인데 재튜닝 못/안 할 때 │ 4단계 │ + └─────────────────────────┴───────────────────────┴──────────────────────────────────────────┴───────────┘ + + (A)는 SP를 AUTO 루프에 쓰는 거라 본질적으로 bumpless하고 가장 안전합니다. (B)는 더 강력하지만 규제·bumpless·폴백을 + 전부 당신이 책임집니다. + + → 당신 직관이 정확합니다: 평상시엔 (A)로 신뢰를 쌓고, 헌팅 루프에 한해 (B)로 개입. PID 파라미터 교정은 필수가 + 아닙니다. + + 3. 4단계의 전제 — "헌팅 원인 진단"이 게이트 (여기가 LLM의 진짜 자리) + + 4단계가 성공하려면 MAN 전환 전에 원인을 판별해야 합니다. stiction인데 OP 핸드홀딩하면 헛수고+마모입니다. + + - 헌팅 검출/심각도 판정 = 결정론(진폭·주기·지속성, 오실레이션 인덱스). MAN 전환 트립도 결정론이어야 함(LLM 지연 불가). + - 원인 분류(튜닝 vs stiction vs 외란) = LLM + 데이터 융합의 고가치 역할. OP-PV 위상, 한계주기 파형, 상류 신호, + 정비이력을 엮어 "이건 stiction → 4단계 말고 정비 플래그" vs "외란 → 4단계 OP 핸드홀딩 유효" 판단. + + 즉 LLM은 OP를 직접 흔드는 게 아니라, "이 루프에 4단계를 적용해도 되는가"를 판정합니다. 이게 당신 비전에 LLM이 깔끔하게 + 들어가는 지점입니다. + + 4. 안전 봉투 — 당신이 든 것 + 빠진 것 + + 당신이 명시한 것(✅ 다 맞음): rate 제한 · 절대값 제한 · 현재 유량 대비 밸브 변동폭 제한 · ESD/IL 독립 보증. 특히 + ESD/SIS가 BPCS 루프의 MAN/AUTO와 무관하게 독립 동작한다는 점이 이 실험을 봉인된 안전 범위 안에 묶어줍니다 — 정확한 + 인식입니다. + + 추가로 반드시 넣어야 할 것: + + 1. 양방향 Bumpless — AUTO→MAN 시 현재 OP에서 시작, MAN→AUTO 복귀 시 PID가 현재 PV/OP에서 초기화(Experion 기본 지원). + 2. 컴스 워치독 → AUTO로 폴백 (중요한 미묘점): MAN에서 OP 잡고 있다가 외부 프로그램이 죽으면 루프가 마지막 OP에 규제 + 없이 방치됨 → 위험. 그래서 "통신 두절 시 MAN 고수가 아니라 AUTO 복귀" 가 안전. 결국 DCS PID는 적당히 튜닝된 채로 두는 + 게 폴백 안전망입니다(바이패스해도 AUTO가 늘 안전귀항지여야 함). + 3. PV/품질 가드 — PV가 밴드 이탈하면 4단계 중단→AUTO 또는 안전 OP. + 4. 한 번에 한 루프 — 간섭 루프를 동시에 MAN 두지 않기. + 5. 운전원 최우선 오버라이드 — 항상 즉시 회수 가능. + 6. MoC/문화 — 자동 시스템이 루프를 MAN으로 돌리고 OP를 흔드는 건 현장에서 APC로 간주되어 변경관리·운전원 수용 이슈가 + 있음(기술 외 항목). + + 5. 기존 인프라와의 매핑 (이미 다 있음) + + - 1~2단계(제안 SP 표시): 루프별 advisory 섀도 포인트(예: FICQ-6101_ADV)를 WriteTagAsync로 쓰고 HMI 그룹/트렌드에 실제 + SP 옆에 표시 → 페이스플레이트 해킹 없이 "제안 vs 실제" 비교. (Experion 디스플레이에 제안값을 어떻게 띄울지가 1~2단계의 + 실질 통합 과제) + - 3단계(SP 주도권): WriteTagAsync(.sp) + AUTO 유지. + - 4단계(MAN+OP): 바로 그 ControlOp(MD→MAN→OP쓰기→AUTO복귀) 가 4단계의 기본 프리미티브입니다. RestoreAuto=false로 MAN + 유지하며 OP 스트리밍 → 안정되면 AUTO 복귀, 워치독이 비상 복귀. + + --- + 문서로 가기 전에 같이 못 박을 것 세 가지: + + 1. 4단계 OP 제어법 — MAN에서 (i) OP 고정 후 가끔 보정인지, (ii) 외부 느린 PI/피드포워드로 OP를 상시 써주는지. 후자면 + "외부 컨트롤러"를 명시적으로 설계해야 합니다(이게 사실상 미니 APC). + 2. 헌팅 임계 정의 — 진폭 몇 %/주기/지속 몇 분에서 4단계 트립? 그리고 stiction 자동 판별을 어디까지 신뢰할지(초기엔 LLM + 진단 → 운전원 확인 권장). + 3. 1~2단계 HMI 표시 방식 — advisory 섀도 포인트로 갈지, Experion 커스텀 디스플레이를 손댈지. 이게 신뢰 구축 단계의 + 실현성을 좌우합니다. + + 이 세 개에 대한 생각을 주시면, 지금까지의 컨셉·4단계 로드맵·안전봉투·LLM 역할(특히 헌팅 원인 진단)을 플랜 문서에 정식 + 섹션으로 정리하겠습니다. + +✻ Cooked for 1m 47s + +❯ sp는 PID 루프의 RSP 입력을 사용하면, 운전원이 언제든 LOCAL SP로 변경할 수 있으므로, 문제 없슴, 즉, PID LOOP의 SP를 + 직접 WRITE하는게 아니고, 별도의 변수에 쓰고, 그게 RSP로 연결, 운전원은 선택권이 있슴 + +● 맞습니다. RSP(Remote SP)를 쓰는 게 정석이고, 이걸로 권한·bumpless·가역성이 한 번에 깔끔하게 풀립니다. 제가 직전에 + 제안한 "advisory 섀도 포인트 + 커스텀 디스플레이"는 이제 필요 없습니다 — 더 나은 길입니다. + + 왜 이게 정답인가 + + 엔진은 루프 SP 레지스터를 절대 건드리지 않고, 자기 변수에만 씁니다. 그 변수가 RSP로 연결되고, 운전원의 LSP↔RSP(= + Experion 기준 AUTO↔CAS) 전환 스위치가 유일한 권한 손잡이가 됩니다. + + 이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다: + - 1~2단계(제안 표시): 루프는 LSP(AUTO)에 둠. 운전원은 페이스플레이트에서 "원격이 제안하는 SP 후보값"을 그냥 봄. 별도 + 화면 개발 불필요 — 네이티브 페이스플레이트가 RSP 후보를 보여줌. + - 3단계(주도권 이양): 운전원이 신뢰가 생기면 CAS로 한 번 토글 → 그 순간부터 엔진 SP 추종. 코드 추가 0. 되돌리려면 다시 + LSP로 토글하면 끝. + + 다만 한 가지 구현 요건 — 외부 추종(tracking) + + 여기가 OPC 외부 감독의 미묘점입니다. 정식 Experion 캐스케이드라면 back-calculation 핸드셰이크로 primary가 자동 + 추종합니다. 그런데 OPC로 RSP 소스에 쓰는 외부 엔진은 그 핸드셰이크를 못 받습니다. 그래서: + + ▎ 루프가 LSP(미선택) 상태일 때, 엔진은 현재 실작동 SP를 읽어 자기 출력값 = 현재 SP로 추종시켜야 합니다. 그래야 + ▎ 운전원이 CAS로 토글하는 순간 bumpless가 보장됩니다. (선택 안 됐을 때 출력을 현재값에 물려두는 표준 캐스케이드 매너를 + ▎ 엔진이 직접 구현) + + 이거 하나만 지키면 운전원이 언제 토글해도 충격 없습니다. + + 방어 심층 (independent layers) + + 1. 엔진 자체 가드 (rate·절대값·변동폭) + 2. DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가. + 3. 운전원 LSP/RSP 토글 (언제든 회수) + 4. ESD/IL/SIS 독립 동작 + + 구체 작업 항목 + + - DCS 구성: 루프별 감독 소스 포인트 생성 → 각 PID의 RSP/X 입력에 control connection. (엔진은 이 포인트에만 OPC write) + - OPC 타깃 변경: WriteTagAsync 대상이 ...:ficq-6101.sp → 감독 소스 포인트로만 바뀜. 쓰기 인프라는 그대로, 노드 ID만 + 교체. + - 모드 전환은 엔진이 안 함: AUTO↔CAS는 운전원 전유. 엔진은 SP 경로에서 모드를 절대 안 바꿈 → 더 안전. + + 한 가지 비대칭 — OP 경로(4단계)는 이만큼 깔끔하지 않음 + + RSP 트릭은 SP 경로(방식 A) 를 완벽히 커버합니다. 그런데 4단계(튜닝발 헌팅 → MAN+OP)는 다릅니다: + - CAS/RSP로 SP를 줘봐야 PID가 루프에 그대로 있으니 튜닝발 헌팅은 안 잡힘. + - 그래서 4단계는 여전히 MAN으로 내려 OP를 직접 쓰는 "무거운 개입"이고, 이전 단서(엔진이 컨트롤러가 됨 / 워치독→AUTO + 폴백)가 그대로 유효. + - 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? + 지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다. + + --- + 이제 SP 경로 설계는 깔끔하게 잠겼습니다(RSP + 외부 추종 + 운전원 토글). 직전에 띄운 세 가지 정렬 항목 중 HMI 표시 건은 + RSP로 해결됐고, 남은 건 둘입니다: + + 1. 4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부 + OP 입력" 지원 여부. + 2. 헌팅 임계 정의 — 진폭/주기/지속 기준, stiction 자동판별 신뢰 수준. + + 이 둘에 대한 방향을 주시면 — 컨셉, RSP 기반 SP 경로, 4단계 OP 경로, 안전봉투, LLM 역할(헌팅 원인 진단 중심), 단계별 + 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. + +✻ Worked for 1m 14s + +❯ 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? + 지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.---> 이것도 + DCS 컨트롤러에 별도의 변수를 만들고, 그걸 우리가 WRITE 하고, SWITCH 기능을 만들어서, PID LOOP OP, LLM OP 를 선택하게 + 하면 해결됨 + +● 정확합니다. 그 셀렉터 방식으로 OP 경로가 RSP와 완전 대칭이 됩니다. 그리고 한 가지 짚으면 — 제대로 하면 이게 기존 + MAN+OP+워치독보다 더 안전해집니다. + + 대칭 구조 완성 + + ┌──────────────────┬──────────────────────┬────────────────────────┐ + │ │ SP 경로 │ OP 경로 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 감독 변수 │ RSP 소스 포인트 │ "LLM OP" 변수 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 우리가 OPC write │ 그 포인트에만 │ 그 변수에만 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 운전원 스위치 │ LSP ↔ RSP (AUTO↔CAS) │ PID-OP ↔ LLM-OP 셀렉터 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 권한 │ 운전원 전유 │ 운전원 전유 │ + └──────────────────┴──────────────────────┴────────────────────────┘ + + 쓰기 인프라(WriteTagAsync)는 그대로, 노드 ID만 바뀝니다. 양쪽 다 "엔진은 자기 변수에만 쓰고, 운전원이 스위치로 + 채택"하는 동일 패턴. + + 단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종 + + 이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면: + + ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + ▎ 튀어나옴(bump). + + 방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 + 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로) + + 보너스 — 이게 4단계의 위험을 없앱니다 + + 이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다: + + - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 + 빠졌으니 사라짐. + - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 + 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐. + + → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 + 다시 씁니다. + + 정직한 단서 — MoC 강도가 다름 + + - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험. + - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → + 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱) + + 방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립. + + --- + 이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐: + + LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) + 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 + 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다. + + 여기에 + 헌팅 임계 정의(진폭/주기/지속). + + 이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 + 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 + 보수적으로 갈지 알려주세요. + +✻ Cooked for 58s + +❯ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output + 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, + MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — + 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 + 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다. + + 운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 + 올리면 PID가 현재 PV/OP에서 bumpless 재개. + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + + - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개. + - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림. + + → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다: + + ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = + ▎ DCS PID 규제로 fail-safe). + + 이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 + 유량/수위 루프는 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 안전합니다.) + + 그래서 결론 — 기본값과 예외 + + ┌───────────────────────────────────────┬──────────────────────────────────┬──────────────────────────────────────┐ + │ 루프 성격 │ 방식 │ 이유 │ + ├───────────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────────┤ + │ 대부분 (유량·수위 등) │ MAN+OP쓰기 + DCS 데드맨→AUTO ← │ 단순·기존인프라·저MoC. 동결이 양성 │ + │ │ 당신 안 │ │ + ├───────────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────────┤ + │ 빠르고 위험해 순간 규제 공백도 불가한 │ 선택+back-calc (PID AUTO 추종) │ 무충격 즉시 폴백 가치가 추가 MoC를 │ + │ 소수 루프 │ │ 정당화 │ + └───────────────────────────────────────┴──────────────────────────────────┴──────────────────────────────────────┘ + + 즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드. + + --- + + - 섀도/추천 모드 학습: 엔진이 "이렇게 하겠다"를 계산만 하고, 실제 운전원 조치 + 결과를 로깅 → 둘의 격차를 학습. + "운전원은 항상 P밸브를 우리 모델보다 느리게 연다" → 모델 보정. 탐색 위험 0, 지도학습. + - CLPM (폐루프 성능 모니터링): Harris 지수(최소분산 대비)·발진 감지·밸브 stiction 진단을 일상 운전 데이터만으로 수행 → + 루프 건강도 점수화 → 튜닝 열화 시 자동 플래그. 이게 재튜닝의 트리거가 되고, LLM이 우선순위를 서술. + + 추천 적응 루프 (이 플랜트 기준) + + 일상 데이터 → CLPM(Harris·stiction·발진) → LLM이 "열화 루프" 식별·서술 + → 게인 스케줄(L2) 해당 점 벗어남? → Bump Test 재식별(L1) + → 트윈에서 베이지안 최적화(L4)로 미세조정 → 운전원 승인 → 가드 경유 반영 + → 결과 로깅 → 섀도 학습으로 모델 보정 (순환) + + 반드시 지켜야 할 제약 (정직하게) + + - 디지털 트윈 우선 — 현 브랜치 sim/... 활용. L4/L5는 실플랜트 전 트윈 검증 필수. + - 식별성(Identifiability) — 충분한 가진(excitation) 없으면 모델 못 만듦. 고순도 탑은 비선형·느림 → 작은 선형모델은 + 국소적으로만 유효 → 그래서 L2 게인 스케줄링이 핵심. + - 안전 제약 — 모든 적응은 플랜 §0 가드 레이어 하드 한계 안에서만. 탐색형(L4/L5)엔 trust-region 필수. + - LLM은 비용함수·실험설계·수렴판정·가드를 담당하고, 최적화 수치는 알고리즘이 낸다 — 여기서도 §0 원칙 유지. + - 이 C-6111은 품질직결·느림·비선형 = 가장 보수적으로 다뤄야 하는 케이스. L1+L2+섀도부터, L4는 트윈에서만. + + --- + 요약: LLM은 PID 튜닝의 지휘자·진단가·번역가로 강력하고(수치는 결정론 수학이 산출), 플랜트 적응 학습도 가능하되 RL이 + 아니라 재식별+게인스케줄링+베이지안최적화+섀도학습+CLPM 조합이 안전하고 현실적인 답입니다. + + 이 내용을 자동운전 플랜 문서에 "§10. PID 튜닝 보조 & 적응 학습" 섹션으로 추가해 둘까요? + +✻ Crunched for 1m 10s + +❯ 좀더 얘기를 하고 문서를 작성하자, + + 내가 알고있는것은 밸브의 사이즈, 배관의종류, 컨트롤밸브의 CV 값과 CV 커브, 플로우미터의 유량범위 등의 물리적인 + 데이터를 가지고 있다면, 결정론적인 부분을 이것으로 프로그램화 하고, LLM은 실제로 무엇을 할 수있다는거야? + +● 아주 정확한 지점을 찌르셨습니다. 솔직하게 답하면 — 그 물리 데이터를 가지고 있다면, 제어 수학에서 LLM이 할 일은 오히려 크게 + 줄어듭니다. 그게 맞고, 그게 좋은 겁니다. 하나씩 정리하죠. + + 1. 물리 데이터로 결정론화되는 부분 (LLM 불필요) + + 말씀하신 데이터는 사실 "데이터 피팅으로 추정"해야 했던 것들을 계산으로 바꿔버립니다: + + ┌───────────────────────────────────┬─────────────────────────────────────────────┬────────────────────┐ + │ 물리 데이터 │ 계산되는 결정론 모델 │ 이전엔 뭐로 구했나 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 컨트롤밸브 Cv + Cv 커브(설치특성) │ OP(%) → 유량 관계, 밸브 게인 dQ/dOP │ Step Test 식별 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 배관 종류·구경·길이 │ ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 │ Step Test로 θ 측정 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 드럼/트레이 홀드업 체적 │ 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) │ Step Test로 τ 측정 │ + ├───────────────────────────────────┼─────────────────────────────────────────────┼────────────────────┤ + │ 플로우미터 레인지 │ 스케일링·분해능·노이즈 플로어 │ — │ + └───────────────────────────────────┴─────────────────────────────────────────────┴────────────────────┘ + + → 즉 자동운전 플랜의 B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업 = 체적/유량 으로 직접 계산됩니다. 밸브 게인도 Cv 커브 + 미분으로 나옵니다. 여기에 LLM을 넣을 이유가 없습니다. 모델기반 튜닝(SIMC/Lambda)도 이 물리모델로 바로 Kc·τI가 떨어집니다. 이 + 부분은 그냥 프로그램하세요. 제 처음 답에서 "Step Test로 식별"이라던 것의 상당 부분이 당신의 경우 불필요해집니다. + + 2. 그런데 물리 데이터가 못 주는 3가지 + + 여기가 핵심입니다. Cv·배관·유량범위는 하이드롤릭(얼마나 흐르나) 을 줍니다. 그런데 증류탑의 진짜 어려움은 거기가 아닙니다. + + (가) 분리/조성 동특성 — 당신 데이터에 없음. + 원본 문서의 "P(측류)는 15~20분으로 가장 느리다" 는 배관 이송이 아니라 트레이별 물질·열 홀드업 + 기액평형(VLE)으로 새 조성이 + 자리잡는 시간입니다. 홀드업 체적은 당신이 알지만, 상대휘발도·트레이 효율·VLE는 Cv 커브에 없습니다. 이 P 지연은 물리 + 데이터만으론 안 나오고, 단별(stage) 분리 모델이 필요합니다. → B·D는 물리로 계산되지만, P는 안 됩니다. 이게 경계선입니다. + + (나) 모델-플랜트 불일치(드리프트). Cv 커브는 깨끗한 신품 설계값입니다. 실제론 밸브 stiction·시트 마모, E-6103 파울링, 트레이 + 효율 저하로 시간에 따라 어긋납니다. 물리모델은 "어제의 진실"이고 플랜트는 오늘 다릅니다. + + (다) 목적·맥락·예외. 무엇이 "잘 도는" 건지(회수율 최대 vs 에너지 최소 vs 순도 사수), 등급 변경, 기동/정지, 계기 고장, 상류 외란 + — 정적 물리 데이터엔 전혀 없습니다. + + 3. 그래서 LLM이 실제로 하는 일 (과장 없이) + + 물리모델이 좋을수록 LLM은 제어 경로에서 빠지고 가장자리로 이동합니다. 솔직한 목록: + + ┌──────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┬───────────────────────────────────────────┐ + │ LLM 역할 │ 구체적으로 + │ 정직한 가치 │ + ├──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┼───────────────────────────────────────────┤ + │ ① 커미셔닝 보조 │ 밸브 데이터시트·Cv 커브·배관 스펙을 파싱해 결정론 엔진의 config/코드로 조립, Cv 값 정합성 점검 + │ ★★ 즉시 유용. "물리는 결정론" 철학 그대로 │ + ├──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┼───────────────────────────────────────────┤ + │ ② 데이터 정합(드리프트 진단) │ 물리예측 유량 vs 실측 잔차 계산은 수학, "이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심" + 해석·재교정 트리거는 LLM │ ★★ (나) 해결 │ + ├──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┼───────────────────────────────────────────┤ + │ ③ 소프트센서 보조 │ 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 + │ ★ (가) 보완(완전 해결 아님) │ + ├──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┼───────────────────────────────────────────┤ + │ ④ 감독형 예외 처리 │ 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장)에서 판단·완화 + │ ★★★ 물리 침묵 영역 │ + ├──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┼───────────────────────────────────────────┤ + │ ⑤ 운전원 인터페이스 │ 의도/경제목표 → SV·제약으로 번역, "왜 이렇게 도는지" 설명 + │ ★★★ 물리 침묵 영역 │ + ├──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┼───────────────────────────────────────────┤ + │ ⑥ 교차 데이터 융합 │ 알람+이벤트+랩분석+정비이력+물리잔차를 엮어 진단 + │ ★★★ 기존 MCP 도구 활용 │ + └──────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────── + ──────────────────┴───────────────────────────────────────────┘ + + 4. 핵심 원리 (한 줄) + + ▎ LLM의 가치는 물리모델 품질에 반비례합니다. 당신처럼 물리를 잘 잡을수록 LLM은 제어 산수에서 사라지고 — ③ 못 측정하는 조성, ④ + ▎ 프로그램 안 된 예외, ⑤ 사람 인터페이스, ⑥ 교차 진단, ①커미셔닝으로 옮겨갑니다. 이게 정상이고 안전한 모습입니다. + + --- + 문서로 넘어가기 전에 같이 정리하고 싶은 게 몇 가지 있습니다: + + 1. 분리/조성(가) 모델을 어디까지 갈 건가? — P 지연을 (a) 그냥 보수적 고정 τ(15~20분)로 두고 안 건드릴지, (b) 간이 트레이/홀드업 + 모델을 세울지, (c) 운전데이터 기반 경험모델로 둘지. 이게 LLM 역할 ③의 깊이를 결정합니다. + 2. 물리 데이터의 형태 — Cv 커브가 표/수식/데이터시트 PDF 중 무엇인가요? 역할 ①(LLM이 config로 조립)의 실현성이 여기 달려 + 있습니다. + 3. LLM을 "제어 보조"로 보시는지 "운전 보조(예외·인터페이스)"로 보시는지 — 위 ②④⑤⑥ 중 어디에 무게를 두실지에 따라 문서 구조가 + 달라집니다. + + 이 세 가지에 대한 생각을 들려주시면, 그걸 반영해서 플랜 문서에 섹션을 작성하겠습니다. + +✻ Baked for 1m 17s + +❯ 내가 생각하는 방향은 이거야 + 1. 결정론이든, llm이든 목표 설정값을 연산---> Experion 서버에 전달 + 2. Experion 서버에서 프로그램을 해서, 전달된 값을 화면상(Operator Station 모니터링 HMI)에 PID Loop 표시에 제안한 SP값을 표시 + 3. 운전원이 여기에 익숙해지고, 신뢰가 생긴다면, mode 변경, -> Set Point 변경 주도권 가져옴 + 4. PID LOOP의 Hunting이 심하다고 판단되는 기준을 넘으면, 매뉴얼 모드로 변경, 제어출력(OP)를 가지고 변경하면서 안정권 유지 + + 꼭 DCS 컨트롤러의 PID 제어기의 파라미터를 교정하는것이 아니어도 매뉴얼 모드에서, op 변경만 가지고도 가능할까? 하는 의문에서 + 시작된 것이 이 세션의 시작 목적이기도 함---> 당연히 안전장치(rate제한, 절대값 제한, 현재 유량 범위 감안 밸브 변동폭 제한, 기본 + 컨트롤러에 설정된 ESD, IL 동작 이 보증된 상태에서 임 + +● 이제 핵심이 명확해졌습니다. 그리고 시작 질문 — "PID 파라미터를 안 건드리고, MANUAL에서 OP만으로 안정화 가능한가?" — 에 정직하게 + 답하면: 경우에 따라 Yes, 그리고 그게 오히려 브라운필드에서 더 현실적입니다. 다만 결정적인 단서가 있습니다. + + 1. 시작 질문에 대한 직답 + + 핵심은 헌팅의 원인입니다. MANUAL+OP로 잡히는 헌팅과 안 잡히는 헌팅이 갈립니다. + + ┌───────────────────────────┬─────────────────────────┬──────────────────────────────────────────────────────────────────────── + ───────────────────────────────┐ + │ 헌팅 원인 │ MANUAL+OP로 잡히나? │ 설명 + │ + ├───────────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────────────── + ───────────────────────────────┤ + │ 튜닝 과민(Kc 과대/I 과속) │ ✅ 즉시 잡힘 │ MAN 전환 순간 컨트롤러 피드백이 빠지므로 제어기발 발진이 사라짐. OP를 + 천천히·rate제한으로 움직이면 됨 │ + ├───────────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────────────── + ───────────────────────────────┤ + │ 상류 외란(원료 헌팅 등) │ ✅ 잘 잡힘 │ 원본 문서의 "필터 + 부드럽게" 가 곧 MAN 느낌의 피드포워드. 가장 강력한 + 케이스 │ + ├───────────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────────────── + ───────────────────────────────┤ + │ 루프 간 간섭 │ ⚠️ 부분적 │ 이동/시차 조절로 완화 + │ + ├───────────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────────────── + ───────────────────────────────┤ + │ 밸브 stiction(고착) │ ❌ 안 잡힘, 오히려 악화 │ 물리적 결함. MAN에서 작게 보정하면 또 고착·점프. 액추에이터 마모만 + 늘어남 → 정비 대상 │ + └───────────────────────────┴─────────────────────────┴──────────────────────────────────────────────────────────────────────── + ───────────────────────────────┘ + + → 결론: 튜닝·외란발 헌팅은 PID 파라미터를 안 건드리고 MAN+OP로 충분히 안정화됩니다. 단, 한 가지 본질적 사실: + + ▎ MAN으로 가는 순간 DCS PID가 하던 자동 피드백 규제가 사라집니다. OP를 누가 계속 움직여줘야 합니다. 즉 당신은 "튜닝을 안 한" 게 + ▎ 아니라 컨트롤러를 DCS 밖(당신 소프트웨어)으로 옮긴 것입니다. 외부 프로그램이 느린 PI/피드포워드로 OP를 써주는, 사실상 외부 + ▎ 컨트롤러가 됩니다. + + 이건 정당한 방식이고, 실제 APC가 하는 일과 같습니다. 그리고 브라운필드에서 매력적인 이유: DCS 로직 변경·변경관리(MoC) 없이 OPC + 쓰기만으로 됩니다(당신은 이미 OPC Write가 있음). + + 2. 그래서 두 가지 모드를 구분하세요 — 당신의 1~4단계가 정확히 여기 매핑됩니다 + + ┌─────────────────────────┬───────────────────────┬──────────────────────────────────────────┬───────────┐ + │ 방식 │ 누가 빠른 규제를 하나 │ 언제 │ 당신 계획 │ + ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤ + │ (A) SP 쓰기 + AUTO 유지 │ DCS PID (그대로 둠) │ 평상시 감독·최적화. 기저 PID가 쓸만할 때 │ 1~3단계 │ + ├─────────────────────────┼───────────────────────┼──────────────────────────────────────────┼───────────┤ + │ (B) OP 쓰기 + MANUAL │ 당신 소프트웨어 │ 기저 PID가 헌팅인데 재튜닝 못/안 할 때 │ 4단계 │ + └─────────────────────────┴───────────────────────┴──────────────────────────────────────────┴───────────┘ + + (A)는 SP를 AUTO 루프에 쓰는 거라 본질적으로 bumpless하고 가장 안전합니다. (B)는 더 강력하지만 규제·bumpless·폴백을 전부 당신이 + 책임집니다. + + → 당신 직관이 정확합니다: 평상시엔 (A)로 신뢰를 쌓고, 헌팅 루프에 한해 (B)로 개입. PID 파라미터 교정은 필수가 아닙니다. + + 3. 4단계의 전제 — "헌팅 원인 진단"이 게이트 (여기가 LLM의 진짜 자리) + + 4단계가 성공하려면 MAN 전환 전에 원인을 판별해야 합니다. stiction인데 OP 핸드홀딩하면 헛수고+마모입니다. + + - 헌팅 검출/심각도 판정 = 결정론(진폭·주기·지속성, 오실레이션 인덱스). MAN 전환 트립도 결정론이어야 함(LLM 지연 불가). + - 원인 분류(튜닝 vs stiction vs 외란) = LLM + 데이터 융합의 고가치 역할. OP-PV 위상, 한계주기 파형, 상류 신호, 정비이력을 엮어 + "이건 stiction → 4단계 말고 정비 플래그" vs "외란 → 4단계 OP 핸드홀딩 유효" 판단. + + 즉 LLM은 OP를 직접 흔드는 게 아니라, "이 루프에 4단계를 적용해도 되는가"를 판정합니다. 이게 당신 비전에 LLM이 깔끔하게 들어가는 + 지점입니다. + + 4. 안전 봉투 — 당신이 든 것 + 빠진 것 + + 당신이 명시한 것(✅ 다 맞음): rate 제한 · 절대값 제한 · 현재 유량 대비 밸브 변동폭 제한 · ESD/IL 독립 보증. 특히 ESD/SIS가 BPCS + 루프의 MAN/AUTO와 무관하게 독립 동작한다는 점이 이 실험을 봉인된 안전 범위 안에 묶어줍니다 — 정확한 인식입니다. + + 추가로 반드시 넣어야 할 것: + + 1. 양방향 Bumpless — AUTO→MAN 시 현재 OP에서 시작, MAN→AUTO 복귀 시 PID가 현재 PV/OP에서 초기화(Experion 기본 지원). + 2. 컴스 워치독 → AUTO로 폴백 (중요한 미묘점): MAN에서 OP 잡고 있다가 외부 프로그램이 죽으면 루프가 마지막 OP에 규제 없이 방치됨 + → 위험. 그래서 "통신 두절 시 MAN 고수가 아니라 AUTO 복귀" 가 안전. 결국 DCS PID는 적당히 튜닝된 채로 두는 게 폴백 + 안전망입니다(바이패스해도 AUTO가 늘 안전귀항지여야 함). + 3. PV/품질 가드 — PV가 밴드 이탈하면 4단계 중단→AUTO 또는 안전 OP. + 4. 한 번에 한 루프 — 간섭 루프를 동시에 MAN 두지 않기. + 5. 운전원 최우선 오버라이드 — 항상 즉시 회수 가능. + 6. MoC/문화 — 자동 시스템이 루프를 MAN으로 돌리고 OP를 흔드는 건 현장에서 APC로 간주되어 변경관리·운전원 수용 이슈가 있음(기술 + 외 항목). + + 5. 기존 인프라와의 매핑 (이미 다 있음) + + - 1~2단계(제안 SP 표시): 루프별 advisory 섀도 포인트(예: FICQ-6101_ADV)를 WriteTagAsync로 쓰고 HMI 그룹/트렌드에 실제 SP 옆에 + 표시 → 페이스플레이트 해킹 없이 "제안 vs 실제" 비교. (Experion 디스플레이에 제안값을 어떻게 띄울지가 1~2단계의 실질 통합 과제) + - 3단계(SP 주도권): WriteTagAsync(.sp) + AUTO 유지. + - 4단계(MAN+OP): 바로 그 ControlOp(MD→MAN→OP쓰기→AUTO복귀) 가 4단계의 기본 프리미티브입니다. RestoreAuto=false로 MAN 유지하며 + OP 스트리밍 → 안정되면 AUTO 복귀, 워치독이 비상 복귀. + + --- + 문서로 가기 전에 같이 못 박을 것 세 가지: + + 1. 4단계 OP 제어법 — MAN에서 (i) OP 고정 후 가끔 보정인지, (ii) 외부 느린 PI/피드포워드로 OP를 상시 써주는지. 후자면 "외부 + 컨트롤러"를 명시적으로 설계해야 합니다(이게 사실상 미니 APC). + 2. 헌팅 임계 정의 — 진폭 몇 %/주기/지속 몇 분에서 4단계 트립? 그리고 stiction 자동 판별을 어디까지 신뢰할지(초기엔 LLM 진단 → + 운전원 확인 권장). + 3. 1~2단계 HMI 표시 방식 — advisory 섀도 포인트로 갈지, Experion 커스텀 디스플레이를 손댈지. 이게 신뢰 구축 단계의 실현성을 + 좌우합니다. + + 이 세 개에 대한 생각을 주시면, 지금까지의 컨셉·4단계 로드맵·안전봉투·LLM 역할(특히 헌팅 원인 진단)을 플랜 문서에 정식 섹션으로 + 정리하겠습니다. + +✻ Cooked for 1m 47s + +❯ sp는 PID 루프의 RSP 입력을 사용하면, 운전원이 언제든 LOCAL SP로 변경할 수 있으므로, 문제 없슴, 즉, PID LOOP의 SP를 직접 + WRITE하는게 아니고, 별도의 변수에 쓰고, 그게 RSP로 연결, 운전원은 선택권이 있슴 + +● 맞습니다. RSP(Remote SP)를 쓰는 게 정석이고, 이걸로 권한·bumpless·가역성이 한 번에 깔끔하게 풀립니다. 제가 직전에 제안한 + "advisory 섀도 포인트 + 커스텀 디스플레이"는 이제 필요 없습니다 — 더 나은 길입니다. + + 왜 이게 정답인가 + + 엔진은 루프 SP 레지스터를 절대 건드리지 않고, 자기 변수에만 씁니다. 그 변수가 RSP로 연결되고, 운전원의 LSP↔RSP(= Experion 기준 + AUTO↔CAS) 전환 스위치가 유일한 권한 손잡이가 됩니다. + + 이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다: + - 1~2단계(제안 표시): 루프는 LSP(AUTO)에 둠. 운전원은 페이스플레이트에서 "원격이 제안하는 SP 후보값"을 그냥 봄. 별도 화면 개발 + 불필요 — 네이티브 페이스플레이트가 RSP 후보를 보여줌. + - 3단계(주도권 이양): 운전원이 신뢰가 생기면 CAS로 한 번 토글 → 그 순간부터 엔진 SP 추종. 코드 추가 0. 되돌리려면 다시 LSP로 + 토글하면 끝. + + 다만 한 가지 구현 요건 — 외부 추종(tracking) + + 여기가 OPC 외부 감독의 미묘점입니다. 정식 Experion 캐스케이드라면 back-calculation 핸드셰이크로 primary가 자동 추종합니다. + 그런데 OPC로 RSP 소스에 쓰는 외부 엔진은 그 핸드셰이크를 못 받습니다. 그래서: + + ▎ 루프가 LSP(미선택) 상태일 때, 엔진은 현재 실작동 SP를 읽어 자기 출력값 = 현재 SP로 추종시켜야 합니다. 그래야 운전원이 CAS로 + ▎ 토글하는 순간 bumpless가 보장됩니다. (선택 안 됐을 때 출력을 현재값에 물려두는 표준 캐스케이드 매너를 엔진이 직접 구현) + + 이거 하나만 지키면 운전원이 언제 토글해도 충격 없습니다. + + 방어 심층 (independent layers) + + 1. 엔진 자체 가드 (rate·절대값·변동폭) + 2. DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가. + 3. 운전원 LSP/RSP 토글 (언제든 회수) + 4. ESD/IL/SIS 독립 동작 + + 구체 작업 항목 + + - DCS 구성: 루프별 감독 소스 포인트 생성 → 각 PID의 RSP/X 입력에 control connection. (엔진은 이 포인트에만 OPC write) + - OPC 타깃 변경: WriteTagAsync 대상이 ...:ficq-6101.sp → 감독 소스 포인트로만 바뀜. 쓰기 인프라는 그대로, 노드 ID만 교체. + - 모드 전환은 엔진이 안 함: AUTO↔CAS는 운전원 전유. 엔진은 SP 경로에서 모드를 절대 안 바꿈 → 더 안전. + + 한 가지 비대칭 — OP 경로(4단계)는 이만큼 깔끔하지 않음 + + RSP 트릭은 SP 경로(방식 A) 를 완벽히 커버합니다. 그런데 4단계(튜닝발 헌팅 → MAN+OP)는 다릅니다: + - CAS/RSP로 SP를 줘봐야 PID가 루프에 그대로 있으니 튜닝발 헌팅은 안 잡힘. + - 그래서 4단계는 여전히 MAN으로 내려 OP를 직접 쓰는 "무거운 개입"이고, 이전 단서(엔진이 컨트롤러가 됨 / 워치독→AUTO 폴백)가 + 그대로 유효. + - 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? 지원하면 OP + 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다. + + --- + 이제 SP 경로 설계는 깔끔하게 잠겼습니다(RSP + 외부 추종 + 운전원 토글). 직전에 띄운 세 가지 정렬 항목 중 HMI 표시 건은 RSP로 + 해결됐고, 남은 건 둘입니다: + + 1. 4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부 OP 입력" + 지원 여부. + 2. 헌팅 임계 정의 — 진폭/주기/지속 기준, stiction 자동판별 신뢰 수준. + + 이 둘에 대한 방향을 주시면 — 컨셉, RSP 기반 SP 경로, 4단계 OP 경로, 안전봉투, LLM 역할(헌팅 원인 진단 중심), 단계별 신뢰 이양 + 로드맵 — 전부 플랜 문서로 정리하겠습니다. + +✻ Worked for 1m 14s + +❯ 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? + 지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.---> 이것도 DCS + 컨트롤러에 별도의 변수를 만들고, 그걸 우리가 WRITE 하고, SWITCH 기능을 만들어서, PID LOOP OP, LLM OP 를 선택하게 하면 해결됨 + +● 정확합니다. 그 셀렉터 방식으로 OP 경로가 RSP와 완전 대칭이 됩니다. 그리고 한 가지 짚으면 — 제대로 하면 이게 기존 MAN+OP+워치독보다 더 안전해집니다. + + 대칭 구조 완성 + + ┌──────────────────┬──────────────────────┬────────────────────────┐ + │ │ SP 경로 │ OP 경로 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 감독 변수 │ RSP 소스 포인트 │ "LLM OP" 변수 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 우리가 OPC write │ 그 포인트에만 │ 그 변수에만 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 운전원 스위치 │ LSP ↔ RSP (AUTO↔CAS) │ PID-OP ↔ LLM-OP 셀렉터 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 권한 │ 운전원 전유 │ 운전원 전유 │ + └──────────────────┴──────────────────────┴────────────────────────┘ + + 쓰기 인프라(WriteTagAsync)는 그대로, 노드 ID만 바뀝니다. 양쪽 다 "엔진은 자기 변수에만 쓰고, 운전원이 스위치로 채택"하는 동일 패턴. + + 단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종 + + 이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면: + + ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 튀어나옴(bump). + + 방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로) + + 보너스 — 이게 4단계의 위험을 없앱니다 + + 이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다: + + - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 빠졌으니 사라짐. + - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐. + + → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 다시 씁니다. + + 정직한 단서 — MoC 강도가 다름 + + - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험. + - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱) + + 방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립. + + --- + 이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐: + + LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다. + + 여기에 + 헌팅 임계 정의(진폭/주기/지속). + + 이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 보수적으로 갈지 알려주세요. + +✻ Cooked for 58s + +❯ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + +✻ Cooked for 1m 47s + +❯ sp는 PID 루프의 RSP 입력을 사용하면, 운전원이 언제든 LOCAL SP로 변경할 수 있으므로, 문제 없슴, 즉, PID LOOP의 SP를 직접 WRITE하는게 아니고, 별도의 변수에 쓰고, 그게 RSP로 연결, 운전원은 선택권이 있슴 + +● 맞습니다. RSP(Remote SP)를 쓰는 게 정석이고, 이걸로 권한·bumpless·가역성이 한 번에 깔끔하게 풀립니다. 제가 직전에 제안한 "advisory 섀도 포인트 + 커스텀 디스플레이"는 이제 필요 없습니다 — 더 나은 길입니다. + + 왜 이게 정답인가 + + 엔진은 루프 SP 레지스터를 절대 건드리지 않고, 자기 변수에만 씁니다. 그 변수가 RSP로 연결되고, 운전원의 LSP↔RSP(= Experion 기준 AUTO↔CAS) 전환 스위치가 유일한 권한 손잡이가 됩니다. + + 이게 당신의 1~3단계를 하나의 운전원 소유 스위치로 압축합니다: + - 1~2단계(제안 표시): 루프는 LSP(AUTO)에 둠. 운전원은 페이스플레이트에서 "원격이 제안하는 SP 후보값"을 그냥 봄. 별도 화면 개발 불필요 — 네이티브 페이스플레이트가 RSP 후보를 보여줌. + - 3단계(주도권 이양): 운전원이 신뢰가 생기면 CAS로 한 번 토글 → 그 순간부터 엔진 SP 추종. 코드 추가 0. 되돌리려면 다시 LSP로 토글하면 끝. + + 다만 한 가지 구현 요건 — 외부 추종(tracking) + + 여기가 OPC 외부 감독의 미묘점입니다. 정식 Experion 캐스케이드라면 back-calculation 핸드셰이크로 primary가 자동 추종합니다. 그런데 OPC로 RSP 소스에 쓰는 외부 엔진은 그 핸드셰이크를 못 받습니다. 그래서: + + ▎ 루프가 LSP(미선택) 상태일 때, 엔진은 현재 실작동 SP를 읽어 자기 출력값 = 현재 SP로 추종시켜야 합니다. 그래야 운전원이 CAS로 토글하는 순간 bumpless가 보장됩니다. (선택 안 됐을 때 출력을 현재값에 물려두는 표준 캐스케이드 매너를 엔진이 직접 구현) + + 이거 하나만 지키면 운전원이 언제 토글해도 충격 없습니다. + + 방어 심층 (independent layers) + + 1. 엔진 자체 가드 (rate·절대값·변동폭) + 2. DCS의 RSP 한계 (SPHILM/SPLOLM, RSP rate) — 엔진과 무관한 독립 클램프. 공짜 안전망 한 겹 추가. + 3. 운전원 LSP/RSP 토글 (언제든 회수) + 4. ESD/IL/SIS 독립 동작 + + 구체 작업 항목 + + - DCS 구성: 루프별 감독 소스 포인트 생성 → 각 PID의 RSP/X 입력에 control connection. (엔진은 이 포인트에만 OPC write) + - OPC 타깃 변경: WriteTagAsync 대상이 ...:ficq-6101.sp → 감독 소스 포인트로만 바뀜. 쓰기 인프라는 그대로, 노드 ID만 교체. + - 모드 전환은 엔진이 안 함: AUTO↔CAS는 운전원 전유. 엔진은 SP 경로에서 모드를 절대 안 바꿈 → 더 안전. + + 한 가지 비대칭 — OP 경로(4단계)는 이만큼 깔끔하지 않음 + + RSP 트릭은 SP 경로(방식 A) 를 완벽히 커버합니다. 그런데 4단계(튜닝발 헌팅 → MAN+OP)는 다릅니다: + - CAS/RSP로 SP를 줘봐야 PID가 루프에 그대로 있으니 튜닝발 헌팅은 안 잡힘. + - 그래서 4단계는 여전히 MAN으로 내려 OP를 직접 쓰는 "무거운 개입"이고, 이전 단서(엔진이 컨트롤러가 됨 / 워치독→AUTO 폴백)가 그대로 유효. + - 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? 지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다. + + --- + 이제 SP 경로 설계는 깔끔하게 잠겼습니다(RSP + 외부 추종 + 운전원 토글). 직전에 띄운 세 가지 정렬 항목 중 HMI 표시 건은 RSP로 해결됐고, 남은 건 둘입니다: + + 1. 4단계 OP 제어법 — MAN에서 OP 고정+간헐 보정인지, 외부 느린 PI/FF로 상시 OP 작성(=미니 APC)인지. 그리고 위의 "외부 OP 입력" 지원 여부. + 2. 헌팅 임계 정의 — 진폭/주기/지속 기준, stiction 자동판별 신뢰 수준. + + 이 둘에 대한 방향을 주시면 — 컨셉, RSP 기반 SP 경로, 4단계 OP 경로, 안전봉투, LLM 역할(헌팅 원인 진단 중심), 단계별 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. + +✻ Worked for 1m 14s + +❯ 확인 필요: 당신 DCS가 RSP처럼 외부 OP 입력 + 운전원 선택 스위치(output connection/external OP)를 지원하나요? + 지원하면 OP 경로도 RSP만큼 가역적으로 만들 수 있습니다. 없으면 4단계는 MAN+OP쓰기+워치독으로 남습니다.---> 이것도 DCS 컨트롤러에 별도의 변수를 만들고, 그걸 우리가 WRITE 하고, SWITCH 기능을 만들어서, PID LOOP OP, LLM OP 를 선택하게 하면 해결됨 + +● 정확합니다. 그 셀렉터 방식으로 OP 경로가 RSP와 완전 대칭이 됩니다. 그리고 한 가지 짚으면 — 제대로 하면 이게 기존 MAN+OP+워치독보다 더 안전해집니다. + + 대칭 구조 완성 + + ┌──────────────────┬──────────────────────┬────────────────────────┐ + │ │ SP 경로 │ OP 경로 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 감독 변수 │ RSP 소스 포인트 │ "LLM OP" 변수 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 우리가 OPC write │ 그 포인트에만 │ 그 변수에만 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 운전원 스위치 │ LSP ↔ RSP (AUTO↔CAS) │ PID-OP ↔ LLM-OP 셀렉터 │ + ├──────────────────┼──────────────────────┼────────────────────────┤ + │ 권한 │ 운전원 전유 │ 운전원 전유 │ + └──────────────────┴──────────────────────┴────────────────────────┘ + + 쓰기 인프라(WriteTagAsync)는 그대로, 노드 ID만 바뀝니다. 양쪽 다 "엔진은 자기 변수에만 쓰고, 운전원이 스위치로 채택"하는 동일 패턴. + + 단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종 + + 이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면: + + ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 튀어나옴(bump). + + 방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로) + + 보너스 — 이게 4단계의 위험을 없앱니다 + + 이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다: + + - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 빠졌으니 사라짐. + - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐. + + → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 다시 씁니다. + + 정직한 단서 — MoC 강도가 다름 + + - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험. + - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱) + + 방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립. + + --- + 이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐: + + LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다. + + 여기에 + 헌팅 임계 정의(진폭/주기/지속). + + 이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 보수적으로 갈지 알려주세요. + +✻ Cooked for 58s + +❯ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다. + + 단 하나의 결정적 요건 — 비선택 PID의 back-calculation 추종 + + 이게 OP 경로의 핵심이자 RSP 추종의 쌍입니다. 셀렉터가 LLM-OP에 있을 때, 네이티브 PID를 그냥 두면: + + ▎ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 튀어나옴(bump). + + 방지책: 셀렉터가 선택된 출력(LLM-OP)을 비선택 PID로 되먹임(back-calc/initialization) 해서, PID 내부 OP가 항상 현재 밸브 위치를 추종하게 만듭니다. 그러면 windup 없음 + 양방향 bumpless. (Honeywell 계열의 BACKCALC/INIT 경로) + + 보너스 — 이게 4단계의 위험을 없앱니다 + + 이 설계는 기존 "MAN으로 내려 OP 쓰고 워치독으로 AUTO 복귀"를 대체하고 더 낫습니다: + + - MAN이 필요 없음. PID는 AUTO에 둔 채 추종만 시키고, 셀렉터로 밸브 주도권만 가져옴 → 튜닝발 헌팅은 PID가 밸브에서 빠졌으니 사라짐. + - 장애 시 무충격 자동 폴백. 엔진 죽거나 운전원이 회수하면 셀렉터가 PID-OP로 → PID가 이미 현재 밸브 위치를 추종 중이므로 그 자리에서 즉시·bumpless로 규제 재개. 기존 MAN 방식의 "규제 없이 마지막 OP에 방치" 위험이 사라짐. + + → 즉 4단계 = "MAN+OP+워치독" 이 아니라 "셀렉터를 LLM-OP로 + PID는 AUTO 추종 + 컴스두절/회수 시 PID-OP로 fail-over" 로 다시 씁니다. + + 정직한 단서 — MoC 강도가 다름 + + - RSP(SP) 경로: PID에 입력 하나만 추가. 출력경로 손 안 댐 → 저위험. + - 셀렉터(OP) 경로: PID와 최종요소(밸브) 사이에 셀렉터를 삽입 → 밸브로 가는 경로를 변경. 오설정 시 밸브에 직접 영향 → 변경관리·테스트가 더 엄격해야 함. (라이브 루프면 더더욱) + + 방어 심층은 그대로: 엔진 가드 + DCS 출력한계(OPHILM/OPLOLM) + 운전원 셀렉터 + ESD/IL/SIS 독립. + + --- + 이제 SP·OP 양 경로가 대칭으로 잠겼습니다. 남은 진짜 설계 결정은 하나뿐: + + LLM-OP 모드에서 엔진이 OP에 무엇을 쓰나? 제 권장은 — "OP 고정+간헐 보정"(규제 상실)이 아니라, 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI를 rate제한해서 OP에 작성 = 사실상 "DCS PID가 이랬으면 했던, 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다. + + 여기에 + 헌팅 임계 정의(진폭/주기/지속). + + 이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 보수적으로 갈지 알려주세요. + +✻ Cooked for 58s + +❯ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, + 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다. + + 운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless 재개. + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + 소프트웨어에서 구동". 헌팅 원인이 외란이면 FF만으로도 충분하고, 약한 PI가 잔차를 잡습니다. + + 여기에 + 헌팅 임계 정의(진폭/주기/지속). + + 이 두 개 방향만 확정하면 — 컨셉, RSP/셀렉터 대칭 구조, back-calc 추종 요건, fail-over, 안전봉투, LLM 헌팅원인 진단 역할, 신뢰 이양 로드맵 — 전부 플랜 문서로 정리하겠습니다. 권장안(외부 FF+느린 PI)으로 진행할지, "고정+간헐 보정"으로 + 보수적으로 갈지 알려주세요. + +✻ Cooked for 58s + +❯ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) /WriteTagAsync(.op) 그대로 — + 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다. + + 운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless 재개. + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + + +❯ PID가 AUTO에서 계속 적분 → 자기 OP는 밸브에 안 가는데 적분만 쌓임(windup) → PID-OP로 되돌리는 순간 누적출력이 + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 + 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / + WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다. + + 운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless 재개. + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + + - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개. + - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림. + + → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다: + + ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID 규제로 fail-safe). + + 이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 + 안전합니다.) + + 그래서 결론 — 기본값과 예외 + + ┌─────────────────────────────────────────────────┬────────────────────────────────────────┬───────────────────────────────────────────┐ + │ 루프 성격 │ 방식 │ 이유 │ + ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤ + │ 대부분 (유량·수위 등) │ MAN+OP쓰기 + DCS 데드맨→AUTO ← 당신 안 │ 단순·기존인프라·저MoC. 동결이 양성 │ + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + + - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개. + - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림. + + → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다: + + ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID 규제로 fail-safe). + + 이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, + 데드맨→AUTO면 충분히 안전합니다.) + + 그래서 결론 — 기본값과 예외 + + ┌─────────────────────────────────────────────────┬────────────────────────────────────────┬───────────────────────────────────────────┐ + │ 루프 성격 │ 방식 │ 이유 │ + ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤ + │ 대부분 (유량·수위 등) │ MAN+OP쓰기 + DCS 데드맨→AUTO ← 당신 안 │ 단순·기존인프라·저MoC. 동결이 양성 │ + ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤ + │ 빠르고 위험해 순간 규제 공백도 불가한 소수 루프 │ 선택+back-calc (PID AUTO 추종) │ 무충격 즉시 폴백 가치가 추가 MoC를 정당화 │ + └─────────────────────────────────────────────────┴────────────────────────────────────────┴───────────────────────────────────────────┘ + + 즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드. + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , 운전원의 PID_OP 선택시 같은 + 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 .op에 쓰는 건 본질적으로 + bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, back-calc 배선도 불필요. MoC도 낮습니다(밸브로 + 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 이게 더 나은 기본값입니다. + + 운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 현재 PV/OP에서 bumpless + 재개. + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + + - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개. + - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림. + + → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다: + + ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID 규제로 fail-safe). + + 이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는동결이 한동안 양성이고 + SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 안전합니다.) + + 그래서 결론 — 기본값과 예외 + + ┌─────────────────────────────────────────────────┬────────────────────────────────────────┬───────────────────────────────────────────┐ + │ 루프 성격 │ 방식 │ 이유 │ + ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤ + │ 대부분 (유량·수위 등) │ MAN+OP쓰기 + DCS 데드맨→AUTO ← 당신 안 │ 단순·기존인프라·저MoC. 동결이 양 │ + ├─────────────────────────────────────────────────┼────────────────────────────────────────┼───────────────────────────────────────────┤ + │ 빠르고 위험해 순간 규제 공백도 불가한 소수 루프 │ 선택+back-calc (PID AUTO 추종) │ 무충격 즉시 폴백 가치가 추가 MoC 정당화 │ + └─────────────────────────────────────────────────┴────────────────────────────────────────┴───────────────────────────────────────────┘ + + 즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드. + + ▎ 튀어나옴(bump).---> LLM OP 전환시 PID MODE를 MANUAL 전환하고, LLM OP 값이 PID OP를 겹쳐쓰게함(Bumpless output 가능) , + 운전원의 PID_OP 선택시 같은 값에서 시작하게 하므로, 운전원 판단에 다라 값을 변경하면됨 + +● 맞습니다. 그게 더 단순하고, 게다가 기존 인프라로 즉시 됩니다. PID를 MAN으로 내리면 적분이 멈추니 windup 자체가 없고, MAN에서 + .op에 쓰는 건 본질적으로 bumpless입니다. 이건 지금 있는 ControlOp(MD→MAN→OP쓰기) / WriteTagAsync(.op) 그대로 — 셀렉터 블록도, + back-calc 배선도 불필요. MoC도 낮습니다(밸브로 가는 출력경로를 변형하지 않고, 네이티브 MAN OP 쓰기만 씀). 제 셀렉터 제안보다 + 이게 더 나은 기본값입니다. + + 운전원 회수도 말씀대로 깔끔합니다: MAN에서 OP는 LLM이 쓴 마지막 값 → 운전원이 그 값에서 이어서 조정, 또는 AUTO로 올리면 PID가 + 현재 PV/OP에서 bumpless 재개. + + 정직하게, 이 방식이 치르는 단 하나의 비용 — 장애 모드 + + 선택+back-calc과 다른 점은 엔진이 죽었을 때입니다: + + - 선택+back-calc(PID는 AUTO 추종 유지): 폴백 시 PID가 즉시 규제 재개. + - MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림. + + → 그래서 이 방식엔 DCS 측 데드맨(comms watchdog) 한 조각이 필요합니다: + + ▎ 엔진이 heartbeat/카운터를 같이 write → DCS 로직이 "N초간 갱신 없음" 감지 시 루프를 강제로 MAN→AUTO 복귀 (안전귀항 = DCS PID + ▎ 규제로 fail-safe). + + 이게 유일하게 추가되는 DCS 측 안전 로직입니다. 작지만 필수 — 없으면 엔진 사망 시 무기한 동결입니다. (대부분의 유량/수위 루프는 + 동결이 한동안 양성이고 SIS/IL이 극단을 잡으므로, 데드맨→AUTO면 충분히 안전합니다.) + + 그래서 결론 — 기본값과 예외 + + ┌───────────────────────────────────────────┬────────────────────────────────────┬────────────────────────────────────────┐ + │ 루프 성격 │ 방식 │ 이유 │ + ├───────────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────────┤ + │ 대부분 (유량·수위 등) │ MAN+OP쓰기 + DCS 데드맨→AUTO ← │ 단순·기존인프라·저MoC. 동결이 양성 │ + │ │ 당신 안 │ │ + ├───────────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────────┤ + │ 빠르고 위험해 순간 규제 공백도 불가한 │ 선택+back-calc (PID AUTO 추종) │ 무충격 즉시 폴백 가치가 추가 MoC를 │ + │ 소수 루프 │ │ 정당화 │ + └───────────────────────────────────────────┴────────────────────────────────────┴────────────────────────────────────────┘ + + 즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드. + + --- + 이제 SP(RSP)·OP(MAN+OP쓰기+데드맨) 양 경로가 다 잠겼습니다. 남은 마지막 한 가지 — LLM-OP 모드의 제어법 — 에 대한 제 권장은: + │ 빠르고 위험해 순간 규제 공백도 불가한 │ 선택+back-calc (PID AUTO 추종) │ 무충격 즉시 폴백 가치가 추가 MoC를 │ + │ 소수 루프 │ │ 정당화 │ + └───────────────────────────────────────────┴────────────────────────────────────┴────────────────────────────────────────┘ + + 즉 당신 방식을 기본으로, 임계 루프만 선택적으로 업그레이드. + + --- + 이제 SP(RSP)·OP(MAN+OP쓰기+데드맨) 양 경로가 다 잠겼습니다. 남은 마지막 한 가지 — LLM-OP 모드의 제어법 — 에 대한 제 권장은: + + ▎ 물리모델(Cv 커브·배관) 피드포워드 + 느린 외부 PI, rate제한. 외란발 헌팅은 FF만으로 잡히고, 약한 PI가 잔차 보정. = "DCS PID가 + ▎ 이랬으면 했던 잘 튜닝된 컨트롤러를 우리 소프트웨어에서 느리게 구동". "고정+간헐 보정"은 규제를 잃어 비권장. + + 이 권장안으로 확정하면, 지금까지 합의된 전체를 플랜 문서로 정리하겠습니다: + + - 컨셉 & §0 원칙 + - RSP 기반 SP 경로 (감독소스 포인트 + 외부추종 + 운전원 LSP/RSP) + - MAN+OP 기반 OP 경로 (ControlOp + DCS 데드맨→AUTO, 선택+back-calc은 임계루프 옵션) + - 헌팅 검출(결정론) + 원인진단(LLM: 튜닝 vs stiction vs 외란) + - 안전봉투(rate·절대·변동폭·데드맨·ESD/IL/SIS 독립) + - 신뢰 이양 로드맵(1~4단계) + - LLM 역할(물리 결정론 위의 진단·예외·인터페이스·커미셔닝) + + 권장 제어법(FF+느린 PI)으로 갈지 알려주시면 바로 문서로 정리하겠습니다. (보수적으로 "고정+간헐 보정"을 원하시면 그걸로 + 반영합니다.) + +✻ Crunched for 58s + +❯ MAN+OP쓰기(이 방식): 엔진이 죽으면 루프가 MAN에 OP 동결 + 규제 없음 상태로 방치. 죽은 엔진은 스스로 AUTO로 못 올림.----> 엔진 + WATCHDOG은 당연히 만들어야 할 것이고, WATCHDOG 발생시 , CONTROLLER LOGIC -> PID AUTO MODE 로 하면 해결됨--> OP가 LLM_OP에서 + 시작하므로, PID 적산 IMPULSE 출력도 없을 것임, PID LOOP 는 BUMPLESS OUTPUT 설정 되어 있슴 + +● 정확합니다. 그러면 완전히 닫힙니다. DCS PID가 bumpless output으로 설정돼 있으니, 워치독→AUTO 전환 시 적분항이 현재 + OP(=LLM_OP)에서 back-calc 초기화 → 적분 임펄스 없이 그 자리에서 규제 재개. 셀렉터+back-calc 없이도 동일한 "무충격 즉시 폴백"을 + 얻습니다 — 그래서 기본값으로 셀렉터는 아예 불필요합니다. + + 확인용 두 가지만 (반론 아님, 설정 체크): + + 1. MAN 중 SP 추종/홀드 설정 — 폴백 후 AUTO가 어떤 LSP로 규제할지가 여기서 정해집니다. SP가 PV 추종이면 전환 시점 PV에 머물고, + SP 홀드면 운전원 목표값으로 복귀(출력은 여전히 bumpless, PI가 천천히 끌고 감). 어느 쪽이 의도인지만 맞춰두면 됩니다. + 2. 이 시나리오 특유의 정직한 단서 — 우리가 OP를 가져온 이유가 그 PID가 헌팅이라서입니다. 따라서 폴백은 헌팅하던 그 PID로 + 되돌아갑니다 → 안전(규제됨, SIS가 극단 차단)하지만 엔진 복구/운전원 개입 전까지 헌팅이 재개됩니다. 위험은 아니고 단지 차선 — + 문서에 명시만 해두면 됩니다. + + --- + 이로써 양 경로가 완전히 잠겼습니다: + - SP: 감독소스 → RSP, 외부추종, 운전원 LSP/RSP 토글 + - OP: MAN + .op write, 엔진 워치독 + DCS 컨트롤러 로직이 stale 감지 → MAN→AUTO(bumpless) 폴백 + + 남은 마지막 결정은 LLM-OP 모드의 제어법 하나뿐입니다. 제 권장(재확인): + + ▎ 물리 FF(Cv 커브·배관) + 느린 외부 PI, rate제한 — 외란발 헌팅은 FF로, 잔차는 약한 PI로. "고정+간헐 보정"은 규제 상실이라 + ▎ 비권장. + + 이걸로 확정해도 될까요? 확정 주시면 — 컨셉/§0 원칙, RSP SP경로, MAN+OP OP경로(+데드맨 폴백), 헌팅 검출(결정론)+원인진단(LLM), + 안전봉투, 1~4단계 신뢰이양, LLM 역할 — 전부 측류추출-자동운전-플랜.md에 정식 섹션으로 추가하겠습니다. + +✻ Crunched for 44s + +❯ 물리 FF(Cv 커브·배관) + 느린 외부 PI, rate제한 — 외란발 헌팅은 FF로, 잔차는 약한 PI로. "고정+간헐 보정"은 규제 상실이라 + ▎ 비권장. --> 나의 이해가 부족함 좀 더 명확하게 설명해주세요 + +● 좋습니다, 천천히 직관부터 쌓아가겠습니다. 핵심 상황은 이겁니다: MAN으로 내린 순간부터 밸브 개도(OP%)를 매 순간 "우리"가 정해야 + 합니다. DCS PID가 더 이상 규제 안 하니까요. 그럼 OP를 무슨 근거로 정하나? 두 가지 정보원을 씁니다. + + 1. 먼저 운전 비유 (정속주행 = cruise control) + + 차로 100km/h를 유지한다고 합시다. + + ┌────────────────┬────────────────────────────────────────────────────────────────────────┬────────────────────────────────┐ + │ 방법 │ 하는 일 │ 결과 │ + ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤ + │ 피드포워드(FF) │ 언덕이 보이면 차가 느려지기 전에 미리 가속페달을 더 밟음 (이 언덕엔 │ 속도가 거의 안 떨어짐 │ + │ │ 대략 이만큼 필요하다는 걸 앎) │ │ + ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤ + │ 피드백(PI) │ 계기판이 "98km/h, 2 부족"을 보여주면 그만큼만 살짝 더 밟아 보정 │ 잔차 제거 │ + ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤ + │ 고정+간헐 보정 │ 페달을 한 위치에 고정, 30초마다 한 번씩만 조정 │ 언덕에서 푹 꺼졌다가 뒤늦게 │ + │ │ │ 복구 → 출렁임 │ + ├────────────────┼────────────────────────────────────────────────────────────────────────┼────────────────────────────────┤ + │ rate 제한 │ 페달을 확 밟지 않고 부드럽게 밟음 │ 차가 안 울컥거림 │ + └────────────────┴────────────────────────────────────────────────────────────────────────┴────────────────────────────────┘ + + FF + PI = 사실상 크루즈컨트롤. 언덕을 미리 보고(FF) + 계기판 잔차를 다듬는다(PI). 이게 우리가 OP에 쓰려는 제어법입니다. + + 2. 이 플랜트로 매핑 + + - "언덕"(외란) = 원료 F의 헌팅(±5%). 원본 문서의 그 문제. + - "이 속도엔 가스 이만큼"(물리 지식) = 밸브 Cv 커브. 원하는 유량 Q와 현재 차압 ΔP를 알면 필요한 개도를 직접 계산: 개도% = Cv⁻¹( + Q / √(ΔP/SG) ). 측정 오차가 쌓이길 기다릴 필요 없이 바로 정답 개도를 압니다. + + FF가 하는 일 (외란발 헌팅을 잡는 핵심) + + 1. 원료 F를 필터링(Lag 300s, 플랜의 그것) → F_clean (헌팅 제거된 부드러운 신호) + 2. 물질수지로 목표 발출유량 계산 (B/D/P) + 3. Cv 커브로 각 목표유량 → 정확한 OP% 계산 + 4. 플랜의 시간상수(B 1~2분 / D 5분 / P 15~20분)로 부드럽게 그 OP로 이동 + + → F가 출렁여도 우리는 필터링된 F로 미리 정답 OP를 계산해 부드럽게 가니까, 밸브가 홱홱 안 움직임 → 헌팅 소멸. (옛 PID는 F + 출렁임을 그대로 받아 밸브를 잡아채서 헌팅했던 것) + + PI가 하는 일 (FF의 오차 청소) + + Cv 커브는 신품 설계값입니다. 밸브 마모·파울링·ΔP 부정확 때문에 FF만으론 살짝 빗나갑니다. 예: 목표 50인데 실제 48. + + → 느린 PI가 잔차(+2)를 보고 OP를 천천히 조금 더 열어 50으로 맞춤. + "느리게/약하게" 인 이유: ①헌팅을 다시 일으킬 만큼 세게 잡아채면 안 됨 ②큰 일은 FF가 이미 했으니 PI는 자투리만 다듬으면 됨. + + 3. 한 줄 공식 + + OP = FF(Cv·배관 물리로 계산한 예측 개도) ← 큰 움직임, 미리, 부드럽게 + + PI(설정값 − 실측 PV, 느린 게인) ← 작은 잔차만 청소 + → rate 제한 + 절대 min/max + 변동폭 제한 ← 안전 봉투 + + 4. 왜 "고정+간헐 보정"은 비권장인가 + + OP를 고정해두고 가끔만 건드리면, 건드리는 사이사이엔 능동 규제가 0입니다. F가 변하거나 ΔP가 드리프트하면 PV가 흘러가는데 다음 + 보정 때까지 아무도 안 잡습니다 → PV 드리프트. 즉 피드백 규제를 통째로 버리는 것. 느린 PI라도 연속적으로 잡아주는 것과 + 근본적으로 다릅니다. (= 크루즈컨트롤 vs 페달 고정) + + 5. 이미 만든 플랜과의 연결 + + 새 개념이 아닙니다: + - FF = 우리가 설계한 결정론 보상 엔진 (필터 → 물질수지 → Cv → OP, 시간상수 적용) 그대로 + - PI = 그 위에 얹는 작은 피드백 트림 하나 추가 + + F(헌팅) ─filter→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐ + ├→ OP → rate제한 → 밸브 + 설정값 − 실측PV ───────────── 느린 PI ──────────→ OP_pi ┘ + + --- + 정리하면: FF는 "물리로 미리 계산한 부드러운 큰 움직임"(헌팅 차단), PI는 "모델 오차만 천천히 청소하는 작은 피드백"(정확도 확보). + 둘이 상호보완이고, 고정+간헐은 피드백을 버려서 PV가 드리프트하므로 안 씁니다. + + 이 설명으로 명확해지셨나요? 막히는 부분 있으면 더 풀어드리고, 괜찮으시면 이 제어법을 확정으로 플랜 문서에 반영하겠습니다. + +✻ Cooked for 57s + +❯ 이해됐어, 이제 플랜 문서에 반영해줘 + +● 전체 논의를 통합해 플랜 문서를 개정하겠습니다. 먼저 현재 내용을 확인합니다. + + Read 1 file (ctrl+o to expand) + +● 전체 논의를 통합해 문서를 전면 개정하겠습니다. + +● Write(측류추출-자동운전-플랜.md) + +───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── + Overwrite file + 측류추출-자동운전-플랜.md +╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ + 1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜 + 2 + 3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서 + 4 -> **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록. + 4 +> 구현하되, **운전원이 단계적으로 신뢰를 쌓아 권한을 넘기는** 감독제어(Supervisory Control) 형태의 + 5 +> 자동운전을 설계한다. 결정론 엔진이 제어하고, 로컬 LLM(vLLM Qwen)은 그 위에서 진단·예외·인터페이스를 맡는다. + 6 > + 6 -> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태. + 7 +> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의 완료본. 코드 미작성 상태. + 8 + 8 -*작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 9 +*작성일: 2026-05-22 / 갱신: 2026-05-22 (논의 합의 반영) / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 10 + 11 --- + 12 + 12 -## 0. 핵심 원칙 (가장 중요) + 13 +## 0. 핵심 원칙 + 14 + 14 -**LLM을 빠른 제어 루프에 넣지 않는다.** + 15 +**LLM을 빠른 제어 루프에 넣지 않는다.** 빠른 보상은 결정론 엔진(코드)이, LLM은 분/이벤트 단위 진단·튜닝·인터페이스만. + 16 + 16 -`측류추출-시간지연-적용방식.md`가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야 + 17 -하는 빠른 루프다. 여기에 LLM을 직접 넣으면: + 18 - + 17 | 문제 | 영향 | + 18 |------|------| + 19 | 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 | + 20 | 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 | + 23 -| 환각 | 잘못된 SV 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 | + 21 +| 환각 | 잘못된 값 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 | + 22 + 25 -→ **결론**: 빠른 보상은 **결정론 엔진(코드)** 이 담당하고, **LLM은 분 단위 감독·튜닝·조언만** 한다. + 26 -이것이 LLM을 실공정에 붙이는 유일하게 안전한 형태다. + 23 +따름정리: **헌팅 검출·MAN 전환·OP 산출 등 안전·실시간 판단은 모두 결정론.** LLM은 그 트립을 *설명*하고 + 24 +*원인을 진단*할 뿐, 직접 트립시키거나 OP를 쓰지 않는다. + 25 + 26 --- + 27 + 30 -## 1. 2-Plane 아키텍처 + 28 +## 1. 물리 결정론 vs LLM — 역할 경계 (이 플랜의 출발점) + 29 + 32 -``` + 33 -┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위, 느림) ───────────────┐ + 34 -│ · Step Test 곡선 분석 → θ(데드타임)·τ(시상수) 자동 추출 │ + 35 -│ · 파라미터(K, τ, 한계값) 튜닝 제안 │ + 36 -│ · 헌팅 / Flooding / 순도 드리프트 이상 감지·자연어 설명 │ + 37 -│ · 운전원 Q&A ("왜 제품밸브가 천천히 열려요?") │ + 38 -│ │ ※ 밸브 직접 쓰기 금지. "엔진 파라미터 저장소"에만 │ + 39 -│ │ 제안 → 운전원 승인 후 반영 │ + 40 -├─────────┼──────────────────────────────────────────────────────┤ + 41 -│ 🔒 안전 가드 레이어 (신규, 0순위) ─ 모든 쓰기가 강제 통과 │ + 42 -│ hard min/max · 변화율(rate) 제한 · dead band · 태그 화이트 │ + 43 -│ 리스트 · 통신두절→안전SV 폴백 · 전 쓰기 감사로그 │ + 44 -├─────────┼──────────────────────────────────────────────────────┤ + 45 -│ Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초 단위) │ + 46 -│ Realtime 구독으로 F(원료유량) 읽기 │ + 47 -│ → Lag(τ=300s) 필터로 헌팅 제거 → F_clean │ + 48 -│ → B_sv(데드타임 1~2분) / D_sv(5분) / P_sv(15~20분) 계산 │ + 49 -│ → 가드 통과 후 WriteTagAsync / ControlOp 로 쓰기 │ + 50 -└────────────────────────────────────────────────────────────────┘ + 51 - 읽기: ExperionRealtimeService · query_pv_history + 52 - 쓰기: IExperionOpcWriteClient (가드 레이어 경유 필수) + 53 -``` + 30 +운영자가 **밸브 사이즈·배관 종류·컨트롤밸브 Cv 값/Cv 커브·플로우미터 유량범위** 등 물리 데이터를 + 31 +보유하면, 제어 수학의 상당 부분이 *데이터 피팅 없이 계산*된다. + 32 + 55 ---- + 33 +### 1.1 물리 데이터로 결정론화되는 것 (LLM 불필요) + 34 +| 물리 데이터 | 계산되는 모델 | + 35 +|------------|--------------| + 36 +| Cv 커브(설치특성) | OP(%) → 유량 관계, 밸브 게인 dQ/dOP | + 37 +| 배관 종류·구경·길이 | ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 | + 38 +| 드럼/트레이 홀드업 체적 | 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) | + 39 +| 플로우미터 레인지 | 스케일링·분해능·노이즈 플로어 | + 40 + 57 -## 2. 보상 제어 수식 (Plane 1 — 결정론, LLM 아님) + 41 +→ 자동운전의 **B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업(=체적/유량)으로 직접 계산**된다. + 42 +밸브 게인도 Cv 커브 미분으로 나온다. **이 부분은 그냥 프로그램한다.** + 43 + 59 -원본 문서 §2·§4 기준. + 44 +### 1.2 물리 데이터가 못 주는 것 + 45 +- **(가) 분리/조성 동특성** — P(측류)의 "15~20분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(VLE)으로 + 46 + 새 조성이 자리잡는 시간. 상대휘발도·트레이 효율·VLE는 Cv 커브에 없음. → **B·D는 물리로 계산되지만 P는 별도 모델 필요.** + 47 +- **(나) 모델-플랜트 불일치(드리프트)** — Cv 커브는 신품 설계값. 밸브 stiction·마모, E-6103 파울링, 트레이 효율 저하로 시 + +간에 따라 어긋남. + 48 +- **(다) 목적·맥락·예외** — 회수율 최대 vs 에너지 최소 vs 순도 사수, 등급변경, 기동/정지, 계기고장, 상류 외란. + 49 + 61 -- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])` + 62 -- **데드타임(Dead Time)**: 링버퍼로 N틱 지연 + 63 -- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** 1개 (원본 §4.1 "1순위 대책") + 50 +### 1.3 따라서 LLM이 실제로 하는 일 + 51 +> **LLM의 가치는 물리모델 품질에 반비례.** 물리를 잘 잡을수록 LLM은 제어 산수에서 빠지고 가장자리로 이동. + 52 + 65 -| MV | 제어 대상 | τ / 데드타임 | 목적 | + 66 -|----|----------|-------------|------| + 67 -| B | 하부 제거량 | 1~2분 | 탑 넘침(Flooding) 즉시 방지 | + 68 -| D/R | 상부 제거량/환류 | 5분 | 압력/조성 안정화 | + 69 -| P | 측류 제품 추출 | 15~20분 | 초고순도 PGMEA 품질 보호 (가장 보수적) | + 70 -| S | 리보일러 스팀 | 가장 빠름(수초~수분) | 하부 온도 직결 | + 53 +| LLM 역할 | 구체 | 가치 | + 54 +|---------|------|------| + 55 +| ① 커미셔닝 보조 | 밸브 데이터시트·Cv 커브·배관 스펙 파싱 → 엔진 config/코드로 조립, 정합성 점검 | ★★ | + 56 +| ② 드리프트 진단((나)) | 물리예측 vs 실측 잔차는 수학, *"이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심"* 해석·재교정 트리 + +거는 LLM | ★★ | + 57 +| ③ 소프트센서 보조((가)) | 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 | ★ | + 58 +| ④ 감독형 예외 처리((다)) | 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장) 판단·완화 | ★★★ | + 59 +| ⑤ 운전원 인터페이스 | 의도/경제목표 → SV·제약 번역, "왜 이렇게 도는지" 설명 | ★★★ | + 60 +| ⑥ 교차 데이터 융합 | 알람+이벤트+랩분석+정비이력+물리잔차 엮어 진단 (기존 MCP 도구) | ★★★ | + 61 +| ⑦ 헌팅 원인 진단 | 튜닝 vs stiction vs 외란 판별 → 4단계(OP 개입) 적용 여부 게이트 (§4.3) | ★★★ | + 62 + 72 -추가 안전요소(원본 §4.2/§4.3): 각 PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑). + 73 - + 63 --- + 64 + 76 -## 3. 현 시스템에서 확인된 능력 (재사용 자산) + 65 +## 2. 감독제어 아키텍처 — 운전원이 권한을 쥔다 + 66 + 78 -### 3.1 쓰기 (이미 구현됨) + 79 -| 기능 | 구현 | 엔드포인트 | + 80 -|------|------|-----------| + 81 -| SP/OP 직접 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, value)` | `POST /api/experion/write` | + 82 -| MAN/AUTO 모드 | `SetModeAsync(cfg, nodeId, "MAN"\|"AUTO")` | `POST /api/experion/mode` | + 83 -| 통합 제어 (MD→MAN → OP쓰기 → AUTO복귀) | `ControlOp(TagName, OpValue, RestoreAuto)` | `POST /api/experion/control` | + 84 -| UI | "OPC UA Write" 탭 (#15) | `index.html #pane-write` | + 67 +핵심 설계 사상: **엔진은 PID 루프의 SP/OP 레지스터를 직접 덮어쓰지 않는다.** 별도 감독변수에 쓰고, + 68 +**운전원이 스위치로 채택**한다. 권한 손잡이는 항상 운전원에게 있다. SP 경로와 OP 경로가 대칭이다. + 69 + 86 -### 3.2 읽기 + 87 -- `ExperionRealtimeService` — 실시간 PV 구독 (`AddMonitoredItemAsync`), `IHostedService` + 88 -- `query_pv_history` (MCP) / `ExperionHistoryController` — Step Test용 시계열 + 70 +| | SP 경로 (평상시) | OP 경로 (헌팅 시) | + 71 +|---|------------------|-------------------| + 72 +| 엔진이 쓰는 곳 | RSP 소스 포인트 (별도 변수) | `.op` (PID MAN 상태에서) | + 73 +| 운전원 스위치 | **LSP ↔ RSP** (Local ↔ Remote SP = AUTO↔CAS) | **PID MODE: AUTO ↔ MAN** | + 74 +| 빠른 규제 담당 | DCS PID (그대로 둠) | 엔진(소프트웨어 컨트롤러) | + 75 +| 폴백(엔진 사망) | 운전원이 LSP로 토글 | 데드맨 → MAN→AUTO (bumpless) | + 76 +| 적용 | 1~3단계 (신뢰 이양) | 4단계 (튜닝발 헌팅 한정) | + 77 + 90 -### 3.3 백그라운드 서비스 패턴 + 91 -- `IHostedService`/`AddHostedService` 이미 Realtime·History·OpcServer·Mcp에서 사용 중 + 92 - → 신규 `AutoRunService : BackgroundService`가 기존 패턴에 그대로 들어감 + 78 +### 2.1 SP 경로 — RSP(Remote Setpoint) + 79 +- 엔진은 **루프 SP를 절대 안 건드림.** 자기 감독소스 포인트에만 OPC write → 그 포인트가 PID의 RSP/X 입력에 control connec + +tion. + 80 +- 운전원의 **LSP/RSP 토글이 유일한 권한 손잡이.** RSP면 엔진 SP 추종, LSP면 운전원 수동 — 언제든 가역. + 81 +- **bumpless 요건(중요)**: OPC 외부 감독은 DCS의 back-calculation 핸드셰이크를 못 받음. + 82 + → 루프가 LSP(미선택)일 때 엔진이 **현재 실작동 SP를 읽어 자기 출력=현재 SP로 추종**시켜야 함. + 83 + 그래야 운전원이 RSP로 토글하는 순간 충격 없음. + 84 +- **공짜 안전망**: DCS RSP 한계(SPHILM/SPLOLM, RSP rate)가 엔진과 독립으로 한 겹 더. + 85 +- **장점**: 1~2단계(제안 표시)는 페이스플레이트가 RSP 후보값을 네이티브로 보여줌 → **별도 화면 개발 불필요.** + 86 + 94 -### 3.4 LLM 감독용 MCP 도구 (기존) + 95 -- `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, + 96 - `summarize_events`, `generate_status_report`, ReAct 에이전트 모드(구현됨) + 87 +### 2.2 OP 경로 — MAN + OP 쓰기 (튜닝발 헌팅 전용) + 88 +- 평상시 RSP로는 **튜닝발 헌팅이 안 잡힘**(PID가 루프에 그대로). 그래서 헌팅 루프에 한해 OP를 직접 잡는다. + 89 +- 방식: PID를 **MAN**으로 → 엔진이 `.op`에 직접 write. **MAN이라 적분이 멈춰 windup 없음, OP 쓰기는 본질적 bumpless.** + 90 + 기존 `ControlOp`(MD→MAN→OP쓰기) / `WriteTagAsync(.op)` 그대로 사용 → **신규 DCS 구성 불필요, 저MoC.** + 91 +- **운전원 회수**: MAN의 OP는 엔진이 쓴 마지막 값 → 운전원이 그 값에서 이어 조정, 또는 AUTO로 올림. + 92 +- **폴백(엔진 사망)**: 엔진 워치독 + **DCS 컨트롤러 로직이 stale(N초 갱신 없음) 감지 → MAN→AUTO 강제 복귀.** + 93 + PID가 bumpless output 설정이라 **현재 OP(=마지막 LLM_OP)에서 적분 임펄스 없이 규제 재개.** + 94 + - *정직한 단서*: 폴백은 "헌팅하던 그 PID"로 돌아감 → 안전(규제됨, SIS가 극단 차단)하나 **엔진 복구 전까지 헌팅 재개.** + +위험 아님, 차선. + 95 + - 설정 확인: MAN 중 SP 추종/홀드 → 폴백 후 어떤 LSP로 규제할지 결정. + 96 +- **상위 옵션(임계 루프 한정)**: *순간 규제 공백도 불가*한 빠른 루프는 선택+back-calc(PID는 AUTO 추종 유지, 무충격 즉시 + +폴백)을 쓰되, 밸브 출력경로를 변형하므로 MoC가 더 엄격. 기본값은 위 MAN 방식. + 97 + 98 --- + 99 + 100 -## 4. ⚠️ 안전 관련 발견 사항 (자동운전 전 반드시 처리) + 100 +## 3. LLM-OP 모드의 제어법 — FF + 느린 PI (rate 제한) + 101 + 102 -1. **쓰기 경로에 안전 가드가 0건.** `WriteTagAsync`는 들어온 double을 그대로 쓴다 — + 103 - min/max 클램프·rate limit·범위 검증·변화율 제한 전무. 사람이 UI에서 손으로 쓸 땐 운전원이 + 104 - 최종 안전망이지만, **엔진이 자동으로 쓰는 순간 안전망이 사라진다.** → **0순위: 가드 레이어.** + 105 -2. **현재 LLM(MCP)에는 쓰기 도구가 없다.** 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는" + 106 - 상태가 유일한 안전 경계. 자동운전을 붙이면 이 경계를 넘게 됨 → 신중한 권한 설계 필요. + 107 -3. **`ask_iiot_llm`(vLLM 직접 질의) MCP 도구가 빈 응답.** 2회 시도 모두 `(응답 없음)`. + 108 - vLLM 엔드포인트 상태/연결 점검 필요. (단 `find_tags`/`trace_connections`는 정상 동작.) + 102 +OP 경로로 개입한 동안 엔진이 매 순간 OP에 무엇을 쓰는가. **크루즈컨트롤과 동일 구조**: 미리 예측(FF) + 잔차 청소(PI). + 103 + 104 +``` + 105 +F(헌팅) ─Lag필터→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐ + 106 + ├→ OP → rate제한 → 절대/변동폭 클램프 → 밸브 + 107 +설정값 − 실측PV ───────────────── 느린 PI ───────→ OP_pi ┘ + 108 +``` + 109 + + 110 +- **FF (피드포워드)**: 물리로 *미리* 정답 개도 계산. `개도% = Cv⁻¹( Q / √(ΔP/SG) )`. + 111 + 필터링된 F_clean로 목표유량(B/D/P)을 물질수지로 구하고 → Cv 커브로 OP 계산 → §5 시간상수로 부드럽게 이동. + 112 + **외란발 헌팅을 잡는 주역**(반응이 아니라 예측이라 밸브가 안 채인다). + 113 +- **PI (느린 피드백)**: Cv 커브는 신품값이라 마모·파울링·ΔP 부정확으로 살짝 빗나감. 잔차(SP−PV)를 + 114 + **느리게/약하게** 보정. 약한 이유: ①헌팅 재유발 방지 ②큰 일은 FF가 이미 함. + 115 +- **rate 제한**: OP 변화율 제한으로 밸브 부드럽게. + 116 +- **비채택: "고정+간헐 보정"** — 보정 사이 능동 규제 0 → 외란 시 PV 드리프트(피드백 상실). 사용 안 함. + 117 +- **연결**: FF = §5 결정론 보상 엔진 그대로 + 그 위에 작은 PI 트림 하나. + 118 + + 119 --- + 120 + 112 -## 5. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections` 기반) + 121 +## 4. 헌팅 검출 & 원인 진단 — 4단계의 게이트 + 122 + 114 -`trace_connections`가 돌려준 원료 경로: + 115 -``` + 116 -P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 + 117 -``` + 123 +### 4.1 검출 (결정론) + 124 +- 오실레이션 인덱스: 진폭·주기·지속성. 임계 초과(예: 진폭 > 범위의 X%, 주기 안정, N분 지속) 시 트립. + 125 +- **MAN 전환 트립은 결정론**(LLM 지연 불가). LLM은 트립을 설명만. + 126 + 119 -| # | 경로 | 조작변수(MV)/제어 | 유량 | 온도 | 수위/압력 | τ | + 120 -|---|------|------------------|------|------|----------|---| + 121 -| **F** | 원료 투입 | **FICQ-6101**(SP/OP)→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력신호(Lag 300s) | + 122 -| **S** | 리보일러 스팀 | 스팀밸브(리보일러 듀티) | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름 + - | + 123 -| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1~2분 | + 124 -| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), LICA-6113, + - PI-6111(진공), PICA-6111 | 5분 | + 125 -| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) | 15~20분 + -| + 127 +### 4.2 원인 분류 (LLM + 데이터 융합) — §1.3-⑦ + 128 +| 원인 | 4단계(MAN+OP)로 잡히나 | 조치 | + 129 +|------|----------------------|------| + 130 +| 튜닝 과민 | ✅ 즉시 | MAN 전환 → FF+PI로 OP 핸드홀딩 | + 131 +| 상류 외란 | ✅ 잘 잡힘 | 동일(FF가 주역) | + 132 +| 루프 간섭 | ⚠️ 부분 | 시차 조절로 완화 | + 133 +| **밸브 stiction** | ❌ 악화 | **정비 플래그.** OP 핸드홀딩 금지(마모만 늘어남) | + 134 + 127 -- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1) + 128 -- 현재 운전 데이터 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종 중, 진공압 PICA-6111 30.4 → 탑 가동 중으로 추정 + 135 +→ LLM이 OP-PV 위상·한계주기 파형·상류 신호·정비이력을 엮어 *"이건 stiction → 4단계 말고 정비"* vs + 136 +*"외란 → 4단계 유효"* 판정. **초기엔 LLM 진단 → 운전원 확인 권장.** + 137 + 130 -### 5.1 미완료 매핑 (담당 구분) + 131 -- **P(측류 제품 추출) 경로 매핑 — 사용자가 직접 진행 예정** (본 플랜에서는 보류) + 132 -- B(하부 제거) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 + 133 - C-6111 `trace_connections downstream`로 보강 가능 (착수 시 확정) + 138 +--- + 139 + 140 +## 5. 보상 제어 수식 (결정론, FF의 본체) + 141 + + 142 +원본 문서 §2·§4 기준. + 143 +- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])` + 144 +- **데드타임**: 링버퍼로 N틱 지연 + 145 +- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** (원본 §4.1) + 146 + + 147 +| MV | 제어 대상 | τ / 데드타임 | 근거 | 목적 | + 148 +|----|----------|-------------|------|------| + 149 +| B | 하부 제거량 | 1~2분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 | + 150 +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 | + 151 +| P | 측류 제품 추출 | 15~20분 | **분리/조성 동특성(§1.2-가, 별도 모델)** | 초고순도 PGMEA 품질 보호 | + 152 +| S | 리보일러 스팀 | 가장 빠름 | 압력 즉시 전달 | 하부 온도 직결 | + 153 + + 154 +추가(원본 §4.2/§4.3): PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑). + 155 + + 156 --- + 157 + 137 -## 6. 선택사항 (의사결정 대기) + 158 +## 6. 안전 봉투 (Safety Envelope) + 159 + 139 -### 6.1 시작 지점 — "무엇부터 구현하나" + 140 -| 옵션 | 내용 | 비고 | + 141 -|------|------|------| + 142 -| **A. 안전 가드 레이어 먼저** | 쓰기 경로에 클램프·변화율·dead band·화이트리스트·감사로그 추가 | **권장**. 자동운전 전제 + -조건이며 수동 쓰기도 즉시 안전해짐 | + 143 -| B. 결정론 보상 엔진(폐루프) | `AutoRunService`: F구독→Lag/데드타임→B/D/P SV 계산→가드 경유 쓰기 | 실제 자동운전 핵심 | + 144 -| C. 조언형(개루프)부터 | 엔진은 권고 SV만 계산·표시, 쓰기는 운전원이 클릭 승인 | 로직 안전검증 후 폐루프 전환 | + 145 -| D. 시뮬레이터 먼저 | FOPDT 증류탑 디지털 트윈으로 실플랜트 전 검증 | 현 브랜치 `sim/...` 와 자연스러움 | + 160 +엔진의 모든 쓰기는 아래를 강제 통과한다(다층 독립 방어): + 161 + 147 -### 6.2 LLM 개입 수준 — "LLM 권한 어디까지" + 148 -| 옵션 | 내용 | 비고 | + 149 -|------|------|------| + 150 -| **가. 감독·조언만** | Step Test 분석·이상 설명·파라미터 제안만. 밸브/쓰기 절대 안 함 | **권장**. 가장 안전 | + 151 -| 나. 파라미터 쓰기(승인 게이트) | LLM이 K·τ 등 엔진 파라미터 변경 제안 → 운전원 승인 후 반영. 밸브 직접 제어는 여전히 엔 + -진만 | 적응 튜닝 가능 | + 152 -| 다. MCP 쓰기 도구 추가 | LLM이 MCP로 직접 SV/모드 쓰기(가드 경유) | 유연하나 위험 큼 — 신중 적용 | + 162 +1. **엔진 가드**: rate 제한 · 절대 min/max · **현재 유량범위 대비 밸브 변동폭 제한** · 태그 화이트리스트 · 전 쓰기 감사로 + +그 + 163 +2. **DCS 측 한계**: RSP 한계(SPHILM/SPLOLM), 출력 한계(OPHILM/OPLOLM) — 엔진과 독립 + 164 +3. **운전원 스위치**: LSP/RSP, AUTO/MAN — 언제든 즉시 회수 (최우선) + 165 +4. **데드맨/워치독**: 엔진 stale → SP경로는 운전원 LSP 회수, OP경로는 DCS 로직이 MAN→AUTO(bumpless) 폴백 + 166 +5. **ESD/IL/SIS 독립**: BPCS 루프의 MAN/AUTO·LSP/RSP와 무관하게 최종요소에 독립 동작 → 실험을 봉인된 안전 범위에 묶음 + 167 +6. **한 번에 한 루프**: 간섭 루프 동시 MAN 금지 + 168 +7. **양방향 bumpless**: 모든 전환에서 충격 없음(PID bumpless output + 엔진 추종) + 169 + 154 -> 현재 권장 조합: **6.1-A (가드 먼저) + 6.2-가 (LLM 감독만)** 로 시작 → 검증 후 단계적 확장. + 170 +> ⚠️ **MoC/문화**: 자동 시스템이 SP/OP를 조작하는 것은 현장에서 APC로 간주 → 변경관리·운전원 수용 절차 필요(기술 외 항목) + +. + 171 + 172 --- + 173 + 158 -## 7. 단계별 로드맵 + 174 +## 7. 단계별 신뢰 이양 로드맵 (운전원 비전) + 175 + 160 -- **Phase 0 — 안전 가드 레이어**: 쓰기 경로 클램프/rate/dead band/화이트리스트/폴백/감사로그. (전제조건) + 161 -- **Phase A — 조언형(개루프)**: 보상 엔진이 권고 SV 계산·대시보드 표시 + LLM Step Test 분석기. + 162 - DCS 쓰기는 운전원 수동 승인. 위험 최소. + 163 -- **Phase B — 감독형 폐루프**: `AutoRunService`가 가드 안에서 SV 자동 쓰기. LLM은 파라미터만 제안(승인 게이트). + 164 -- **Phase C — 자가 튜닝**: LLM이 Step Test 시점 제안 → 자동 피팅 → 시뮬레이터 A/B 검증 후 반영. + 176 +| 단계 | 내용 | 경로 | 권한 | + 177 +|------|------|------|------| + 178 +| **1. 제안 표시** | 엔진이 RSP 소스 포인트에 계산값 write → 운전원이 페이스플레이트에서 "제안 SP"를 봄(LSP 유지) | SP/RS + +P | 운전원 100% | + 179 +| **2. 관찰·신뢰 형성** | 제안값이 합리적인지 운전원이 일정 기간 관찰 | SP/RSP | 운전원 100% | + 180 +| **3. SP 주도권 이양** | 신뢰 시 운전원이 **RSP로 토글** → 엔진 SP 추종. 언제든 LSP 회수 | SP/RSP | 엔진(가역) | + 181 +| **4. 헌팅 자동 안정화** | 헌팅 임계 초과 + 원인=튜닝/외란 확인 시 PID MAN 전환 → FF+PI로 OP 핸드홀딩 → 안정 후 복귀 | O + +P/MAN | 엔진(데드맨 폴백) | + 182 + 183 +**구현 선행조건(Phase 0)**: §6-1 엔진 가드 레이어 + 데드맨. *(현재 쓰기 경로에 가드 0건 — §10 참조.)* + 184 + + 185 --- + 186 + 168 -## 8. LLM이 잘하는 4가지 역할 (Plane 2 상세) + 187 +## 8. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections`) + 188 + 170 -1. **Step Test 분석 (강력 추천)** — 원본 §3. 유량 스텝 후 하부/상부/환류드럼/측류 온도·Analyzer 곡선을 + 171 - `query_pv_history`로 뽑아 LLM에 주면 구간별 데드타임 θ·시상수 τ를 읽어냄 (결정론 곡선피팅으로 교차검증) + 172 - → 그 값이 Plane 1 파라미터가 됨. + 173 -2. **파라미터 튜닝 조언** — 처리량·원료 조성 드리프트 시 K·τ 재조정 제안. + 174 -3. **이상 상황 서술** — "FT 헌팅 5분째 ±5% 지속, 필터 τ 300→420초 권장" 식 자연어 진단. + 175 -4. **운전원 코칭** — 신입에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명. + 189 +원료 경로(trace_connections): + 190 +``` + 191 +P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 + 192 +``` + 193 + 194 +| # | 경로 | MV/제어 | 유량 | 온도 | 수위/압력 | τ | + 195 +|---|------|---------|------|------|----------|---| + 196 +| **F** | 원료 투입 | **FICQ-6101**→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력(Lag 300s) | + 197 +| **S** | 리보일러 스팀 | 스팀밸브 | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름 | + 198 +| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1~2분 | + 199 +| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), LICA-6113, + + PI-6111(진공), PICA-6111 | 5분 | + 200 +| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) | 15~20분 + +| + 201 + + 202 +- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1). + 203 + ※ SP 경로 구현 시 write 타깃은 **루프 SP가 아니라 RSP 소스 포인트**로 바뀜(노드 ID만 교체, 쓰기 코드 동일). + 204 +- 현재 운전 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종, 진공압 PICA-6111 30.4 → 가동 중 추정. + 205 + + 206 +### 8.1 미완료 매핑 (담당 구분) + 207 +- **P(측류 제품 추출) 경로 매핑 — 사용자 직접 진행 예정** (본 플랜 보류) + 208 +- B(하부) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 C-6111 `trace_connections downstream`로 보강 + 209 + + 210 --- + 211 + 179 -## 9. 미해결/확인 필요 항목 + 212 +## 9. 현 시스템 재사용 자산 + 213 + 214 +| 구분 | 자산 | + 215 +|------|------| + 216 +| 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(.sp/.op)`, `SetModeAsync(MAN/AUTO)`, `ControlOp`(MD→MAN→OP→AUTO) / `POST / + +api/experion/{write,mode,control}` / UI "OPC UA Write" 탭 | + 217 +| 읽기 | `ExperionRealtimeService`(실시간 PV 구독, IHostedService), `query_pv_history`(MCP)/`ExperionHistoryController` | + 218 +| 백그라운드 | `IHostedService`/`AddHostedService` 패턴 기존 사용 → 신규 `AutoRunService : BackgroundService` 그대로 적용 + + | + 219 +| LLM 감독 | `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, `summarize_events`, ` + +generate_status_report`, ReAct 에이전트 모드 | + 220 + + 221 +--- + 222 + + 223 +## 10. 미해결/확인 필요 항목 + 224 + + 225 - [ ] **P(측류 제품 추출) 경로 매핑** — *사용자 직접 진행* + 226 - [ ] B(하부) 발출 유량계·밸브 태그 확정 + 183 -- [ ] 6.1 / 6.2 선택 확정 (시작 지점 / LLM 권한) + 227 +- [ ] **쓰기 경로 안전 가드(§6-1) 신규 구현** — 현재 `WriteTagAsync`에 클램프/rate/변동폭 0건 (Phase 0 선행) + F(헌팅) ─filter→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐ + ├→ OP → rate제한 → 밸브 + 설정값 − 실측PV ───────────── 느린 PI ──────────→ OP_pi ┘ + + --- + 정리하면: FF는 "물리로 미리 계산한 부드러운 큰 움직임"(헌팅 차단), PI는 "모델 오차만 천천히 청소하는 작은 피드백"(정확도 확보). + 둘이 상호보완이고, 고정+간헐은 피드백을 버려서 PV가 드리프트하므로 안 씁니다. + + 이 설명으로 명확해지셨나요? 막히는 부분 있으면 더 풀어드리고, 괜찮으시면 이 제어법을 확정으로 플랜 문서에 반영하겠습니다. + +✻ Cooked for 57s + +❯ 이해됐어, 이제 플랜 문서에 반영해줘 + +● 전체 논의를 통합해 플랜 문서를 개정하겠습니다. 먼저 현재 내용을 확인합니다. + + Read 1 file (ctrl+o to expand) + +● 전체 논의를 통합해 문서를 전면 개정하겠습니다. + +● Write(측류추출-자동운전-플랜.md) + ⎿  Added 178 lines, removed 123 lines + 1 # 측류 추출 증류탑(C-6111) — 로컬 LLM 기반 자동운전 플랜 + 2 + 3 > **목적**: `측류추출-시간지연-적용방식.md`의 시간지연/시차 보상 제어를 ExperionCrawler 시스템 위에서 + 4 -> **로컬 LLM(vLLM Qwen)** 과 결합해 자동운전(Autopilot)으로 구현하기 위한 컨셉·아키텍처·선택사항 기록. + 4 +> 구현하되, **운전원이 단계적으로 신뢰를 쌓아 권한을 넘기는** 감독제어(Supervisory Control) 형태의 + 5 +> 자동운전을 설계한다. 결정론 엔진이 제어하고, 로컬 LLM(vLLM Qwen)은 그 위에서 진단·예외·인터페이스를 맡는다. + 6 > + 6 -> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의용. 코드 미작성 상태. + 7 +> 문서 성격: **설계/의사결정 기록**. 구현 착수 전 합의 완료본. 코드 미작성 상태. + 8 + 8 -*작성일: 2026-05-22 / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 9 +*작성일: 2026-05-22 / 갱신: 2026-05-22 (논의 합의 반영) / 대상: C-6111 PGMEA 진공 측류추출 증류탑 (P6 영역)* + 10 + 11 --- + 12 + 12 -## 0. 핵심 원칙 (가장 중요) + 13 +## 0. 핵심 원칙 + 14 + 14 -**LLM을 빠른 제어 루프에 넣지 않는다.** + 15 +**LLM을 빠른 제어 루프에 넣지 않는다.** 빠른 보상은 결정론 엔진(코드)이, LLM은 분/이벤트 단위 진단·튜닝·인터페 + +이스만. + 16 + 16 -`측류추출-시간지연-적용방식.md`가 말하는 "1분/5분/15~20분 지연 보상"은 초 단위로 결정론적으로 돌아야 + 17 -하는 빠른 루프다. 여기에 LLM을 직접 넣으면: + 18 - + 17 | 문제 | 영향 | + 18 |------|------| + 19 | 비결정성 | 같은 입력에 다른 출력 → 밸브 제어에 치명적 | + 20 | 지연(latency) | 토큰 생성 수 초 → Flooding 즉시 대응 불가 | + 23 -| 환각 | 잘못된 SV 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 | + 21 +| 환각 | 잘못된 값 한 줄이 바로 밸브로 → 측류 순도 영역 파괴 | + 22 + 25 -→ **결론**: 빠른 보상은 **결정론 엔진(코드)** 이 담당하고, **LLM은 분 단위 감독·튜닝·조언만** 한다. + 26 -이것이 LLM을 실공정에 붙이는 유일하게 안전한 형태다. + 23 +따름정리: **헌팅 검출·MAN 전환·OP 산출 등 안전·실시간 판단은 모두 결정론.** LLM은 그 트립을 *설명*하고 + 24 +*원인을 진단*할 뿐, 직접 트립시키거나 OP를 쓰지 않는다. + 25 + 26 --- + 27 + 30 -## 1. 2-Plane 아키텍처 + 28 +## 1. 물리 결정론 vs LLM — 역할 경계 (이 플랜의 출발점) + 29 + 32 -``` + 33 -┌─ Plane 2: LLM 감독 (MCP, 분/이벤트 단위, 느림) ───────────────┐ + 34 -│ · Step Test 곡선 분석 → θ(데드타임)·τ(시상수) 자동 추출 │ + 35 -│ · 파라미터(K, τ, 한계값) 튜닝 제안 │ + 36 -│ · 헌팅 / Flooding / 순도 드리프트 이상 감지·자연어 설명 │ + 37 -│ · 운전원 Q&A ("왜 제품밸브가 천천히 열려요?") │ + 38 -│ │ ※ 밸브 직접 쓰기 금지. "엔진 파라미터 저장소"에만 │ + 39 -│ │ 제안 → 운전원 승인 후 반영 │ + 40 -├─────────┼──────────────────────────────────────────────────────┤ + 41 -│ 🔒 안전 가드 레이어 (신규, 0순위) ─ 모든 쓰기가 강제 통과 │ + 42 -│ hard min/max · 변화율(rate) 제한 · dead band · 태그 화이트 │ + 43 -│ 리스트 · 통신두절→안전SV 폴백 · 전 쓰기 감사로그 │ + 44 -├─────────┼──────────────────────────────────────────────────────┤ + 45 -│ Plane 1: 결정론 보상 엔진 (신규 BackgroundService, 초 단위) │ + 46 -│ Realtime 구독으로 F(원료유량) 읽기 │ + 47 -│ → Lag(τ=300s) 필터로 헌팅 제거 → F_clean │ + 48 -│ → B_sv(데드타임 1~2분) / D_sv(5분) / P_sv(15~20분) 계산 │ + 49 -│ → 가드 통과 후 WriteTagAsync / ControlOp 로 쓰기 │ + 50 -└────────────────────────────────────────────────────────────────┘ + 51 - 읽기: ExperionRealtimeService · query_pv_history + 52 - 쓰기: IExperionOpcWriteClient (가드 레이어 경유 필수) + 53 -``` + 30 +운영자가 **밸브 사이즈·배관 종류·컨트롤밸브 Cv 값/Cv 커브·플로우미터 유량범위** 등 물리 데이터를 + 31 +보유하면, 제어 수학의 상당 부분이 *데이터 피팅 없이 계산*된다. + 32 + 55 ---- + 33 +### 1.1 물리 데이터로 결정론화되는 것 (LLM 불필요) + 34 +| 물리 데이터 | 계산되는 모델 | + 35 +|------------|--------------| + 36 +| Cv 커브(설치특성) | OP(%) → 유량 관계, 밸브 게인 dQ/dOP | + 37 +| 배관 종류·구경·길이 | ΔP·마찰, 이송 데드타임 θ = 관내체적/유량 | + 38 +| 드럼/트레이 홀드업 체적 | 체류시간 τ = 체적/유량 (D-6113 환류드럼 등) | + 39 +| 플로우미터 레인지 | 스케일링·분해능·노이즈 플로어 | + 40 + 57 -## 2. 보상 제어 수식 (Plane 1 — 결정론, LLM 아님) + 41 +→ 자동운전의 **B(하부)·D/R(상부) 타이밍은 하이드롤릭 홀드업(=체적/유량)으로 직접 계산**된다. + 42 +밸브 게인도 Cv 커브 미분으로 나온다. **이 부분은 그냥 프로그램한다.** + 43 + 59 -원본 문서 §2·§4 기준. + 44 +### 1.2 물리 데이터가 못 주는 것 + 45 +- **(가) 분리/조성 동특성** — P(측류)의 "15~20분" 지연은 배관 이송이 아니라 트레이 홀드업+기액평형(VLE)으로 + 46 + 새 조성이 자리잡는 시간. 상대휘발도·트레이 효율·VLE는 Cv 커브에 없음. → **B·D는 물리로 계산되지만 P는 별도 모 + +델 필요.** + 47 +- **(나) 모델-플랜트 불일치(드리프트)** — Cv 커브는 신품 설계값. 밸브 stiction·마모, E-6103 파울링, 트레이 효율 + + 저하로 시간에 따라 어긋남. + 48 +- **(다) 목적·맥락·예외** — 회수율 최대 vs 에너지 최소 vs 순도 사수, 등급변경, 기동/정지, 계기고장, 상류 외란. + 49 + 61 -- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])` + 62 -- **데드타임(Dead Time)**: 링버퍼로 N틱 지연 + 63 -- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** 1개 (원본 §4.1 "1순위 대책") + 50 +### 1.3 따라서 LLM이 실제로 하는 일 + 51 +> **LLM의 가치는 물리모델 품질에 반비례.** 물리를 잘 잡을수록 LLM은 제어 산수에서 빠지고 가장자리로 이동. + 52 + 65 -| MV | 제어 대상 | τ / 데드타임 | 목적 | + 66 -|----|----------|-------------|------| + 67 -| B | 하부 제거량 | 1~2분 | 탑 넘침(Flooding) 즉시 방지 | + 68 -| D/R | 상부 제거량/환류 | 5분 | 압력/조성 안정화 | + 69 -| P | 측류 제품 추출 | 15~20분 | 초고순도 PGMEA 품질 보호 (가장 보수적) | + 70 -| S | 리보일러 스팀 | 가장 빠름(수초~수분) | 하부 온도 직결 | + 53 +| LLM 역할 | 구체 | 가치 | + 54 +|---------|------|------| + 55 +| ① 커미셔닝 보조 | 밸브 데이터시트·Cv 커브·배관 스펙 파싱 → 엔진 config/코드로 조립, 정합성 점검 | ★★ | + 56 +| ② 드리프트 진단((나)) | 물리예측 vs 실측 잔차는 수학, *"이 OP·ΔP에서 8% 미달 → 밸브 파울링/마모 의심"* 해석· + +재교정 트리거는 LLM | ★★ | + 57 +| ③ 소프트센서 보조((가)) | 측정 안 되는 조성을 온도(TI-6111B/C)로 추론, 분석기 결측 보간 | ★ | + 58 +| ④ 감독형 예외 처리((다)) | 엔진이 프로그램 안 된 상황(기동·등급변경·상류 업셋·계기고장) 판단·완화 | ★★★ | + 59 +| ⑤ 운전원 인터페이스 | 의도/경제목표 → SV·제약 번역, "왜 이렇게 도는지" 설명 | ★★★ | + 60 +| ⑥ 교차 데이터 융합 | 알람+이벤트+랩분석+정비이력+물리잔차 엮어 진단 (기존 MCP 도구) | ★★★ | + 61 +| ⑦ 헌팅 원인 진단 | 튜닝 vs stiction vs 외란 판별 → 4단계(OP 개입) 적용 여부 게이트 (§4.3) | ★★★ | + 62 + 72 -추가 안전요소(원본 §4.2/§4.3): 각 PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑). + 73 - + 63 --- + 64 + 76 -## 3. 현 시스템에서 확인된 능력 (재사용 자산) + 65 +## 2. 감독제어 아키텍처 — 운전원이 권한을 쥔다 + 66 + 78 -### 3.1 쓰기 (이미 구현됨) + 79 -| 기능 | 구현 | 엔드포인트 | + 80 -|------|------|-----------| + 81 -| SP/OP 직접 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(cfg, nodeId, value)` | `POST /api/experion/write` | + 82 -| MAN/AUTO 모드 | `SetModeAsync(cfg, nodeId, "MAN"\|"AUTO")` | `POST /api/experion/mode` | + 83 -| 통합 제어 (MD→MAN → OP쓰기 → AUTO복귀) | `ControlOp(TagName, OpValue, RestoreAuto)` | `POST /api/experion/con + -trol` | + 84 -| UI | "OPC UA Write" 탭 (#15) | `index.html #pane-write` | + 67 +핵심 설계 사상: **엔진은 PID 루프의 SP/OP 레지스터를 직접 덮어쓰지 않는다.** 별도 감독변수에 쓰고, + 68 +**운전원이 스위치로 채택**한다. 권한 손잡이는 항상 운전원에게 있다. SP 경로와 OP 경로가 대칭이다. + 69 + 86 -### 3.2 읽기 + 87 -- `ExperionRealtimeService` — 실시간 PV 구독 (`AddMonitoredItemAsync`), `IHostedService` + 88 -- `query_pv_history` (MCP) / `ExperionHistoryController` — Step Test용 시계열 + 70 +| | SP 경로 (평상시) | OP 경로 (헌팅 시) | + 71 +|---|------------------|-------------------| + 72 +| 엔진이 쓰는 곳 | RSP 소스 포인트 (별도 변수) | `.op` (PID MAN 상태에서) | + 73 +| 운전원 스위치 | **LSP ↔ RSP** (Local ↔ Remote SP = AUTO↔CAS) | **PID MODE: AUTO ↔ MAN** | + 74 +| 빠른 규제 담당 | DCS PID (그대로 둠) | 엔진(소프트웨어 컨트롤러) | + 75 +| 폴백(엔진 사망) | 운전원이 LSP로 토글 | 데드맨 → MAN→AUTO (bumpless) | + 76 +| 적용 | 1~3단계 (신뢰 이양) | 4단계 (튜닝발 헌팅 한정) | + 77 + 90 -### 3.3 백그라운드 서비스 패턴 + 91 -- `IHostedService`/`AddHostedService` 이미 Realtime·History·OpcServer·Mcp에서 사용 중 + 92 - → 신규 `AutoRunService : BackgroundService`가 기존 패턴에 그대로 들어감 + 78 +### 2.1 SP 경로 — RSP(Remote Setpoint) + 79 +- 엔진은 **루프 SP를 절대 안 건드림.** 자기 감독소스 포인트에만 OPC write → 그 포인트가 PID의 RSP/X 입력에 cont + +rol connection. + 80 +- 운전원의 **LSP/RSP 토글이 유일한 권한 손잡이.** RSP면 엔진 SP 추종, LSP면 운전원 수동 — 언제든 가역. + 81 +- **bumpless 요건(중요)**: OPC 외부 감독은 DCS의 back-calculation 핸드셰이크를 못 받음. + 82 + → 루프가 LSP(미선택)일 때 엔진이 **현재 실작동 SP를 읽어 자기 출력=현재 SP로 추종**시켜야 함. + 83 + 그래야 운전원이 RSP로 토글하는 순간 충격 없음. + 84 +- **공짜 안전망**: DCS RSP 한계(SPHILM/SPLOLM, RSP rate)가 엔진과 독립으로 한 겹 더. + 85 +- **장점**: 1~2단계(제안 표시)는 페이스플레이트가 RSP 후보값을 네이티브로 보여줌 → **별도 화면 개발 불필요.** + 86 + 94 -### 3.4 LLM 감독용 MCP 도구 (기존) + 95 -- `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, + 96 - `summarize_events`, `generate_status_report`, ReAct 에이전트 모드(구현됨) + 87 +### 2.2 OP 경로 — MAN + OP 쓰기 (튜닝발 헌팅 전용) + 88 +- 평상시 RSP로는 **튜닝발 헌팅이 안 잡힘**(PID가 루프에 그대로). 그래서 헌팅 루프에 한해 OP를 직접 잡는다. + 89 +- 방식: PID를 **MAN**으로 → 엔진이 `.op`에 직접 write. **MAN이라 적분이 멈춰 windup 없음, OP 쓰기는 본질적 bump + +less.** + 90 + 기존 `ControlOp`(MD→MAN→OP쓰기) / `WriteTagAsync(.op)` 그대로 사용 → **신규 DCS 구성 불필요, 저MoC.** + 91 +- **운전원 회수**: MAN의 OP는 엔진이 쓴 마지막 값 → 운전원이 그 값에서 이어 조정, 또는 AUTO로 올림. + 92 +- **폴백(엔진 사망)**: 엔진 워치독 + **DCS 컨트롤러 로직이 stale(N초 갱신 없음) 감지 → MAN→AUTO 강제 복귀.** + 93 + PID가 bumpless output 설정이라 **현재 OP(=마지막 LLM_OP)에서 적분 임펄스 없이 규제 재개.** + 94 + - *정직한 단서*: 폴백은 "헌팅하던 그 PID"로 돌아감 → 안전(규제됨, SIS가 극단 차단)하나 **엔진 복구 전까지 헌 + +팅 재개.** 위험 아님, 차선. + 95 + - 설정 확인: MAN 중 SP 추종/홀드 → 폴백 후 어떤 LSP로 규제할지 결정. + 96 +- **상위 옵션(임계 루프 한정)**: *순간 규제 공백도 불가*한 빠른 루프는 선택+back-calc(PID는 AUTO 추종 유지, 무 + +충격 즉시 폴백)을 쓰되, 밸브 출력경로를 변형하므로 MoC가 더 엄격. 기본값은 위 MAN 방식. + 97 + 98 --- + 99 + 100 -## 4. ⚠️ 안전 관련 발견 사항 (자동운전 전 반드시 처리) + 100 +## 3. LLM-OP 모드의 제어법 — FF + 느린 PI (rate 제한) + 101 + 102 -1. **쓰기 경로에 안전 가드가 0건.** `WriteTagAsync`는 들어온 double을 그대로 쓴다 — + 103 - min/max 클램프·rate limit·범위 검증·변화율 제한 전무. 사람이 UI에서 손으로 쓸 땐 운전원이 + 104 - 최종 안전망이지만, **엔진이 자동으로 쓰는 순간 안전망이 사라진다.** → **0순위: 가드 레이어.** + 105 -2. **현재 LLM(MCP)에는 쓰기 도구가 없다.** 쓰기는 Web UI/HTTP 전용 → 지금은 "사람만 쓸 수 있는" + 106 - 상태가 유일한 안전 경계. 자동운전을 붙이면 이 경계를 넘게 됨 → 신중한 권한 설계 필요. + 107 -3. **`ask_iiot_llm`(vLLM 직접 질의) MCP 도구가 빈 응답.** 2회 시도 모두 `(응답 없음)`. + 108 - vLLM 엔드포인트 상태/연결 점검 필요. (단 `find_tags`/`trace_connections`는 정상 동작.) + 102 +OP 경로로 개입한 동안 엔진이 매 순간 OP에 무엇을 쓰는가. **크루즈컨트롤과 동일 구조**: 미리 예측(FF) + 잔차 청 + +소(PI). + 103 + 104 +``` + 105 +F(헌팅) ─Lag필터→ F_clean ─물질수지→ 목표유량 ─Cv커브→ OP_ff ┐ + 106 + ├→ OP → rate제한 → 절대/변동폭 클램프 → 밸브 + 107 +설정값 − 실측PV ───────────────── 느린 PI ───────→ OP_pi ┘ + 108 +``` + 109 + + 110 +- **FF (피드포워드)**: 물리로 *미리* 정답 개도 계산. `개도% = Cv⁻¹( Q / √(ΔP/SG) )`. + 111 + 필터링된 F_clean로 목표유량(B/D/P)을 물질수지로 구하고 → Cv 커브로 OP 계산 → §5 시간상수로 부드럽게 이동. + 112 + **외란발 헌팅을 잡는 주역**(반응이 아니라 예측이라 밸브가 안 채인다). + 113 +- **PI (느린 피드백)**: Cv 커브는 신품값이라 마모·파울링·ΔP 부정확으로 살짝 빗나감. 잔차(SP−PV)를 + 114 + **느리게/약하게** 보정. 약한 이유: ①헌팅 재유발 방지 ②큰 일은 FF가 이미 함. + 115 +- **rate 제한**: OP 변화율 제한으로 밸브 부드럽게. + 116 +- **비채택: "고정+간헐 보정"** — 보정 사이 능동 규제 0 → 외란 시 PV 드리프트(피드백 상실). 사용 안 함. + 117 +- **연결**: FF = §5 결정론 보상 엔진 그대로 + 그 위에 작은 PI 트림 하나. + 118 + + 119 --- + 120 + 112 -## 5. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections` 기반) + 121 +## 4. 헌팅 검출 & 원인 진단 — 4단계의 게이트 + 122 + 114 -`trace_connections`가 돌려준 원료 경로: + 115 -``` + 116 -P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 + 117 -``` + 123 +### 4.1 검출 (결정론) + 124 +- 오실레이션 인덱스: 진폭·주기·지속성. 임계 초과(예: 진폭 > 범위의 X%, 주기 안정, N분 지속) 시 트립. + 125 +- **MAN 전환 트립은 결정론**(LLM 지연 불가). LLM은 트립을 설명만. + 126 + 119 -| # | 경로 | 조작변수(MV)/제어 | 유량 | 온도 | 수위/압력 | τ | + 120 -|---|------|------------------|------|------|----------|---| + 121 -| **F** | 원료 투입 | **FICQ-6101**(SP/OP)→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력신호(Lag 300s) | + 122 -| **S** | 리보일러 스팀 | 스팀밸브(리보일러 듀티) | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | + - 가장 빠름 | + 123 -| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1 + -~2분 | + 124 -| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), + -LICA-6113, PI-6111(진공), PICA-6111 | 5분 | + 125 -| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) + -| 15~20분 | + 127 +### 4.2 원인 분류 (LLM + 데이터 융합) — §1.3-⑦ + 128 +| 원인 | 4단계(MAN+OP)로 잡히나 | 조치 | + 129 +|------|----------------------|------| + 130 +| 튜닝 과민 | ✅ 즉시 | MAN 전환 → FF+PI로 OP 핸드홀딩 | + 131 +| 상류 외란 | ✅ 잘 잡힘 | 동일(FF가 주역) | + 132 +| 루프 간섭 | ⚠️ 부분 | 시차 조절로 완화 | + 133 +| **밸브 stiction** | ❌ 악화 | **정비 플래그.** OP 핸드홀딩 금지(마모만 늘어남) | + 134 + 127 -- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1) + 128 -- 현재 운전 데이터 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종 중, 진공압 PICA-6111 30.4 → 탑 가동 중으로 추정 + 135 +→ LLM이 OP-PV 위상·한계주기 파형·상류 신호·정비이력을 엮어 *"이건 stiction → 4단계 말고 정비"* vs + 136 +*"외란 → 4단계 유효"* 판정. **초기엔 LLM 진단 → 운전원 확인 권장.** + 137 + 130 -### 5.1 미완료 매핑 (담당 구분) + 131 -- **P(측류 제품 추출) 경로 매핑 — 사용자가 직접 진행 예정** (본 플랜에서는 보류) + 132 -- B(하부 제거) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 + 133 - C-6111 `trace_connections downstream`로 보강 가능 (착수 시 확정) + 138 +--- + 139 + 140 +## 5. 보상 제어 수식 (결정론, FF의 본체) + 141 + + 142 +원본 문서 §2·§4 기준. + 143 +- **1차 지연(Lag) 필터** (이산): `y[k] = y[k-1] + (Δt/τ) · (x[k] − y[k-1])` + 144 +- **데드타임**: 링버퍼로 N틱 지연 + 145 +- **헌팅 제거**: 원료 FT 신호 직후 Lag 필터 τ=**300초(3~5분)** (원본 §4.1) + 146 + + 147 +| MV | 제어 대상 | τ / 데드타임 | 근거 | 목적 | + 148 +|----|----------|-------------|------|------| + 149 +| B | 하부 제거량 | 1~2분 | 하이드롤릭 홀드업(물리 계산) | 탑 넘침(Flooding) 즉시 방지 | + 150 +| D/R | 상부 제거량/환류 | 5분 | D-6113 드럼 체류시간(물리 계산) | 압력/조성 안정화 | + 151 +| P | 측류 제품 추출 | 15~20분 | **분리/조성 동특성(§1.2-가, 별도 모델)** | 초고순도 PGMEA 품질 보호 | + 152 +| S | 리보일러 스팀 | 가장 빠름 | 압력 즉시 전달 | 하부 온도 직결 | + 153 + + 154 +추가(원본 §4.2/§4.3): PID 블록 **dead band 0.5~1.0%**, 원료탱크 **Surge Control**(P-Gain↓ I-Time↑). + 155 + + 156 --- + 157 + 137 -## 6. 선택사항 (의사결정 대기) + 158 +## 6. 안전 봉투 (Safety Envelope) + 159 + 139 -### 6.1 시작 지점 — "무엇부터 구현하나" + 140 -| 옵션 | 내용 | 비고 | + 141 -|------|------|------| + 142 -| **A. 안전 가드 레이어 먼저** | 쓰기 경로에 클램프·변화율·dead band·화이트리스트·감사로그 추가 | **권장**. 자 + -동운전 전제조건이며 수동 쓰기도 즉시 안전해짐 | + 143 -| B. 결정론 보상 엔진(폐루프) | `AutoRunService`: F구독→Lag/데드타임→B/D/P SV 계산→가드 경유 쓰기 | 실제 자동운 + -전 핵심 | + 144 -| C. 조언형(개루프)부터 | 엔진은 권고 SV만 계산·표시, 쓰기는 운전원이 클릭 승인 | 로직 안전검증 후 폐루프 전환 + -| + 145 -| D. 시뮬레이터 먼저 | FOPDT 증류탑 디지털 트윈으로 실플랜트 전 검증 | 현 브랜치 `sim/...` 와 자연스러움 | + 160 +엔진의 모든 쓰기는 아래를 강제 통과한다(다층 독립 방어): + 161 + 147 -### 6.2 LLM 개입 수준 — "LLM 권한 어디까지" + 148 -| 옵션 | 내용 | 비고 | + 149 -|------|------|------| + 150 -| **가. 감독·조언만** | Step Test 분석·이상 설명·파라미터 제안만. 밸브/쓰기 절대 안 함 | **권장**. 가장 안전 | + 151 -| 나. 파라미터 쓰기(승인 게이트) | LLM이 K·τ 등 엔진 파라미터 변경 제안 → 운전원 승인 후 반영. 밸브 직접 제어는 + - 여전히 엔진만 | 적응 튜닝 가능 | + 152 -| 다. MCP 쓰기 도구 추가 | LLM이 MCP로 직접 SV/모드 쓰기(가드 경유) | 유연하나 위험 큼 — 신중 적용 | + 162 +1. **엔진 가드**: rate 제한 · 절대 min/max · **현재 유량범위 대비 밸브 변동폭 제한** · 태그 화이트리스트 · 전 + +쓰기 감사로그 + 163 +2. **DCS 측 한계**: RSP 한계(SPHILM/SPLOLM), 출력 한계(OPHILM/OPLOLM) — 엔진과 독립 + 164 +3. **운전원 스위치**: LSP/RSP, AUTO/MAN — 언제든 즉시 회수 (최우선) + 165 +4. **데드맨/워치독**: 엔진 stale → SP경로는 운전원 LSP 회수, OP경로는 DCS 로직이 MAN→AUTO(bumpless) 폴백 + 166 +5. **ESD/IL/SIS 독립**: BPCS 루프의 MAN/AUTO·LSP/RSP와 무관하게 최종요소에 독립 동작 → 실험을 봉인된 안전 범위 + +에 묶음 + 167 +6. **한 번에 한 루프**: 간섭 루프 동시 MAN 금지 + 168 +7. **양방향 bumpless**: 모든 전환에서 충격 없음(PID bumpless output + 엔진 추종) + 169 + 154 -> 현재 권장 조합: **6.1-A (가드 먼저) + 6.2-가 (LLM 감독만)** 로 시작 → 검증 후 단계적 확장. + 170 +> ⚠️ **MoC/문화**: 자동 시스템이 SP/OP를 조작하는 것은 현장에서 APC로 간주 → 변경관리·운전원 수용 절차 필요(기 + +술 외 항목). + 171 + 172 --- + 173 + 158 -## 7. 단계별 로드맵 + 174 +## 7. 단계별 신뢰 이양 로드맵 (운전원 비전) + 175 + 160 -- **Phase 0 — 안전 가드 레이어**: 쓰기 경로 클램프/rate/dead band/화이트리스트/폴백/감사로그. (전제조건) + 161 -- **Phase A — 조언형(개루프)**: 보상 엔진이 권고 SV 계산·대시보드 표시 + LLM Step Test 분석기. + 162 - DCS 쓰기는 운전원 수동 승인. 위험 최소. + 163 -- **Phase B — 감독형 폐루프**: `AutoRunService`가 가드 안에서 SV 자동 쓰기. LLM은 파라미터만 제안(승인 게이트). + 164 -- **Phase C — 자가 튜닝**: LLM이 Step Test 시점 제안 → 자동 피팅 → 시뮬레이터 A/B 검증 후 반영. + 176 +| 단계 | 내용 | 경로 | 권한 | + 177 +|------|------|------|------| + 178 +| **1. 제안 표시** | 엔진이 RSP 소스 포인트에 계산값 write → 운전원이 페이스플레이트에서 "제안 SP"를 봄(LSP 유 + +지) | SP/RSP | 운전원 100% | + 179 +| **2. 관찰·신뢰 형성** | 제안값이 합리적인지 운전원이 일정 기간 관찰 | SP/RSP | 운전원 100% | + 180 +| **3. SP 주도권 이양** | 신뢰 시 운전원이 **RSP로 토글** → 엔진 SP 추종. 언제든 LSP 회수 | SP/RSP | 엔진(가역) + + | + 181 +| **4. 헌팅 자동 안정화** | 헌팅 임계 초과 + 원인=튜닝/외란 확인 시 PID MAN 전환 → FF+PI로 OP 핸드홀딩 → 안정 + +후 복귀 | OP/MAN | 엔진(데드맨 폴백) | + 182 + 183 +**구현 선행조건(Phase 0)**: §6-1 엔진 가드 레이어 + 데드맨. *(현재 쓰기 경로에 가드 0건 — §10 참조.)* + 184 + + 185 --- + 186 + 168 -## 8. LLM이 잘하는 4가지 역할 (Plane 2 상세) + 187 +## 8. 태그/노드 매핑 (실측 — `find_tags`·`trace_connections`) + 188 + 170 -1. **Step Test 분석 (강력 추천)** — 원본 §3. 유량 스텝 후 하부/상부/환류드럼/측류 온도·Analyzer 곡선을 + 171 - `query_pv_history`로 뽑아 LLM에 주면 구간별 데드타임 θ·시상수 τ를 읽어냄 (결정론 곡선피팅으로 교차검증) + 172 - → 그 값이 Plane 1 파라미터가 됨. + 173 -2. **파라미터 튜닝 조언** — 처리량·원료 조성 드리프트 시 K·τ 재조정 제안. + 174 -3. **이상 상황 서술** — "FT 헌팅 5분째 ±5% 지속, 필터 τ 300→420초 권장" 식 자연어 진단. + 175 -4. **운전원 코칭** — 신입에게 "왜 P는 15분 늦게 여는가"를 문서 근거로 설명. + 189 +원료 경로(trace_connections): + 190 +``` + 191 +P-6101(원료펌프) → FT-6101 → FICQ-6101 → FCV-6101 → E-6103(예열) → C-6111 원료 스프레이 분배기 + 192 +``` + 193 + 194 +| # | 경로 | MV/제어 | 유량 | 온도 | 수위/압력 | τ | + 195 +|---|------|---------|------|------|----------|---| + 196 +| **F** | 원료 투입 | **FICQ-6101**→FCV-6101 | FT-6101 | (E-6103 예열) | — | 입력(Lag 300s) | + 197 +| **S** | 리보일러 스팀 | 스팀밸브 | **FI-6115** | TI-6111A(BOT), TICA-6111A | PI-6700(스팀압) | 가장 빠름 | + 198 +| **B** | 하부 제거 | 하부 발출 밸브 *(밸브태그 미확인)* | (미확인) | TI-6111A(BOT) | **LI-6111**(하부수위) | 1 + +~2분 | + 199 +| **D/R** | 상부/환류 | **FICQ-6113**(PV29.9/SP36.4) | FI-6113 | TI-6111D(TOP) | **LI-6113**(D-6113 환류드럼), + +LICA-6113, PI-6111(진공), PICA-6111 | 5분 | + 200 +| **P** | 측류 제품 | **🔲 사용자 매핑 예정** | FI-6120(PGMEA) | TI-6111B/C(MID) | LI-6121/6122/6123(제품탱크) + +| 15~20분 | + 201 + + 202 +- OPC Node 형식: `ns=1;s=sinamserver:ficq-6101.sp` / `.op` / `.md`(MAN=0/AUTO=1). + 203 + ※ SP 경로 구현 시 write 타깃은 **루프 SP가 아니라 RSP 소스 포인트**로 바뀜(노드 ID만 교체, 쓰기 코드 동일). + 204 +- 현재 운전 흔적: FICQ-6113 PV 29.9 / SP 36.4 추종, 진공압 PICA-6111 30.4 → 가동 중 추정. + 205 + + 206 +### 8.1 미완료 매핑 (담당 구분) + 207 +- **P(측류 제품 추출) 경로 매핑 — 사용자 직접 진행 예정** (본 플랜 보류) + 208 +- B(하부) 발출 유량계·밸브 태그 — `find_tags`(6112/6114/6116번대) 또는 C-6111 `trace_connections downstream`로 + +보강 + 209 + + 210 --- + 211 + 179 -## 9. 미해결/확인 필요 항목 + 212 +## 9. 현 시스템 재사용 자산 + 213 + 214 +| 구분 | 자산 | + 215 +|------|------| + 216 +| 쓰기 | `ExperionOpcWriteClient.WriteTagAsync(.sp/.op)`, `SetModeAsync(MAN/AUTO)`, `ControlOp`(MD→MAN→OP→AUTO) + + / `POST /api/experion/{write,mode,control}` / UI "OPC UA Write" 탭 | + 217 +| 읽기 | `ExperionRealtimeService`(실시간 PV 구독, IHostedService), `query_pv_history`(MCP)/`ExperionHistoryCon + +troller` | + 218 +| 백그라운드 | `IHostedService`/`AddHostedService` 패턴 기존 사용 → 신규 `AutoRunService : BackgroundService` + +그대로 적용 | + 219 +| LLM 감독 | `query_pv_history`, `find_tags`, `trace_connections`, `active_alarms`, `query_events`, `summarize_ + +events`, `generate_status_report`, ReAct 에이전트 모드 | + 220 + + 221 +--- + 222 + + 223 +## 10. 미해결/확인 필요 항목 + 224 + + 225 - [ ] **P(측류 제품 추출) 경로 매핑** — *사용자 직접 진행* + 226 - [ ] B(하부) 발출 유량계·밸브 태그 확정 + 183 -- [ ] 6.1 / 6.2 선택 확정 (시작 지점 / LLM 권한) + 227 +- [ ] **쓰기 경로 안전 가드(§6-1) 신규 구현** — 현재 `WriteTagAsync`에 클램프/rate/변동폭 0건 (Phase 0 선행) + 228 +- [ ] **DCS 구성**: RSP 소스 포인트 생성·연결, OP 데드맨(stale→MAN→AUTO) 로직, RSP 추종/홀드 설정 + 229 +- [ ] 헌팅 임계 정의(진폭/주기/지속) 및 stiction 자동판별 신뢰 수준 + 230 +- [ ] 각 MV의 hard min/max·변화율·밸브 변동폭 한계(공정 안전 범위) + Cv 커브·배관 물리 데이터 수집 형태 + 231 +- [ ] P(측류) 분리/조성 모델(§1.2-가) 깊이 결정: 고정 τ vs 간이 트레이모델 vs 경험모델 + 232 - [ ] `ask_iiot_llm`(vLLM) 빈 응답 — vLLM 엔드포인트 상태 점검 + 185 -- [ ] 각 MV의 hard min/max·변화율 한계값(공정 안전 범위) 수집 + 233 - [ ] Step Test 수행 가능 시점/조건 (가동 중 5~10% 스텝) + 187 -- [ ] APC 블록 내장 여부 vs 일반 PID 환경 (원본 §"현재 시스템 확인 사항") + 234 +- [ ] APC 블록 내장 여부 vs 일반 PID 환경 / MoC 절차 + 235 + 236 --- + 237 + ... + 241 - 실시간 읽기: `src/Infrastructure/OpcUa/ExperionRealtimeService.cs` + 242 - UI: `src/Web/wwwroot/index.html` (#pane-write) + 243 - MCP 도구: `mcp-server/server.py` (find_tags, trace_connections, query_pv_history, ask_iiot_llm 등) + 244 + + 245 +## 부록 B. 합의된 핵심 결정 (요약) + 246 +1. 감독제어 — 엔진은 별도 변수에만 쓰고 운전원이 스위치로 채택(권한은 운전원). + 247 +2. SP는 **RSP** 경로(LSP/RSP 토글), 외부 추종으로 bumpless. + 248 +3. OP는 **MAN+`.op` 쓰기** 경로(기존 ControlOp), 엔진 워치독 + **DCS 데드맨→MAN→AUTO bumpless** 폴백. + 249 +4. OP 제어법은 **물리 FF(Cv·배관) + 느린 PI + rate제한** (고정+간헐 보정 비채택). + 250 +5. PID 파라미터 재튜닝은 **필수 아님** — MAN에서 OP 대체로 헌팅 안정화 가능(stiction 제외). + 251 +6. LLM은 물리 결정론 위에서 ①커미셔닝 ②드리프트진단 ③소프트센서 ④예외처리 ⑤인터페이스 ⑥교차융합 ⑦헌팅원인진단. + +● 플랜 문서를 전면 개정했습니다. 이번 세션에서 합의한 내용을 모두 반영했습니다. 향후 세션을 위해 핵심 발견을 메모리에 + 남겨두겠습니다. + + Read 1 file, recalled 1 memory, wrote 2 memories (ctrl+o to expand) + +● 플랜 문서 개정과 메모리 기록을 완료했습니다. + + 측류추출-자동운전-플랜.md 개정 내역 + + 처음 작성본(2-Plane 일반론)에서 → 이번 세션에서 합의한 감독제어 구체 설계로 전면 개편했습니다. + + 새로 추가/확정된 핵심 섹션: + + ┌────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ + │ § │ 내용 │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ §1 │ 물리 결정론 vs LLM 역할 경계 — Cv·배관으로 B·D는 계산되나 P(측류)는 분리/조성 모델 필요, LLM은 ①~⑦ 가장자리 역할 │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ §2 │ 감독제어 아키텍처 — SP=RSP / OP=MAN+OP쓰기 대칭 표, 운전원이 권한 쥠, bumpless 요건, 데드맨 폴백 │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ §3 │ LLM-OP 제어법 — FF(Cv) + 느린 PI + rate제한, 크루즈컨트롤 다이어그램, "고정+간헐" 비채택 │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ §4 │ 헌팅 검출(결정론) + 원인진단(LLM: 튜닝/외란/stiction) — 4단계 게이트 │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ §6 │ 안전 봉투 — 엔진가드·DCS한계·운전원스위치·데드맨·ESD/IL/SIS 독립·한루프·bumpless 7층 │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ §7 │ 1~4단계 신뢰 이양 로드맵 (운전원 비전) │ + ├────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ + │ 부록 B │ 합의된 6대 핵심 결정 요약 │ + └────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ + + §8 태그 매핑은 P 경로 = 사용자 직접 진행으로 유지했습니다. + + 메모리 + + project_autopilot_plan.md를 추가하고 인덱스에 등록했습니다. 향후 세션이 자동운전 작업에 들어가기 전 알아야 할 두 가지 — 쓰기 + 경로 가드 0건(Phase 0 선행), ask_iiot_llm 빈 응답(vLLM 점검) — 을 명시해 두었습니다. + + 플랜 §10에 미해결 항목(가드 구현, DCS 구성, 헌팅 임계 정의, P 분리모델 깊이 등)을 체크리스트로 정리해 두었으니, 다음에 어느 + 항목부터 착수할지 정하시면 됩니다. + +✻ Churned for 2m 28s + +───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── +❯ 쓰기 경로 안전 가드부터 구현해줘 +───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── + ⏵⏵ accept edits on (shift+tab to cycle) + + +