"고장이 나도 사람이 다치지 않게 만든다" 를 프로세스로 규정한 표준. IEC 61508에서 자동차용으로 갈라져 나왔다.
무엇을 요구하나 — 결과물이 아니라 과정
아이템 정의 무엇을 하는 기능인가
HARA 고장 시나리오마다 S·E·C 를 매겨 ASIL 결정
안전 목표 "조향이 의도치 않게 들어가면 안 된다"
안전 요구사항 시스템 → 하드웨어 · 소프트웨어로 내려간다
설계·구현·검증 등급에 맞는 방법과 커버리지
안전 논증(safety case) 위 전부가 추적 가능하게 이어진 증거 묶음
코드에 남는 흔적
등급이 정해지면 안전 메커니즘이 요구된다. 윈도우 워치독, ECC, CRC, MPU 기반 분리, 이중 저장, 주기 자가진단이 그 예다. "왜 이 코드가 이렇게 생겼나"의 답이 대부분 여기 있다.
흔한 오해 둘
- 제품이 인증을 받는 것이 아니다. 프로세스와 근거로 논증을 구성한다. MCU 데이터시트의 "ASIL B ready"는 논증에 쓸 재료가 준비돼 있다는 뜻이다.
- QM은 대충 해도 된다는 뜻이 아니다. ISO 26262의 추가 안전 활동이 없을 뿐, 일반 품질 프로세스는 그대로 적용된다.
신입에게 요구되는 깊이
조항 번호를 외울 필요는 없다. "위험도에 따라 개발 강도가 달라지고, 그 결과가 코드의 워치독·CRC로 나타난다" 까지 말할 수 있으면 충분하다.