통신 오류 와 반드시 구분해야 한다. §6.5.3 이 명시적으로 요구한다.
"센서 오류, 통신 오류 및 기능 자체 오류를 사용자가 구분할 수 있도록 표시해야 한다."
왜 구분해야 하나 — 사용자의 행동이 다르다
| 오류 | 사용자가 할 수 있는 일 |
|---|---|
| 센서 오류 | 센서가 가려졌나 확인, 정비소 방문 |
| 통신 오류 | 잠시 기다림, 재시동 |
| 기능 자체 오류 | 정비 |
같은 아이콘으로 뭉뚱그리면 사용자는 아무것도 판단할 수 없다.
구현에 주는 제약
bool error_flag 하나로 만들면 이 요구사항을 절대 만족시킬 수 없다. 최소한 오류 원인을 열거형으로 들고 다녀야 하고, 한 기능이 동시에 여러 종류의 오류를 가질 수 있으므로 기능 × 오류종류 2차원이어야 한다.
typedef enum { ERR_SENSOR, ERR_COMM, ERR_FUNCTION, ERR_KIND_COUNT } err_kind_t;
typedef struct {
func_state_t state;
uint16_t err_detail[ERR_KIND_COUNT]; /* 종류별 세부 코드 */
} func_status_t;
Predictive Climate 가 습도 센서 고장(ERR_SENSOR)과 Sensing 노드 통신 두절(ERR_COMM)을 동시에 겪을 수 있는데, 단일 필드면 나중에 쓴 게 앞을 덮는다.