권한과 운영
운영 전체 흐름
원시 계측만 쌓아두면 현장은 엑셀을 다시 켭니다. 에너지 도메인의 가치는 집계 이후입니다. 하루/주/월로 말고, 기준선과 비교하고, 요금과 탄소로 환산하고, 알람과 보고서로 운영에 넣는 단계입니다.
이 페이지는 각 단계를 한 장으로 요약하고, 자세한 내용은 단계별 페이지로 연결합니다.
1. 단계별 요약
| 단계 | 핵심 질문 | 핵심 데이터 | 자세히 |
|---|---|---|---|
| 마스터 | 어디서 쓰는가 | company ~ meter 계층 | 조직과 자산 계층 |
| 수집 | 값이 제대로 들어오는가 | 원시 계측, 계기 상태 | 계기와 수집 데이터 모델 |
| 품질 | 믿을 수 있는 값인가 | 결측률, 품질 플래그 | 데이터 품질과 결측 처리 |
| 집계 | 얼마나 썼는가 | 15분 / 시간 / 일·월·연 | 집계 구조 |
| 요금 | 돈이 얼마인가 | 시간대별 kWh × 단가 | 한전 요금 구조 |
| 탄소 | 얼마나 배출했는가 | 사용량 × 배출계수 | 탄소와 ESG |
| 기준선 | 얼마나 아꼈는가 | 조정 기준선 - 실측 | 기준선과 절감(M&V) |
| 알람 | 지금 문제가 있는가 | 규칙, 임계, 이벤트 | 알람 설계 |
| 보고서 | 경영진에게 어떻게 보고하는가 | 스케줄, HTML/PDF | 보고서 자동화 |
| 보전 | 왜 숫자가 바뀌었는가 | 점검, 교체 이력 | 점검, 유지보수, 교체 |
각 단계는 앞 단계의 품질에 의존합니다. 보고서 숫자가 이상하면 거꾸로 집계 → 품질 → 수집 → 마스터 순으로 의심하면 원인을 빨리 찾습니다.
2. 전체 프로세스
- 마스터 등록 (회사-공장-계기-수집기)
- 원시 수집
- 결측/이상치 처리
- 시간 → 일 → 월 집계
- 기준선 확정
- 절감/요금/탄소 산출
- 임계 초과 시 알람
- 스케줄 보고서 생성
- 현장 피드백으로 매핑·배율 보정
3. 실제 사용되는 IT 기술
에너지 도메인은 제조업 그리드와 비슷하지만, 시계열과 스케줄이 더 큽니다.
수집
- Python + pymodbus, paho-mqtt
- APScheduler, cron
- 현장 에이전트는 공장망, 서버는 별도망. 브로커를 가운데 둡니다
저장
- MariaDB / MySQL: 마스터, 집계, 보고서 메타
- 시계열이 커지면 월 파티션, 또는 별도 TSDB
- Redis: 최신값 캐시, 대시보드 현재 전력
API / 화면
- REST API (조직, 계기, 집계, 알람, 보고서)
- 대시보드 차트: Chart.js, ECharts, Grafana
- 그리드: AG Grid, DevExtreme. 계기 수백 개 일괄 조회
- 보고서: Jinja2 HTML, WeasyPrint PDF, 스케줄러
운영
- 타임존 고정 (KST)
- soft delete. 계기를 지워버리면 과거 집계가 고아가 됩니다
- 공통코드로 계기타입, 알람타입, 기준선타입 관리
어떤 라이브러리를 쓸지는 PL과 현장 통신 환경이 결정합니다. 트렌디한 스택보다 패킷 스펙과 집계 시각을 맞추는 쪽이 먼저입니다.