설비 고장 온톨로지 구축: 증상·원인 가설·정비 근거를 연결하는 법

설비 고장 온톨로지 구축은 관측한 증상, 원인 가설, 검토자가 확인한 원인과 조치 결과를 서로 다른 기록으로 연결하는 작업입니다. 같은 소음이 여러 원인에서 나올 수 있으므로 증상과 원인을 같은 뜻으로 묶지 않습니다. AI는 질문에 맞는 주장과 근거, 상충·철회 상태를 설명하고, 실제 진단과 작업·재가동 판단은 권한을 가진 현장 책임자가 별도 절차로 처리합니다.

정비 보고서에서 진동 증가를 검색하면 베어링 교체 기록과 정렬 조정 기록이 함께 나옵니다. 문장이 비슷하다는 이유로 두 기록을 같은 원인의 사례로 묶으면 검색 결과는 많아져도 설명은 부정확해집니다. 어떤 설비의 어느 위치에서 무엇을 관측했는지, 당시 원인을 누가 어떤 근거로 판단했는지 연결해야 과거 사례를 참고할 범위가 정해집니다. 조치 뒤 증상이 줄었다는 기록만으로 그 조치가 원인을 증명했다고 답해서도 안 됩니다.

이 글은 고장 지식의 의미와 근거를 연결하는 발주 범위입니다. 점검 접수, 작업지시, 부품 불출과 복귀 절차를 다시 설계하는 글은 아닙니다. 아래 설비 E1·E2, 보고서 D1·D2, 관측 O1과 주장 C1·C2는 모두 가상 예시이며 실제 설비의 진단 자료가 아닙니다. 센서 임계값, 진단 정확도와 안전한 재가동 조건은 제시하지 않습니다. 검색 화면을 운전 지시나 안전 승인 화면으로 사용하는 것도 제외합니다.

가상 E1에서 진동 증가 O1을 기록하고 작성자가 정렬 불량 C1을 원인 가설로 적었다고 가정합니다. 다른 보고서 D2에는 체결 상태를 더 확인해야 한다는 C2가 남아 있습니다. C1과 C2는 O1을 설명하려는 서로 다른 주장입니다. 두 문서가 같은 증상을 언급했다고 병합하지 말고 가설별 검토 상태를 유지해야 합니다. 발주팀은 질문에 하나의 확정 원인이 없을 때 시스템이 어떻게 보류하고 어느 근거를 보여 줄지 먼저 합의하세요.

SOSA의 관측 모델과 PROV의 출처 모델을 제한해서 사용한다#

2026년 11월 3일 W3C의 SSN/SOSA 권고안과 PROV-O 권고안 원문을 확인했습니다. SOSA는 관측 대상·속성·결과·시점 등을 표현하고 PROV-O는 출처 관계를 기술합니다. 이 글의 원인 주장 상태와 검토 절차는 업무 설계안입니다. 두 표준은 특정 설비의 원인, 진단 정확도나 안전한 재가동을 인증하지 않습니다.

• W3C SSN/SOSA: 관측 문맥을 표현하는 권고안의 의미를 참고하며 원인 확정 규칙으로 확대하지 않습니다.
• W3C PROV-O: 주장과 처리 과정의 출처를 연결하는 모델을 참고합니다.

원천 연결에서 답변 게시까지 주장 단위를 유지한다#

발주 자료는 설비 목록, 사건 번호, 용어 사전과 대표 보고서 묶음부터 준비합니다. 파일에는 원천 ID와 판번호, 작성·수정 시각, 열람 가능한 조직을 붙입니다. 보고서 본문에서 관측과 추측이 같은 문장에 섞여 있다면 원문 위치를 남기고 분리 후보로 등록하세요. 추출 과정이 원문의 서법을 바꾸지 않는지 확인합니다. 원인일 수 있다는 문구를 확인된 원인으로 바꾸는 오류는 문서 요약이 자연스러워도 반려합니다.

센서 원천과 정비 보고서를 연결할 때 설비명만 맞추지 않습니다. 측정 위치, 구성품 ID, 관측 기간과 단위를 함께 대사합니다. E1의 구동부 측정값과 E2의 외관 점검을 같은 증상으로 검색할 수는 있어도 같은 사건의 근거로 합치지 않아야 합니다. 시간대나 단위가 확인되지 않은 값은 비교 대상에서 보류합니다. 연결 실패 목록과 해소 담당자를 운영 화면에 남겨 데이터가 없는 상태와 아직 연결하지 못한 상태를 구분합니다.

AI 질문은 어떤 원인인가, 어떤 후보를 검토했나, 어떤 자료가 부족한가를 구분합니다. O1에 C1과 C2가 모두 가설로 남았다면 기대 답은 두 후보와 각각의 근거, 미확인 상태입니다. 확정 원인 하나를 요구해도 근거가 없으면 확정할 수 없다고 답해야 합니다. 과거에 유사 증상이 있었다는 이유로 현재 설비의 원인으로 복사하지 않습니다. 사용자가 사건 번호를 주지 않았다면 대상과 문맥을 먼저 확인하도록 질문 흐름을 설계합니다.

가상 D1이 정정돼 C1을 철회하면 해당 주장과 파생 요약, 검색 색인과 답변 캐시를 영향 대상으로 찾습니다. 문서 저장소만 최신판으로 바꾸고 검색 저장소에는 옛 결론을 남기면 답변이 계속 틀릴 수 있습니다. 반영이 완료될 때까지 현재 원인 답변을 보류하고 마지막 갱신 상태를 표시하세요. 철회 사실과 이전 근거판을 삭제하지 않아야 과거 시점에 어떤 자료를 읽고 답했는지 확인할 수 있습니다.

기술 검토 권한과 자료 등록 권한을 나눕니다. 외주 보고서를 업로드한 사람이 곧바로 원인을 확인 상태로 게시할 수 없도록 하되 조직의 실제 책임 구조에 맞춰 예외를 정합니다. 한 사람이 두 역할을 맡으면 어떤 역할로 판정했는지 남기세요. 제한 설비의 근거는 원문뿐 아니라 검색 요약과 관계도, 내보내기에서도 보호합니다. 권한이 없는 경로를 우회해 원인 후보를 보여 주는지 일반 사용자 계정으로 검수합니다.

원천 수집이 중단되면 마지막 성공 수신판과 미수신 범위를 드러냅니다. 검색 결과가 적다는 이유로 해당 설비에 고장이 없다고 답하면 안 됩니다. 근거 유효기간은 문서 작성일과 별도 정책으로 정하고 재검토가 필요한 조건도 명시하세요. 운전 문맥이 달라졌다면 예전 확인 원인의 적용 범위를 다시 확인합니다. 운영자는 미확인 원천을 채우는 업무를 맡고 기술 판단은 검토자에게 넘겨 시스템 관리자가 원인 판정을 대신하지 않게 합니다.

정답 문장보다 후보·확인·보류의 경계를 검수한다#

정답 묶음은 현업 검토자가 대표 질문과 기대 상태를 함께 작성합니다. O1에 관측만 있고 주장이 없다면 원인 미확인이 기대값입니다. C1이 가설이면 후보와 근거를 보여 주되 확인 원인으로 표현하지 않습니다. 검토 확인된 C1이 있어도 해당 사건과 범위를 함께 제시합니다. 같은 증상인 E2를 질문하면 E1의 확인 결과를 그대로 넘기지 않아야 합니다. 이 표본들은 진단 정확도를 측정하는 시험과 구별해 검색·표현 경계의 검수에 사용합니다.

상충 표본에는 유효한 D1과 D2가 다른 원인을 주장하도록 구성합니다. 기대 결과는 양쪽 근거와 미합의 표시, 추가 확인 책임입니다. 문서 수가 많거나 작성일이 최근이라는 이유만으로 한쪽을 자동 확정하면 반려하세요. 검토자가 특정 주장만 기각하면 그 주장 상태만 바뀌어야 합니다. 관측 O1 자체를 삭제하거나 다른 사건의 같은 용어까지 일괄 기각하는 오류가 없는지도 확인합니다.

철회 검수에서는 C1을 인용한 답변을 만든 뒤 근거판을 철회합니다. 새 질문에는 철회한 결론이 현재 확인 원인으로 나오지 않고 과거 답변 이력에는 당시 참조판과 이후 철회 상태가 남아야 합니다. 검색·직접 조회·AI 설명이 같은 게시판을 읽는지 비교하세요. 현장 확인을 기다리는 주장을 운영자가 강제 확인으로 바꿀 수 없고 대량 업로드와 API에서도 같은 상태 규칙을 지키는지가 인수 조건입니다.

복구는 잘못 연결한 설비나 보고서판을 해제하고 영향받은 주장과 질문 목록을 다시 계산하는 절차로 준비합니다. 직전 게시판으로 되돌리더라도 그 근거가 철회됐거나 접근 권한이 바뀌었다면 그대로 재게시하지 않습니다. 유효한 복구판이 없으면 원인 답변을 보류하고 원천 문서를 찾는 제한된 조회만 제공합니다. 복구 담당자는 기술 검토자에게 미해결 주장 목록을 넘기고 재게시 승인 결과를 별도 기록합니다.

납품 인수물에는 어휘 정의와 금지 추론 예시, 설비·사건 ID 대응표, 관측·주장 관계 명세, 원천 수집 범위와 권한표를 포함합니다. 질문별 기대 상태와 실행 결과, 철회 반영 및 캐시 해제 절차도 받아야 합니다. AI 설명을 끈 상태에서도 담당자가 사건에서 근거판을 직접 찾을 수 있는지 확인하세요. 실제 진단, 설비 제어, 안전 작업과 재가동 승인을 넣으려면 별도 전문 검토와 명시적 범위 결정이 필요하며 이 지식 조회 구축과 합쳐 완료 처리하지 않습니다.

정비 작업의 운영 흐름은 설비보전 시스템 설계에서 구분해 보세요. 답변 이력의 출처는 AI 답변 근거 추적와 함께 검토합니다. 게시 승인 책임은 온톨로지 사람 검토 흐름를 참고하세요.