201 lines
9.9 KiB
Markdown
201 lines
9.9 KiB
Markdown
---
|
|
name: analyze-ptop-architecture
|
|
description: ILSOS_PrismaticRD_PTOP의 3계층 아키텍처(UI → Machine Logic → Device)를 분석하고 검증. EquipDef.cs, EquipmentSetup.cs, Sequences/, Device/ 폴더의 관계를 맵핑하고 Rx.NET 이벤트 흐름을 추적. 디바이스 스택(PLC, Laser, OCT, CellTracker) 통합 여부 검증. "PTOP 아키텍처 분석", "PTOP 계층 구조 검토", "디바이스 스택 파악" 처럼 **구조·의존성 한 영역만** 볼 때 쓴다. 구분 — 아키텍처·구현·빌드를 함께 보려는 요청("PTOP 전체 점검", "종합 분석", "구조 파악")은 `orchestrate-ptop-harness`를 쓴다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
|
|
---
|
|
|
|
# Analyze PTOP Architecture Skill
|
|
|
|
## 목표
|
|
|
|
ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처 전체 그림**을 명확히 파악하고 문서화한다.
|
|
|
|
## 분석 단계
|
|
> **소스 루트 = `Machines/ILSOS_PrismaticRD_PTOP/`.** 이 문서의 상대 경로(`Sequences/…`,
|
|
> `Device/PLC/…`)는 모두 그 아래다. 저장소 루트의 동명 폴더 `ILSOS_PrismaticRD_PTOP/`은
|
|
> 빌드 산출물(.pdb)이므로 거기서 소스를 찾지 말 것.
|
|
|
|
|
|
### 1단계: EquipDef.cs & EquipmentSetup.cs 분석
|
|
|
|
**EquipDef.cs에서 수집할 항목:**
|
|
- `DeviceIds : CommonDeviceIds`에 **직접 선언된** 상수 (`MassFlowMeter` 등) + base에서 상속된 것
|
|
- `SequenceIds : CommonSequenceIds`에 **직접 선언된** 상수 —
|
|
`SeqStreamTest`, `SeqEventQTest`, `SeqTestRun`, `SeqAutoRunComponentWeld`, `SeqAlarmMonitor`,
|
|
`SeqStatusMonitor`, `SeqAutoRunTDC`, `SeqAutoRunPTOP` (8개)
|
|
- 커스텀 `DeviceIds` / `SequenceIds` / `SettingIds` / `StreamMessageNames`
|
|
(`MotorIds`·`RecipeIds` 클래스는 **없다** — base `Common*`·레시피 매니저가 관리)
|
|
|
|
**EquipmentSetup.cs에서 수집할 항목:**
|
|
- `GetEquipmentName()` → 장비명 확인 ("ILSOS PrismaticRD_PTOP")
|
|
- `BuildMainStatusView()` → 표시되는 디바이스 (CellTracker, OCT)
|
|
- `OnSetAlarm()` 로직 → 알람 처리
|
|
- `OnStartUp()` 로직 → 초기화 순서
|
|
- SequenceBuilder 선언과 **실제 `register(...)` 여부는 다르다.** `EquipmentSetup.cs:206-218` 기준:
|
|
- `_SeqAutoRunPrismatic_Builder` → **등록됨**(`:211`, `SequenceIds.SeqAutoRun`)
|
|
- `_SeqAutoRunComponentWeld_Builder` → 대입은 되나 **등록 주석 처리**(`:212`)
|
|
- `_SeqTestRun_Builder` → **선언만·대입 없음**, 등록도 주석(`:213`)
|
|
- `_SeqAlarmMonitor_Builder` → **등록됨**(`:214`)
|
|
- `SeqStatusMonitor.Builder()` → **필드 없이 직접 등록됨**(`:215`) — 빌더 필드만 보면 놓친다
|
|
- `_SeqAutoRunPTOP_Builder` → **등록됨**(`:218`), 메인 시퀀스 (260605)
|
|
|
|
> 목록을 그대로 옮기지 말고 **작업 전 `register(` 호출부를 실제로 나열해 대조하라** —
|
|
> 주석 처리 여부까지 확인해야 "빌드되는 시퀀스"를 정확히 말할 수 있다.
|
|
|
|
**출력:** `_workspace/01a_equipdef_analysis.md`
|
|
|
|
### 2단계: Sequences/ 폴더 구조 분석
|
|
|
|
**주요 파일들:**
|
|
```
|
|
Sequences/
|
|
├── SeqAutoRunPTOP.cs ← 메인 (분석 우선순위 1, 260605)
|
|
├── SeqAutoRunPrismatic.cs ← 기존 (2026-06-18에 SeqAutoRunPrismaticScanner에서 개명)
|
|
├── SeqAutoRunComponentWeld.cs
|
|
├── SeqTestRun.cs
|
|
├── SeqStreamTest.cs
|
|
├── SeqEventQTest.cs
|
|
├── SeqWaitWeldOrChangePage.cs
|
|
├── LaserAngleOffsetSelector.cs
|
|
├── SequenceContextEx.cs ← 컨텍스트 정의
|
|
├── SequenceManager.cs ← 시퀀스 관리
|
|
├── Monitoring/
|
|
└── Manual/
|
|
```
|
|
|
|
> 트리는 참고용이다. **작업 전 `Sequences/`를 실제로 나열해 대조하라** — 이 목록이 낡았을 수 있다.
|
|
|
|
**각 시퀀스 분석 항목:**
|
|
- 용도 (주 시퀀스? 테스트? 모니터링?)
|
|
- 상태 머신 정의 (시작, 대기, 실행, 완료, 에러)
|
|
- 타이밍 (예상 소요시간)
|
|
- 호출하는 디바이스 목록
|
|
- 의존성 (다른 시퀀스에 의존하는가?)
|
|
|
|
**특히 SeqAutoRunPTOP.cs:**
|
|
- 상태 다이어그램 작성
|
|
- 각 상태에서 호출되는 디바이스/API 추적
|
|
- 타임아웃/재시도 로직
|
|
|
|
**출력:** `_workspace/01b_sequences_analysis.md`
|
|
|
|
### 3단계: Device/ 폴더 분석
|
|
|
|
**파일 구조:**
|
|
```
|
|
Device/
|
|
├── PLC/
|
|
│ ├── PLCContoller.Config.cs ← 생성자·접속 설정만. 18줄, 주소 0건 (Controller 아님 — 저장소 오탈자)
|
|
│ ├── PLCController.Logic.cs ← 읽기/쓰기 로직
|
|
│ └── PLCController.Address.cs ← PLC 주소 맵의 진실원. 신호 상수 enum
|
|
└── IO/
|
|
└── PAIX_PTOP.cs ← IO 제어 (2026-06-18 개명)
|
|
```
|
|
|
|
> **동명 심볼 함정.** `WeldingCommon.Devices.Laser.PAIX_PrismaticScanner`(공유)와
|
|
> `WeldingComponents/WeldingCommon/Devices/PLC/PLCController.Config.cs`(공유, 오탈자 없음)는
|
|
> 개명되지 않고 그대로 존재한다. 머신 쪽 파일과 혼동하지 말 것.
|
|
|
|
**PLC 분석:** (모든 값은 `PLCController.Address.cs`의 enum에서 읽어 `파일:라인`과 함께 적는다)
|
|
- 실제 사용되는 주소 범위 — 추정하지 말고 enum 정의에서 확인
|
|
- 주요 신호 목록 (eBitInput/eBitOutput/eWordInput/eWordOutput)
|
|
- 읽기·쓰기 주기, 타임아웃 — 코드 상수 기준. 못 찾으면 `불명확 — 확인 필요`
|
|
|
|
**IO 분석:**
|
|
- 입력 신호 (센서, 스위치)
|
|
- 출력 신호 (제어 신호)
|
|
- 각 신호의 의미
|
|
|
|
**출력:** `_workspace/01c_device_analysis.md`
|
|
|
|
### 4단계: Rx.NET 이벤트 흐름 분석
|
|
|
|
**수집할 정보:**
|
|
- System.Reactive 사용 패턴 (Observable, Subject, etc.)
|
|
- 메시지 타입 (String/Double/Int/JSON/LBAD)
|
|
- 구독자 목록 (누가 어떤 메시지를 구독?)
|
|
- 백프레셔/에러 처리
|
|
|
|
**파이프라인 예시:**
|
|
```
|
|
[PLC Status] Observable
|
|
├─→ Filter(Ready == true)
|
|
├─→ Select(x => new LaserCommand())
|
|
└─→ Subscribe(Laser.Execute())
|
|
```
|
|
|
|
**출력:** `_workspace/01d_rxnet_analysis.md`
|
|
|
|
### 5단계: 외부 디바이스 통합 검증
|
|
|
|
**검증 대상:**
|
|
- PLC (Mitsubishi)
|
|
- Laser (AuroraLaser)
|
|
- OCT Scanner (AuroraOCT)
|
|
- CellTracker (AuroraCellTracker)
|
|
- IO (PAIX)
|
|
|
|
**각 디바이스마다:**
|
|
- 초기화 시점
|
|
- 활성화 조건
|
|
- 사용 방식 (동기/비동기)
|
|
- 에러 처리
|
|
- 정상 종료 절차
|
|
|
|
**출력:** `_workspace/01e_device_integration.md`
|
|
|
|
## 통합 산출물
|
|
|
|
### 최종 보고서: `_workspace/01_ptop_architecture.md`
|
|
|
|
보고서 골격은 [references/report-template.md](references/report-template.md) 참조.
|
|
모든 항목에 `파일:라인` 근거를 붙이고, 확인 못 한 내용은 `불명확 — 확인 필요`로 남긴다.
|
|
|
|
**단독 기동으로 `01`을 갱신했으면 stale 표기 의무는 여전히 네게 있다.** "아키텍처만 다시" 같은 요청은
|
|
이 스킬로도, `orchestrate-ptop-harness`로도 들어올 수 있는데 오케스트레이터 경유가 아니면 표기해 줄 주체가 없다.
|
|
`01`의 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)` 을 적고, **이 파일에 의존하는 `02`·`03`이 이미 있으면**
|
|
그 두 파일 첫 줄에 `이전 실행 결과 재사용 — 01 갱신으로 정합성 미확인(YYYY-MM-DD)` 을 남긴다
|
|
(문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).
|
|
**코드로 확인하지 않은 인과·해석은 문장 앞에 `[추론]`을 붙인다** (`rules.md` #15·#16).
|
|
`불명확 — 확인 필요`(값을 못 찾음)와 축이 다르니 대체하지 말고 필요하면 병기한다.
|
|
확인한 뒤에는 `[추론]`을 떼고 `파일:라인`으로 바꾼다.
|
|
|
|
## 입력 조건
|
|
> **단독 호출 시**: 생성할 `_workspace/` 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다
|
|
> (`rules.md` #2). 오케스트레이터(`orchestrate-ptop-harness`)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.
|
|
|
|
|
|
사용자가 다음과 같이 요청할 때:
|
|
- "PTOP 아키텍처 분석해줘"
|
|
- "PTOP 계층 구조 검토"
|
|
- "PTOP에서 PLC, Laser, OCT가 어떻게 연결되어있는지"
|
|
- "PTOP 3계층 아키텍처 검증"
|
|
|
|
> "PTOP 전체 점검"·"종합 분석"처럼 **구현·빌드까지 함께** 보려는 요청은 이 스킬이 아니라
|
|
> `orchestrate-ptop-harness`다. 시퀀스 내부 동작만이면 `analyze-ptop-implementation`,
|
|
> 빌드/CI면 `optimize-ptop-build`.
|
|
|
|
## 출력 결과
|
|
|
|
- 5개 상세 분석 문서 (`_workspace/01a~01e_*.md`)
|
|
- 통합 보고서 (`_workspace/01_ptop_architecture.md`)
|
|
- 다이어그램 (3계층, 상태 머신, 이벤트 흐름)
|
|
|
|
## 주의사항
|
|
|
|
1. **코드 읽기 능력이 중요** — C#, WPF, Rx.NET 이해 필수
|
|
2. **불명확한 부분은 기록** — "이 부분은 왜 이렇게?"라는 질문을 명시
|
|
3. **Namespace** — 대부분 `ILSOS_PrismaticRD_PTOP.*`이고 옛 `ILSOS_PrismaticScanner`는 0건이다.
|
|
단 **프로젝트 내 예외 3개**: `Sequences/SeqTestRun.cs:35`=`ILSOS_PrismaticRD_TDC.Sequences`,
|
|
`Sequences/Monitoring/SeqAlarmMonitor.cs:22`·`SeqStatusMonitor.cs:11`=`WeldingCommon.Sequences`.
|
|
네임스페이스로 grep하면 이 3개가 누락된다 — 파일 경로로 찾을 것.
|
|
또한 **공유 프로젝트에는 `PAIX_PrismaticScanner` 같은 옛 이름 심볼이 그대로 남아 있으니** 머신 심볼과 혼동 금지
|
|
4. **260605 변경 이후 상태 파악** — SeqAutoRunPTOP이 최신 메인 시퀀스
|
|
5. **한글 주석 인코딩** — `docs/CODING_RULES.md` 확인
|
|
6. **주석·변수명·함수명을 맹신하지 않는다** (`rules.md` #1) — 위 3의 `PAIX_PrismaticScanner` 잔존이
|
|
그 사례다. 이름이 계층·소속을 말해 주지 않으므로 등록부·구현 본문으로 확인한다.
|
|
|
|
> 이 스킬은 10분을 넘긴다 — **단계 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
|
|
>
|
|
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
|
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|