이상탐지 · 이상 접수 대응
PlantPulse AI 는 이상을 감지하고, AI 가 진단해 조치를 제안하며, 사람이 승인해 조치를 실행하고, 그 결과를 자동으로 검증합니다.
화면에서는 이 건을 이상 접수라고 부릅니다 — 고장만이 아니라 알람 · 이상 신호로도 열리기 때문입니다. 2026-10-14 전의 화면에는 «고장 접수» 로 보입니다. API · 설정 키의 이름은 incident 입니다.
감지 (이상탐지 · 알람 · 고장 전조)
→ 확인할 이상 · 이상 접수 + 알림 (화면 · 메일 · Slack · 푸시)
→ AI 진단 (원인 후보 · 제안 조치)
→ 사람이 승인 (고쳐서 승인 · 거절) · 조치 실행
→ 자동 재발 검증 (기본 1시간 뒤)
→ 결과 기록 · 종결
화면에서 하는 일 — 확인 · 승인(고쳐서 승인 · 거절) · 조치 실행 · 결과 기록 · 종결 — 은 모두 제안(/tasks)의 한 상세에서 합니다 →
제안 — 할 일 · 이상 · 이상 접수를 끝까지. 이 쪽은 그 뒤에서 서버가 언제 무엇을 하는지를 적습니다.
«이상 진단» · «해결» 메뉴와 모바일 전용 판(/m)은 없어졌습니다. 확인할 이상과 이상 접수는 제안 › 할 일 › 돌발에 있고,
새 화면은 폰에서도 그대로 씁니다(홈 화면 앱으로 올려 둘 수 있습니다). 옛 주소는 넘어가지 않습니다 →
코파일럿 화면 지도 — 옛 주소
이상탐지 — 언제 무엇을 재나
| 무엇 | 주기(기본) | 설정 |
|---|---|---|
| 전체 훑기 — 모든 설비. 센서는 최근 태그가 움직인 설비만 | 2시간마다 | anomaly.schedule.cron |
| 타깃 탐지 | 10분마다 | anomaly.targeted.cron |
| ERROR 알람 받기(MQTT 구독) → 이상 접수 | 상시(구독 확인은 매분) | incident.mqtt.subscribe.cron |
| 고장 전조 조기경보 받기 → 이상 접수 | 매시 | incident.precursor.poll.cron |
| 엔진이 스스로 적은 AI 발견 받기 | 1분마다 | finding.poll.cron |
시각은 모두 설치의 공장 시간대 기준입니다.
한 설비 · 한 시간 = 한 행
설비 이상은 설비 하나에 한 시간마다 한 행으로 남습니다. 센서 · OEE · RAM · 에너지는 그 행 안의 갈래이고, 제목과 심각도는 이상 태그 수와 이상 분(최근 1시간 가운데 이상이었던 분)으로 정합니다.
| 심각도 | 최근 1시간의 이상 분(기본) | 설정 |
|---|---|---|
| 낮음 | 10분 이상 — 이보다 적으면 행을 남기지 않습니다 | anomaly.asset.min.minutes |
| 보통 | 20분 이상 | anomaly.asset.medium.minutes |
| 높음 | 40분 이상 | anomaly.asset.high.minutes |
- 제안의 확인할 이상 한 줄이 이 행입니다. 같은 원인에서 비롯된 이상은 한 줄로 묶여 보입니다.
anomaly.exclude.assets(기본TEST_*,ASSET_TEST_*)에 든 설비는 탐지에서 뺍니다.- 탐지 대상은 엔진이 설비마다 판정한 적격성을 따릅니다 — 센서 탐지 · 생산(OEE · RAM · 작업오더) · 에너지. 맞는 탐지가 하나도 없는 설비는 건너뜁니다.
- 임계는
anomaly.detector.score.threshold(센서, 비우면 엔진 기본값) ·anomaly.detector.domain.score.threshold(그 밖, 기본 0.5)입니다. 설비별 센서 임계는 AI 가 스스로 조정합니다 → AI 발견과 정확도
고장 전조 조기경보
시계열 엔진은 지금 파형을 과거 ERROR 알람 직전의 파형 모음과 맞대 고장 위험을 잽니다. 코파일럿은 그 결과를 매시 받아 와 고장으로 접수합니다 — 이상이 «이미 났다» 가 아니라 «날 낌새» 일 때 이상 접수가 먼저 생깁니다. 묻기에서 「이 설비 고장 전조 위험도를 확인해줘」 로 직접 물을 수도 있습니다 → 시계열 인사이트
이상 접수가 생기는 길
| 길 | 조건 |
|---|---|
| 설비 이상 | 심각도 높음 이상이면 자동으로(하한 incident.source.anomaly.minSeverity) |
| ERROR 알람 | 플랫폼 알람을 받는 즉시 |
| 고장 전조 | 위 조기경보 |
| 사람 | 제안의 확인할 이상에서 이상 접수로 올리기 |
| 자동화 | 자동화가 결과에 붙인 이상 접수 올리기를 사람이 승인하면 → 자동화 — 승인 행동 |
- 같은 문제가 이미 열려 있으면 새로 만들지 않고 그 이상 접수에 합칩니다(발생 횟수만 늡니다).
- 생긴 이상 접수는 진단 대기열에 들어가 AI 가 차례로 진단합니다(원인 추정과 조치안 넷까지).
- 소스별로 켜고 끕니다 —
incident.enabled·incident.source.*. - 예전의 와치는 없어져 더는 이상 접수를 올리지 않습니다. 예전에 와치가 올린 이상 접수는 그대로 남아 있습니다 → 자동화
알림 채널
| 채널 | 받는 조건 | 설정 |
|---|---|---|
화면 — 사이드바 알림 종과 알림 목록(/alerts) | 늘. 지난 24시간 내 범위의 확인할 이상 · 이상 접수 | — |
| 푸시 — 휴대폰 · 브라우저 | 심각도 높음(기본) 이상. 기기마다 설정 › 알림에서 켭니다 | push.enabled · push.notify.severity |
| 메일 | 받는 사람 · 등급을 설정했을 때 | anomaly.notify.email.* · incident.notify.email.* |
| Slack | 웹훅 · 등급을 설정했을 때 | anomaly.notify.slack.* · incident.notify.slack.* |
- 화면 알림과 푸시는 사람마다 그 사람의 설비 범위 안의 것만 갑니다.
- 푸시를 켜는 곳은 설정(
/settings) › 알림 › 휴대폰·브라우저 알림입니다. HTTPS 주소에서만 되고, iPhone · iPad 는 홈 화면에 올린 앱에서만 됩니다 → 코파일럿 화면 지도 — 설정 · 코파일럿 여는 법 - 푸시를 누르면 제안 › 할 일 › 돌발이 열립니다. 예전에 받은 알림 · 메일의 옛 링크는 넘어가지 않고 「찾는 화면이 없습니다」 를 보입니다 — 제안에서 찾습니다.
- 이상 · 이상 접수 알림의 메일 · Slack 은 관리 콘솔의 시스템 설정(
/admin/config)에서 위 키로 정합니다 → 코파일럿 관리 콘솔
관리 콘솔의 알림 채널(/admin/channels)에 등록하는 Teams · Slack 채널과 메일 허용 도메인은 자동화의 «보내기» 가 쓰는 것입니다 —
자동화가 결과를 메신저 채널 · 사내 메일로 보낼 때 여기서 등록한 채널과 허용한 도메인으로만 나갑니다. 위 표의 이상 · 이상 접수 알림은 이 화면을 쓰지 않고
시스템 설정의 키를 따릅니다(메신저는 Slack 웹훅). → 코파일럿 관리 콘솔 · 자동화 — 보내기
조치 네 가지 — 실행하면 실제로 일어나는 일
AI 진단이 내는 조치안은 네 유형이고, 제안 상세에서 조치 실행을 누르면 아래가 일어납니다.
| 유형 | 누르면 실제로 일어나는 일 |
|---|---|
알람 확인 (ack_alarm) | 플랫폼의 해당 알람을 확인 처리합니다 |
담당자 통보 (notify) | 받는 사람(아래)에게 이상 접수 요약 메일을 보냅니다. 메일 서버(SMTP)가 없는 설치에서는 실행할 수 없습니다(아래) |
현장 점검 지시 (inspect) | 수행 제안에 점검 카드를 내고 받는 사람(아래)을 배정하며, 결과 등록 링크가 담긴 메일을 보냅니다. 메일은 덧붙이는 것이라 SMTP 가 없어도 카드는 냅니다 |
추가 조사 (investigate) | 밖으로 나가는 동작이 없습니다 — «조사 항목을 접수했다» 는 사실만 실행자 · 시각과 함께 기록합니다 |
- 받는 사람 — 통보 · 점검을 받을 사람은 관리 콘솔 담당자 명단에서 옵니다(로그인 계정과 별개). 조치안의 역할(정비 · 운영 · 안전)과 담당자의 통보 역할이 같고, 담당 범위(사이트 · 설비 — 비우면 전체)가 이 이상 접수를 덮는 사람이 딱 한 명일 때만 저절로 정합니다. 없거나 여럿이면 실행하지 않고, 실행하는 사람이 화면에서 고릅니다. «명단의 첫 사람» 으로 보내는 일은 없습니다 → 코파일럿 관리 콘솔 — 담당자
- SMTP 가 없는 설치 — 메일 서버(
smtp.host·smtp.username)가 비어 있으면 담당자 통보는 이 설치에서 쓸 수 없습니다. AI 진단에도 이 조치를 내지 말라고 알리고, 그래도 나온 통보 조치는 화면에서 사유와 함께 막히며 실패 기록을 남기지 않습니다 — 몇 번을 눌러도 같습니다. 다른 채널로 바꿔 보내지 않습니다. 메일 서버가 보내기를 거절하면 「메일 서버가 통보 메일을 보내지 못했습니다(…). 메일 설정을 확인하세요.」 로 실패합니다 → 시스템 설정 - 누가 — «조치 실행» 권한(
approve:incident_action)이 있는 사람만 단추가 보입니다(기본 반장 · 정비 · 공장장 · 관리자) → 권한 조치안 승인 · 고쳐서 승인 · 거절은 이상 접수를 볼 수 있는 사람(menu:resolve)이면 합니다 → 제안 — 조치안 검토 - 중복 방지 — 두 사람이 동시에 눌러도 한쪽만 실행합니다. 실행된 조치는 다시 실행할 수 없고, 실패한 조치만 다시 실행합니다.
- 안전 범위 — 설비 제어 명령은 실행 대상이 아닙니다. 알람 확인 · 통보 · 카드 발행 같은 되돌릴 수 있는 조치만 실행합니다.
- 실행 · 실패 · 종결은 모두 상세의 경과에 실행자 · 시각과 함께 남습니다.
- 점검 지시 메일을 받은 담당자는 메일의 링크로 로그인 없이 조치 결과(완료 · 해당 없음과 메모)를 등록합니다.
자동 재발 검증
조치를 실행하면 한 시간 뒤(기본, incident.verify.delay.minutes = 60) 같은 설비에 이상이 다시 났는지 서버가 스스로 확인합니다. 확인은 매시 돕니다.
| 결과 | 화면 |
|---|---|
| 재발 없음 | 완료 탭에 «재발 없음», 머리 한 줄의 검증 통과 % 에 들어갑니다 |
| 재발 | 완료 탭에 «재발» 로 표시되고, 머리 한 줄의 재발 건수에 들어갑니다 — 추가 대응이 필요하다는 신호입니다 |
제안의 완료 탭 머리 한 줄(조치 · 처리 시간 · 검증 통과 · 재발 · 결과 대기)이 이 검증의 성적입니다.
손대지 않은 이상 접수는 스스로 닫힙니다
| 경우 | 기본 | 설정 |
|---|---|---|
| 이상 감지가 올린 이상 접수(사람이 아직 잡지 않은 것)가 재발 없이 조용함 | 6시간 뒤 «해소» 로 종결 | incident.autoresolve.quiet.hours |
| 처리 중인 이상 접수가 재발 · 상태 변화 없이 오래됨 | 7일 뒤 종결 | incident.stale.close.days |
| 진단을 받지 못한 채 남은 이상 접수 | 24시간 뒤 종결 | incident.diagnose.expire.hours |
0 이하로 두면 앞의 둘은 꺼집니다. 닫은 사실은 경과에 남습니다.
AI 발견에서 시작하는 조치
시계열 엔진이 스스로 찾은 AI 발견(오더 목표 미달 · 부품 지연 회복안 · 고장 위험 …)도 같은 원칙을 따릅니다 — AI 는 제안하고 사람이 정합니다. 어느 단추도 설비를 제어하거나 오더 · 일정을 바꾸지 않습니다. 발견의 종류와 알리는 규칙은 AI 발견과 정확도에 있습니다.
AI 제안 카드 — 수락 · 거절 · 효과
사람의 판단이 필요한 발견 — 오더 목표 미달 · 부품 지연 회복안 · 고장 위험 — 은 제안 › 계획에 AI 제안 카드로 올라옵니다 (고장 위험은 그 판정이 현장에 켜져 있을 때만). 상세의 AI 제안 판단 칸에서 수락 · 거절하고, 수락한 뒤에는 효과 있음 · 효과 없음 · 아직 모름을 남깁니다 → 제안 — AI 제안 판단
- 수락 · 거절은 기록만 합니다 — 오더 · 일정 · 설비는 자동으로 바뀌지 않습니다.
- 같은 설비 · 같은 종류의 발견은 그날 한 카드로 묶입니다.
- 묶인 발견이 모두 닫혔고 사람이 손대지 않은 카드는 목록에서 빠집니다(기록은 남습니다).
수리 후 자동 확인
거절 사유로 「이미 했습니다」 를 고르면, 서버는 그 조치가 먹혔는지 스스로 잽니다(finding.repair.enabled, 기본 켜짐).
| 결과 | 뜻 |
|---|---|
| 효과 확인됨 | 태그가 기준 범위로 돌아왔거나, 조건이 풀리고 다시 안 나타났습니다 |
| 효과 없음 | 같은 이상이 다시 나타났거나, 태그가 기준 범위 밖에 남았습니다 |
| 판단 불가 | 가동 중 데이터가 모자랐거나 조건이 풀린 것을 확인하지 못했습니다 |
확인 시간은 종류에 따라 다릅니다 — 대개 안정화 30분 + 확인 120분, 데이터 끊김 · 전력 피크는 15분 + 60분. 결과는 그 제안의 효과 기록으로 남고, 사람이 남긴 표시는 덮지 않습니다.
승인 → 초안
제안이 다른 시스템의 행동에 대응하면 카드에 승인하면 만들어지는 초안 칸이 생깁니다. 지금 대응하는 것은 둘입니다.
| 제안 | 만들어지는 것 | 대상 |
|---|---|---|
| 부품 지연 회복안 | 발주 라인 독촉 요청 초안 | 공급망(SCM) |
| 고장 위험 | 설비 정비 요청 | MES |
- 그 행동을 내는 켜진 커넥터가 디지털 스레드에 등록돼 있어야 합니다. 없으면 카드는 수락 · 거절 · 효과만 합니다.
- 만드는 것은 그 시스템의 초안 · 요청 하나입니다. 확정은 그 시스템 안에서 사람이 합니다. 같은 제안을 두 번 승인해도 초안은 하나입니다.
- 승인 사유 · 2인 승인 · 권한은 제안 — 승인하면 만들어지는 초안에 있습니다.
- 커넥터 등록은 AI 관리 콘솔의 디지털 스레드에서 합니다 → 디지털 스레드
관련 문서
- 제안 — 화면에서 확인 · 승인 · 조치 · 결과 · 종결
- AI 발견과 정확도
- 자동화 — 새 이상 접수가 생길 때 도는 자동화(경보 실행)
- 코파일럿 관리 콘솔 — 담당자 · 시스템 설정 · 설비 중요도 등급