92 lines
4.8 KiB
Markdown
92 lines
4.8 KiB
Markdown
# P&ID Parser Detailed Implementation Plan (by Gemma 4)
|
|
|
|
## 1. 개요 (Overview)
|
|
본 계획은 대용량 DXF 파일 처리 시 발생하는 LLM 프롬프트 복잡도 및 하드웨어 부하 문제를 해결하기 위해, 기존의 단일 프로세스 추출 방식을 **분산 처리 방식(Distributed Processing)**으로 전환하는 상세 설계도입니다.
|
|
|
|
## 2. 데이터 인터페이스 설계 (Data Interface Specification)
|
|
|
|
### 2.1 중간 데이터 포맷 (Intermediate JSON Schema)
|
|
메인 프로그램이 `ezdxf`로 전처리하여 서브 프로그램에 전달할 데이터 구조입니다. 서브 프로그램은 이 JSON을 읽어 패턴 매칭을 수행합니다.
|
|
|
|
```json
|
|
{
|
|
"metadata": {
|
|
"filename": "string",
|
|
imtimestamp": "ISO8601"
|
|
},
|
|
"entities": [
|
|
{
|
|
"type": "TEXT | MTEXT | LINE | CIRCLE | LWPOLYLINE",
|
|
"layer": "string",
|
|
"content": "string (텍스트 내용)",
|
|
"coordinates": { "x": 0.0, "y": 0.0, "z": 0.0 },
|
|
"attributes": { "color": "int", "lineweight": "float" }
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
## 3. 컴포넌트별 상세 설계 (Component Detailed Design)
|
|
|
|
### 3.1 [Python] Main Processor (Orchestrator)
|
|
**역할**: DXF 전처리, 서브 프로세스 생명주기 관리, 결과 통합 및 DB 저장 요청.
|
|
|
|
- **Class: `DXFPreprocessor`**
|
|
- `load_and_parse(file_path)`: `ezdxf`를 사용하여 DXF를 로드하고 엔티티를 추출.
|
|
- `generate_intermediate_json(output_path)`: 추출된 엔티티를 위 JSON 스키마로 변환하여 저장.
|
|
- **Class: `ExtractionOrchestrator`**
|
|
- `run_parallel_extractors(input_json_path)`: `subprocess.Popen`을 사용하여 5개의 서브 프로그램을 병렬로 실행.
|
|
- `monitor_processes(process_list)`: 모든 프로세스가 종료될 때까지 대기하며 에러 발생 시 로그 기록.
|
|
- `aggregate_results(result_files)`: 각 서브 프로그램이 생성한 JSON 파일들을 읽어 하나의 `MasterExtractionResult`로 병합.
|
|
- **Class: `DatabaseIntegrator`**
|
|
- `send_to_backend(merged_data)`: 병합된 데이터를 .NET API(C#)로 전송.
|
|
|
|
### 3.2 [Python] Specialized Extractors (Sub-programs)
|
|
**역할**: 전달받은 JSON에서 특정 정규표현식(Regex) 패턴을 찾아 추출.
|
|
|
|
- **Common Logic (Base Class: `BaseExtractor`)**
|
|
- `load_input_json()`: 전처리된 JSON 로드.
|
|
- `apply_regex_pattern(pattern)`: 엔티티의 `content` 필드에 대해 Regex 매칭 수행.
|
|
- `save_output_json()`: 추출된 결과를 `result_{type}.json`으로 저장.
|
|
|
|
- **Specific Patterns (Regex Implementation)**
|
|
1. **`dxf_extract_transmitter.py`**: `r"(FIT|FT|LT|PT|TE)\s?-\s?\d+"`
|
|
2. **`dxf_extract_valve.py`**: `r"(FCV|LCV|TCV|PCV|XV)\s?-\s?\d+"`
|
|
3. **`dxf_extract_gague.py`**: `r"(PG|TG|LG)\s?-\s?\d+"`
|
|
4. **`dxf_extract_equipment.py`**: `r"(C|T|F|D|E|B|CT|CH|K)-?\d+"` (상세 규칙은 설계서 참조)
|
|
5. **`dxf_extract_pump.py`**: `r"(P|VP)-\d+"`
|
|
|
|
### 3.3 [C#] Backend Service (Data Persistence)
|
|
**역할**: Python으로부터 전달받은 데이터를 검증하고 `ExperionDbContext`를 통해 DB에 영구 저장.
|
|
|
|
- **Controller: `PidExtractionController`**
|
|
- `[HttpPost] PostExtractionResult(ExtractionDto dto)`: Python의 요청을 수신.
|
|
- **Service: `PidProcessingService`**
|
|
- `ProcessAndSave(ExtractionDto dto)`: 데이터 유효성 검사 후 `PidEquipment` 엔티티로 변환.
|
|
- **Repository: `PidRepository`**
|
|
- `SaveAsync(PidEquipment entity)`: SQL Server에 저장.
|
|
|
|
## 4. 상세 구현 로드맵 (Implementation Roadmap)
|
|
|
|
### Phase 1: 데이터 규격 및 환경 구축
|
|
- [ ] `IntermediateDataFormat.json` 스키마 확정.
|
|
- [ ] Python `ezdxf` 기반의 `DXFPreprocessor` 프로토타입 개발.
|
|
|
|
### Phase 2: 서브 프로그램(Extractor) 개발
|
|
- [ ] `BaseExtractor` 클래스 구현 (JSON 로드/저장/Regex 공통 로직).
|
|
- [ ] 5종의 특화된 Regex 패턴 적용 및 개별 스크립트 완성.
|
|
- [ ] **검증**: `test_dxf_extract_pid1.py`를 활용한 추출 정확도 테스트.
|
|
|
|
### Phase 3: 메인 오케스트레이터 개발
|
|
- [ ] `subprocess`를 이용한 병렬 실행 및 프로세스 모int 모니터링 로직 구현.
|
|
- [ ] 결과 파일 병합(Aggregation) 및 중복 제거 로직 구현.
|
|
|
|
### Phase 4: 백엔드 연동 및 통합 테스트
|
|
- [ ] C# API 엔드포인트 구현 및 Python `DatabaseIntegrator` 연동.
|
|
- [ ] **E2E 테스트**: DXF 파일 투입 $\rightarrow$ 분산 추출 $\rightarrow$ DB 저장 전체 파이프라인 검증.
|
|
|
|
## 5. 예외 처리 및 안정성 전략 (Error Handling)
|
|
- **DXF 오류**: 파일 손상 시 `DXFPreprocessor`에서 에러 로그 남기고 프로세스 중단.
|
|
- **서브 프로세스 실패**: 특정 서브 프로그램 실패 시, 해당 결과는 제외하되 다른 프로세스 결과는 유지하며 `Partial Success` 상태로 보고.
|
|
- **DB 연결 오류**: 재시도(Retry) 로직 적용 및 실패 시 로컬 파일로 결과 백업.
|