§9 의 마지막 원칙이 이 문서 전체의 작성 기준이다.
"사용자 관점에서 관찰 가능한 기능과 안전 의도는 SR 에서 정의하고, Controller 간 내부 명령 전달, 상태 교환, 세부 중재 및 실행 메커니즘은 SysRS 또는 설계 문서에서 정의한다."
| 쓸 수 있나 | 문장 | 이유 |
|---|---|---|
| ○ | "끼임 위험을 감지한 경우 진행 중인 닫힘을 즉시 정지해야 한다" | 창문이 멈추는 걸 볼 수 있다 |
| ✗ | "모터 전류가 임계값을 초과하면 H-브리지를 브레이크 모드로 전환한다" | 내부 구현 |
| ○ | "잠금이 정상 완료된 경우 피드백 차임을 1회 출력해야 한다" | 듣고 횟수를 셀 수 있다 |
| ✗ | "CAN ID 0x210 프레임을 수신하면 오디오 태스크에 이벤트를 큐잉한다" | 내부 메커니즘 |
왜 이렇게 나누나
구현 방식을 바꿔도 요구사항이 안 바뀌게 하기 위해서다. "전류로 감지한다"를 SR 에 쓰면 로드셀로 바꿀 때 요구사항을 고쳐야 하고, 그러면 시험 항목까지 연쇄로 흔들린다.
TBD-009 가 "Anti-pinch 감지 방식"을 미정으로 둘 수 있는 이유도 이것이다 — SR 은 "감지해야 한다"만 말하고 방법은 안 정한다.
예외는 아키텍처 제약 요구사항
구조 자체가 안전을 보장하는 유일한 방법일 때만 내부 구조를 언급한다.