184 lines
7.8 KiB
Markdown
184 lines
7.8 KiB
Markdown
---
|
|
name: analyze-ptop-implementation
|
|
description: ILSOS_PrismaticRD_PTOP의 구현 상세 분석. SeqAutoRunPTOP 시퀀스 로직, PLC/Laser/OCT/CellTracker 디바이스 호출 흐름, Rx.NET 메시지 체인, 상태 전이, 타이밍, 에러 처리를 분석하고 구현 개선안 제시. "PTOP 시퀀스 로직 분석", "PLC 통신 흐름 추적", "디바이스 호출 순서", "타이밍 다이어그램" 요청 시 사용. 구분 — 계층·의존성 구조는 `analyze-ptop-architecture`, 빌드/CI는 `optimize-ptop-build`, 셋을 함께 보려는 종합 요청은 `orchestrate-ptop-harness`. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
|
|
---
|
|
|
|
# Analyze PTOP Implementation Skill
|
|
|
|
## 목표
|
|
|
|
ILSOS_PrismaticRD_PTOP의 **구현 세부사항**을 분석하고 최적화 기회를 식별한다.
|
|
|
|
## 분석 영역
|
|
|
|
### 1단계: SeqAutoRunPTOP.cs 상태 머신 분석
|
|
|
|
**수집 대상:**
|
|
- 상태 정의 (enum/class로 표현된 상태들)
|
|
- 상태 진입 조건
|
|
- 상태 내 액션 (동작)
|
|
- 상태 종료 조건
|
|
- 상태 전이 경로
|
|
- 타임아웃 설정
|
|
- 재시도 로직
|
|
|
|
**산출 형식: 상태 다이어그램**
|
|
```
|
|
[시작]
|
|
↓ (전이 순서 — 시간축은 코드 상수 확인 후 기입)
|
|
[초기화] → [준비] → [용접] → [완료] → [정리] → [대기]
|
|
↓ ↓ ↓ ↓ ↓
|
|
[에러 처리] ← ← ← ← ← ← ← ← ← ← ← ←
|
|
```
|
|
|
|
### 2단계: 디바이스 호출 시퀀스 추적
|
|
|
|
각 상태에서:
|
|
- 어떤 디바이스가 호출되는가?
|
|
- 호출 순서는? (순차 vs 병렬)
|
|
- 예상 소요시간?
|
|
- 다음 상태로의 전이 신호는 어디서 오는가?
|
|
|
|
**추적 대상:**
|
|
1. **PLC 호출**
|
|
- 실제 API·주소는 `Device/PLC/PLCController.Logic.cs`와 `PLCController.Address.cs`에서 확인한다.
|
|
PTOP은 원시 주소 문자열이 아니라 **enum 기반**(eBitInput/eBitOutput/eWordInput/eWordOutput)이다.
|
|
- 읽기 / 쓰기 / 폴링 지점을 각각 `파일:라인`과 함께 기록
|
|
- 주소·API 이름을 기억이나 추측으로 쓰지 말 것 — 반드시 소스에서 확인한 것만 적는다.
|
|
|
|
2. **Laser 제어**
|
|
- 활성화 (SetPower, SetFrequency, etc.)
|
|
- 대기
|
|
- 정상 종료
|
|
|
|
3. **OCT 스캔**
|
|
- 스캔 시작
|
|
- 데이터 수집
|
|
- 스캔 종료
|
|
|
|
4. **CellTracker**
|
|
- 셀 추적 시작
|
|
- 위치 업데이트
|
|
- 추적 종료
|
|
|
|
**산출 형식: 타이밍 다이어그램**
|
|
```
|
|
Time <코드 상수 기준 눈금 — 실측이 아니면 눈금 대신 순서만 표기>
|
|
State [<상태1>][<상태2>][<상태3>]
|
|
PLC <호출> <호출>
|
|
Laser <호출>
|
|
OCT <호출>
|
|
CellTrk <호출>
|
|
```
|
|
|
|
> 축의 숫자는 **코드에서 읽은 지연 상수**이거나 **실측값**일 때만 넣는다.
|
|
> 둘 다 아니면 눈금을 빼고 호출 순서만 그린다 — 없는 시간축을 그리면 병목 판단이 오염된다.
|
|
|
|
### 3단계: Rx.NET 메시지 체인 분석
|
|
|
|
**수집 대상:**
|
|
- Observable 소스 (어디서 데이터가 나오는가?)
|
|
- 변환 (Select, Map, Filter)
|
|
- 구독자 (누가 소비하는가?)
|
|
- 에러 처리 (OnError, Catch)
|
|
|
|
**기록 형식:** 실제 소스에서 발췌한 구독 체인을 그대로 인용하고 `파일:라인`을 붙인다.
|
|
|
|
```
|
|
<발행 지점> — 파일:라인
|
|
└─ <연산자 체인> — 파일:라인
|
|
└─ <구독 지점> — 파일:라인
|
|
```
|
|
|
|
> 이 스킬은 예시 코드를 제공하지 않는다. Aurora의 실제 이벤트 API(`EventPublisher`/`EventObservable`)는
|
|
> `docs/Aurora에이전트레퍼런스모음/01_concepts/event.md`에서 확인하고 저장소 코드로 대조하라.
|
|
> **그 폴더는 `.gitignore` 제외(로컬 전용)라 없을 수 있다** — 없으면 `External/Aurora/Aurora2.0_Guide.pdf`와
|
|
> 소스 코드를 직접 대조한다.
|
|
> 그럴듯한 가짜 체인을 적으면 이후 분석이 통째로 그 위에 쌓인다.
|
|
|
|
**산출 형식: 메시지 파이프라인 맵**
|
|
|
|
### 4단계: 에러 처리 로직
|
|
|
|
**찾아야 할 패턴:**
|
|
- Try-Catch 블록
|
|
- TimeoutException 처리
|
|
- PLC 에러 응답 처리
|
|
- 디바이스 오류 복구
|
|
- 폴백 경로 (재시도, 초기화 재개, 강제 종료)
|
|
|
|
**각 에러에 대해:**
|
|
- 감지 방법
|
|
- 처리 방식
|
|
- 복구 가능 여부
|
|
- 사용자 개입 필요 여부
|
|
|
|
### 5단계: 성능/안정성 분석
|
|
|
|
**성능:**
|
|
- 각 상태의 예상 소요시간
|
|
- 전체 시퀀스 총 소요시간
|
|
- 병목 구간 (가장 오래 걸리는 부분)
|
|
- 최적화 기회 (병렬화 가능한가?)
|
|
|
|
**안정성:**
|
|
- 데드락 가능성 (두 디바이스가 서로 대기?)
|
|
- 타이밍 이슈 (신호 도착 순서 의존?)
|
|
- 리소스 누수 (구독 취소 안 됨?)
|
|
- 상태 불일치 (PLC와 소프트웨어 상태 차이?)
|
|
|
|
## 통합 산출물
|
|
|
|
### 최종 보고서: `_workspace/02_ptop_implementation.md`
|
|
(**필수 산출물 2종**: `_workspace/02_ptop_implementation.md` · `_workspace/03_device_integration.md`)
|
|
|
|
보고서 골격은 [references/report-template.md](references/report-template.md) 참조.
|
|
|
|
> **타이밍·주소·소요시간을 지어내지 않는다.** 코드 상수에서 읽은 값(`파일:라인` 병기)이나
|
|
> 실측값만 적고, 둘 다 아니면 `미측정`이라고 쓴다.
|
|
> **상태 전이·경합·인과를 코드로 확인하지 않고 서술하면 문장 앞에 `[추론]`을 붙인다**
|
|
> (`rules.md` #15·#16). `미측정`(값 없음)과 축이 다르니 대체하지 말고 병기한다.
|
|
> 주석이 그렇게 쓰여 있다는 것은 확인이 아니다 (#1) — 실제 코드 경로를 따라가야 표기를 뗄 수 있다.
|
|
|
|
## 입력 조건
|
|
> **단독 호출 시**: 생성할 `_workspace/` 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다
|
|
> (`rules.md` #2). 오케스트레이터(`orchestrate-ptop-harness`)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.
|
|
|
|
|
|
사용자가 다음 요청 시:
|
|
- "PTOP 시퀀스 로직 상세 분석"
|
|
- "SeqAutoRunPTOP이 PLC/Laser/OCT을 어떻게 제어하는가"
|
|
- "PTOP 타이밍 분석"
|
|
- "PTOP에서 에러가 발생하면 어떻게 처리되나"
|
|
- "PTOP의 성능 병목은"
|
|
|
|
## 출력 결과
|
|
|
|
- 상태 머신 다이어그램
|
|
- 타이밍 다이어그램 (시간축)
|
|
- Rx.NET 메시지 흐름도
|
|
- 에러 처리 매트릭스
|
|
- 성능 프로파일
|
|
- 최종 분석 보고서
|
|
|
|
## 주의사항
|
|
|
|
1. **코드 라인 번호 기록** — "Line 245의 try-catch" 형식으로 정확한 위치 기록
|
|
2. **데이터 흐름 추적** — 변수, 반환값을 따라가며 이해
|
|
3. **시간 측정** — Thread.Sleep() / Task.Delay() / TimeSpan 찾기
|
|
4. **예외 처리** — Exception 타입별로 분류
|
|
5. **불명확한 부분 기록** — 추측 금지, 명시적으로 "불명확함" 표시
|
|
6. **주석·변수명·함수명을 맹신하지 않는다** (`rules.md` #1) — 이름이 말하는 동작과 실제 구현이
|
|
다른 사례가 이 저장소에 실재한다. 판단 근거는 항상 구현 본문이다.
|
|
|
|
> **단독 기동으로 `02`·`03`을 갱신했으면 stale 표기 의무는 네게 있다.** "구현만 다시" 같은 요청은
|
|
> 이 스킬로도, `orchestrate-ptop-harness`로도 들어올 수 있는데 오케스트레이터 경유가 아니면 표기할 주체가 없다.
|
|
> 갱신한 파일 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)` 을 적고, 의존 관계인 `01`이 낡았으면
|
|
> `01` 첫 줄에 `이전 실행 결과 재사용 — 정합성 미확인(YYYY-MM-DD)` 을 남긴다
|
|
> (문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).
|
|
|
|
> 이 스킬은 10분을 넘긴다 — **단계 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
|
|
>
|
|
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
|
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|