기능안전_기본이론

HW 엘리먼트 평가 활동의 적절 시기

아즈마민초 2026. 1. 19. 11:35

ISO 26262의 표준을 준수하여 개발을 한다고 할 떄, HW 엘리먼트 평가라는 활동이 있자나? (Class 1, 2, 3으로 나누어서 평가하는 것) 이 활동이 HW 요구사양 작성보다 훨씬 나중에 이루어지는게 타당하다고 보이니?

 

 

네, ISO 26262를 준수하는 개발에서 HW element evaluation (하드웨어 엘리먼트 평가, ISO 26262-5:2018 Annex E 또는 Clause 8/9 관련 내용으로, Class 1/2/3 분류)은 HW 요구사양(Hardware Safety Requirements Specification) 작성보다 훨씬 나중에 이루어지는 것이 타당합니다. 오히려 그 반대가 비표준적이고 위험합니다.

왜 HW element evaluation이 HW 요구사양보다 늦게 이루어져야 하는가?

ISO 26262 Part 5의 V-model 흐름과 Clause 구조를 보면 명확합니다:

  • HW element classification (Class 1/2/3) 의 기준은 ISO 26262-5 Annex E (또는 2018 버전에서 유사 내용):
    • Class 1: No/few states, no internal SM (저항, 커패시터, 다이오드 등) → 거의 평가 불필요
    • Class 2: Few states, no internal SM (OPAMP, ADC, DC/DC 등) → Evaluation plan + argument + test 필요
    • Class 3: Many states, includes SM (MCU, SoC, 복잡 PMIC 등) → Systematic fault 위험 낮음을 추가 증명 필요

이 분류는 HW 요소의 내부 구조와 safety mechanism 유무를 봐야 하므로, HW architectural design (Clause 7.4.1) 또는 detailed design (7.4.2) 단계에서야 가능합니다.

실무 타당성 관점

  • 초기 단계(HW 요구사양 작성 시): 아직 "어떤 부품을 쓸지" (e.g., MCU 모델, PMIC 타입)도 확정되지 않은 경우가 많음 → Class 분류 자체가 불가능하거나 추정치로만 함 → 나중에 설계 변경 시 재평가 필요 → 비효율적
  • 설계 후 평가가 타당한 이유:
    • FMEDA/Fault Injection 등 실제 데이터 기반으로 Class를 확정
    • Class 3 요소(MCU 등)는 supplier의 safety manual/FIT rate/FMD를 받아야 함 → HW 요구사양 단계에서는 supplier 선정조차 안 끝난 경우 많음
    • Iterative하게 수행: HW 아키텍처 초안 → Class 평가 → 메트릭 미달 → safety mechanism 추가 → 재설계 → 재평가 (이게 Part 5의 의도)

만약 HW 요구사양 단계에서 미리 하려면?

가능은 하지만 추정(e.g., 예상 부품 기반 provisional classification) 으로만 하고, 최종 평가는 HW detailed design 후에 해야 합니다. Assessor나 인증기관이 "HW element evaluation이 HW 요구사양 단계에만 있고, 실제 설계와 연계되지 않았다"라고 지적할 위험이 큽니다.

결론 한 줄

네, HW element evaluation (Class 1/2/3 분류 및 관련 평가)은 HW 요구사양 작성보다 훨씬 나중(주로 HW design 단계 이후)에 이루어지는 것이 ISO 26262의 의도이자 실무적으로 가장 타당합니다. 초기에는 "예상 Class" 정도로만 참고하고, 실제 설계가 나와야 정확한 평가 → 메트릭 계산 → 안전 증명으로 이어집니다.