§6.5.1 이 여섯 상태를 정의하고, §6.2.6 이 윈도우에 다섯을 정의한다. 시스템 전역에서 하나의 모델을 쓴다는 게 설계 일관성 측면에서 중요하다.
| 상태 | 의미 |
|---|---|
| 접수(수락) | 유효성·우선순위 통과, 실행 대기/시작 |
| 거부 | 조건 미충족으로 시작하지 않음 |
| 진행 | 실행 중 |
| 완료 | 목표 상태 도달 확인 |
| 중단 | 외부 요인으로 멈춤 — 의도된 개입 |
| 실패 | 실행했으나 목표 도달 못 함 — 의도치 않은 결과 |
중단과 실패의 구분이 중요하다
Anti-pinch 로 창문이 멈춤 → 중단 (시스템이 의도적으로 개입, 정상 동작)
도어락 구동했으나 타임아웃 → 실패 (원인 불명, 고장 가능성)
사용자 대응이 다르다 — 중단은 "다시 시도하세요", 실패는 "점검이 필요합니다".
거부는 반드시 사유와 함께
§6.2.2 윈도우 제어 요청을 거부한 경우 거부 사유를 HMI 에서 사용할 수 있도록 제공해야 한다
§6.5.1 제어 요청이 거부되거나 실패한 경우 그 사유를 사용자에게 제공해야 한다
요청이 아무 반응 없이 사라지는 게 가장 나쁜 UX 다. 사용자는 버튼이 고장 났는지, 명령이 안 갔는지, 일부러 막힌 건지 구분할 수 없다.
거부 사유는 열거형으로 공용화해야 한다. 기능마다 따로 만들면 HMI 가 기능별 메시지 테이블을 들고 있어야 하고, 새 기능이 생길 때마다 HMI 를 고쳐야 한다.