개념
이 레슨이 닫는 두 가지
레슨 3에서 철도·61508 계열의 도구 등급(T1~T3)을 봤다. 자동차 쪽인 ISO 26262는 같은 문제를 다른 방식 으로 푼다. 도구를 종류로 분류하지 않고, 그 도구를 어떻게 쓰는가(사용 사례) 로 신뢰 수준을 판정한다. 이 레슨의 앞 절반이 그것이다.
뒤 절반은 모듈 전체를 닫는다. 레슨 1의 기법 선택표, 레슨 2의 단위 검증 증거, 레슨 3의 역할 배치표와 도구 등록부, 레슨 4·5의 MISRA 준수 체계 — 이 산출물들이 시험소에 들어가 성적서 한 건 으로 나오기까지 무엇이 판정되고 무엇이 판정되지 않는지 정리한다.
도구 분류가 아니라 사용 사례 분류
ISO 26262-8의 11절은 소프트웨어 도구 사용에 대한 신뢰를 다룬다. 출발점은 도구 목록이 아니라 사용 사례 목록 이다. 같은 정적 분석기라도 이렇게 쓰임이 다를 수 있다.
사용 사례 U1 정적 분석기로 MISRA 위반을 찾고, 결과를 리뷰어가 코드 리뷰에서 다시 확인한다
사용 사례 U2 정적 분석기의 "위반 0" 결과를 근거로 해당 규칙의 수동 리뷰를 생략한다U1에서 도구가 위반을 놓쳐도 리뷰가 잡을 기회가 있다. U2에서는 도구가 놓치면 아무도 잡지 못한다. 같은 도구가 두 사용 사례에서 다른 신뢰 수준을 받는다. 모듈 25 레슨 5에서 "이 도구를 썼기 때문에 그 검증 활동을 생략했다고 말하는 순간 그 도구는 자격을 갖춰야 한다"고 했던 원칙이 여기서 판정 절차가 된다.
TI · TD · TCL
사용 사례마다 두 가지를 판정한다.
도구 영향(Tool Impact, TI)
| 등급 | 뜻 |
|---|---|
| TI1 | 도구가 오동작해도 안전 관련 요소에 오류를 넣거나, 오류를 놓치게 만들 가능성이 없다 |
| TI2 | TI1이 아닌 모든 경우 |
도구 오류 검출(Tool error Detection, TD)
| 등급 | 뜻 |
|---|---|
| TD1 | 도구의 오동작과 그 잘못된 출력이 예방·검출될 것이라는 높은 확신이 있다 |
| TD2 | 중간 수준의 확신 |
| TD3 | 그 밖의 모든 경우 |
두 값으로 도구 신뢰 수준(Tool Confidence Level, TCL) 이 정해진다.
TD1 TD2 TD3
TI1 TCL1 TCL1 TCL1
TI2 TCL1 TCL2 TCL3TCL1은 적격성 확인이 필요 없고, TCL2·TCL3는 필요하다. 한 도구에 사용 사례가 여럿이면 가장 높은 TCL이 그 도구의 요구 수준이 된다.
앞의 두 사용 사례에 적용하면 이렇다.
| 사용 사례 | TI | TD | TCL | 이유 |
|---|---|---|---|---|
| U1 리뷰로 재확인 | TI2 | TD1 | TCL1 | 놓칠 수는 있지만 후속 리뷰가 높은 확신으로 검출 |
| U2 리뷰 생략 근거 | TI2 | TD3 | TCL3 | 놓치면 후속 검출 수단이 없음 |
여기서 실무적인 선택지가 생긴다. U2를 U1으로 바꾸면 적격성 확인 비용이 사라진다. 반대로 리뷰 공수를 줄이려고 도구에 판단을 위임하면 적격성 확인 비용이 생긴다. 이 교환을 비용으로 비교하는 것이 도구 전략 회의의 실체다.
오래된 백서나 교육 자료 중에는 규격 초안(DIS) 시기의 표기(TI0/TI1, TD4 등)를 쓴 것이 있다. 발행된 ISO 26262-8:2018의 표기와 다르므로, 인용할 때는 발행본의 표기로 옮긴다.
TD를 정할 때 무엇을 근거로 삼는가
TD 판정은 도구 밖의 확인 수단까지 고려한다. 도구 자체의 내부 감시 기능뿐 아니라, 개발 프로세스 안의 리뷰·시험·다른 도구가 그 오류를 잡을 수 있는지를 본다.
| 도구 | 사용 사례 | 도구 오류 예 | 후속 검출 수단 | TD 판단의 근거 |
|---|---|---|---|---|
| 커버리지 측정기 | 분기 커버리지 달성 판정 | 밟지 않은 분기를 밟았다고 보고 | 레슨 3의 알려진 답 샘플로 정기 확인, 미도달 분석 리뷰 | 샘플 확인 주기와 범위 |
| 크로스 컴파일러 | 타깃 실행 코드 생성 | 최적화로 잘못된 코드 생성 | 타깃(PIL·HIL)에서 요구사항 기반 시험 재실행 | 시험 커버리지와 최적화 수준 동일성 |
| 단위 시험 하니스 | 시험 실행과 합부 판정 | 실패를 성공으로 기록 | 결과 원자료(로그) 무작위 재확인 | 재확인 표본 크기 |
| 요구사항 관리 도구 | 추적 매트릭스 생성 | 추적 링크 누락 | 추적 매트릭스 수동 리뷰 | 리뷰 방식 |
두 번째 줄이 레슨 2와 연결된다. 레슨 2에서 계측 빌드와 비계측 빌드를 대조 하라고 한 것, 호스트와 타깃의 차이를 분석하라고 한 것이 컴파일러 사용 사례의 TD 근거 로 다시 쓰인다. 시험 활동이 도구 신뢰의 증거가 되고, 도구 신뢰가 시험 결과의 증거가 되는 순환 구조 다. 그래서 TD 근거로 드는 시험이 그 도구에 의존하지 않는지 를 확인해야 한다. 같은 컴파일러로 빌드한 코드를 같은 환경에서만 시험했다면 컴파일러 오류를 검출한다고 주장하기 어렵다.
적격성 확인 방법 — 넷 중 무엇을 고르는가
TCL2·TCL3 도구에 대해 규격은 네 가지 적격성 확인 방법을 제시하고, ASIL에 따라 권고 강도가 달라진다.
| 방법 | 내용 | 실무 평가 |
|---|---|---|
| 1a 사용 경험에 의한 신뢰 | 비슷한 사용 조건에서 안전 관련 오동작 없이 쓰인 기록 | 기록 요건이 까다롭고, 높은 ASIL·TCL로 갈수록 권고 강도가 낮아진다 |
| 1b 도구 개발 프로세스 평가 | 도구가 적절한 표준에 따른 프로세스로 개발됐는지 평가 | 상용 도구에서 벤더 인증서로 자주 쓰인다 |
| 1c 소프트웨어 도구 확인(validation) | 사용 사례의 요구에 대해 도구가 올바르게 동작함을 시험으로 입증 | 가장 흔히 쓰이는 방법 중 하나. 사내 환경·설정에서 수행해야 의미가 있다 |
| 1d 안전 표준에 따른 개발 | 도구 자체를 안전 표준에 따라 개발 | 상용 도구에서는 드물다 |
해설 자료들은 실무에서 1b와 1c가 가장 많이 쓰인다고 평가한다. 여기서 흔한 오해 하나를 짚어야 한다. 벤더가 판매하는 "적격성 확인 키트(qualification kit)"는 적격성 확인 자체가 아니다. 키트는 1c를 수행하기 위한 시험 스위트와 문서 틀이고, 그것을 우리 사용 사례·우리 도구 버전·우리 설정·우리 환경에서 실행한 기록 이 증거다. 모듈 34 레슨 3에서 칩 제조사의 보안 기능이 완제품 인증을 대신하지 못한다고 했던 구조와 같다.
적격성 확인 산출물은 대체로 네 가지로 정리된다 — 도구 적격성 확인 계획, 도구 문서, 도구 분류 분석 (TI·TD·TCL), 도구 적격성 확인 보고서. 레슨 3의 도구 등록부에 "TCL" 열과 "분류 분석 문서 ID" 열을 더하면 두 계보(61508 T1~T3와 26262 TCL)를 한 장에서 관리할 수 있다.
| 도구 | 버전 | 사용 사례 | T 등급(61508/62279) | TI | TD | TCL | 적격성 방법 | 보고서 ID | 기준선 |기능안전 시험성적서 — 무엇을 판정했는가를 먼저 적는다
이제 모듈 전체를 성적서 한 건으로 묶는다. 레슨 1에서 과정 규격(61508-3·26262-6·62279)으로 시험소가 하는 일을 증거 적합성 검토·독립 재수행·표본 시험 의 세 갈래로 나눴다. 성적서는 이 세 갈래를 표지에서부터 구분해 드러내야 한다.
1. 표지 규격·파트·판 (예: ISO 26262-6:2018, MISRA C:2012 + AMD)
대상 소프트웨어: 이름·버전·빌드 해시 · 목표 등급(ASIL/SIL)
2. 시험 범위 수행한 갈래와 수행하지 않은 것
✔ 증거 적합성 검토 (목록은 4장)
✔ 독립 재수행: 정적 분석, 단위 구조 커버리지 측정
✔ 표본 시험: 요구사항 표본 N개
✘ 기능안전 평가(assessment)·확인 — 이 성적서의 범위 아님
3. 판정 기준 목표 등급별 표(레슨 1·2), 준수 체계(레슨 5), 결정 규칙
4. 검토한 증거 문서 ID·버전 목록 (기법 선택표, 단위 검증 명세, 역할 배치표, 도구 등록부, GEP·GRP·편차·GCS …)
5. 재수행 결과 도구·버전·설정·TCL, 제조사 결과와의 대조표, 차이 원인
6. 표본 시험 표본 추출 방법, 요구사항 → 케이스 → 실행 결과
7. 발견 사항 판정에 영향을 주는 것 / 개선 권고 — 구분해서
8. 의견과 해석 (있다면) 권한자·근거와 함께, 판정과 분리
9. 한계 환경(호스트·시험대 범위), 채택 코드 제외, 표본의 대표성2번의 "수행하지 않은 것" 칸이 이 성적서의 신뢰를 만든다. 모듈 32 레슨 7에서 과정 규격 성적서의 판정 대상이 제품이 아니라 증거 라고 했다. 그리고 규격이 따로 정한 기능안전 평가(assessment) 는 독립 평가자의 활동이지 시험 성적서가 아니다. 성적서가 그것을 대신하는 것처럼 읽히면 레슨 3에서 본 평가자 독립성 구조가 무너진다.
발견 사항의 두 층과 의견의 자리
7번 발견 사항은 두 층으로 나눈다.
| 층 | 예 | 성적서에서의 무게 |
|---|---|---|
| 판정에 영향 | ASIL C 모듈의 분기 커버리지 미도달 17건 중 근거 없는 5건 / 필수 MISRA 규칙 위반 1건 / 검증자·설계자 겸임 흔적 | 해당 항목 판정을 "부적합" 또는 "판정 보류"로 만든다 |
| 개선 권고 | 편차 허가 사유가 일반적임 / 도구 등록부의 버전 표기가 CI 설정과 다른 형식 | 판정은 유지되며 참고로 기록 |
"판정 보류"라는 칸을 두는 것이 중요하다. 제조사에게 추가 증거를 요청해야 판정할 수 있는 항목을 억지로 적합·부적합으로 가르면, 모듈 31 레슨 6에서 본 재발행 이 뒤따른다.
8번 의견은 모듈 32 레슨 6의 17025 7.8.7을 따른다. "이 수준이면 ASIL C 프로젝트로 충분하다고 판단된다" 같은 문장은 판정이 아니라 의견이다. 권한 있는 사람이 근거와 함께, 판정 표와 물리적으로 분리된 절 에 적는다.
모듈 전체를 한 표로 — 산출물이 성적서의 어느 절로 가는가
| 레슨 | 제조사 산출물 | 성적서 절 | 시험소가 하는 일 |
|---|---|---|---|
| 1 | 기법 선택표, 미도달 분석표 | 4 · 7 | HR 미채택 근거 검토, A→B 전개 확인 |
| 2 | 단위 검증 명세, 추적표, 커버리지 리포트, 환경 차이 분석 | 4 · 5 · 6 | 커버리지 재측정, MC/DC 독립 쌍 표본 확인 |
| 3 | 역할 배치표, 도구 등록부 | 4 · 7 | 문서 간 이름 대조로 독립성 확인 |
| 4 | 판·언어 표준 확정 문구 | 1 · 3 | 판정 기준 고정 |
| 5 | GEP · GRP · 편차 · GCS | 4 · 5 | 독립 재수행 대조표 |
| 6 | 도구 분류 분석(TCL), 적격성 보고서 | 5 · 9 | 시험소 자체 도구의 TCL·버전 기재, 제조사 도구 TCL 근거 검토 |마지막 줄에 시험소 자신의 도구 가 들어간다는 점을 놓치지 말자. 시험소가 재수행에 쓴 정적 분석기와 커버리지 측정기도 결과를 만드는 도구다. 모듈 32 레슨 3의 측정 소급성과 레슨 4의 원자료 관리가 여기서 시험소 도구의 버전·설정·확인 기록 으로 성적서 5절에 들어간다.
실무에서 왜 필요한가
도구 신뢰는 기능안전 프로젝트의 숨은 일정 이다. 도구를 다 고른 뒤에 TCL 분석을 하면, TCL3로 나온 도구의 적격성 확인에 몇 주가 들고, 그 사이 도구 버전을 올릴 수 없다. 반대로 개발 계획 단계에서 사용 사례를 먼저 적고 "리뷰를 남겨 TD1을 확보할지, 도구에 위임하고 적격성을 확인할지"를 결정하면 비용이 예측된다.
적격성 확인 키트를 사는 것으로 끝났다고 믿는 조직은 심사에서 흔히 막힌다. 키트를 자기 환경에서 돌린 기록 이 없고, 도구 버전을 올린 뒤 재확인한 기록도 없다. 도구 등록부의 버전·TCL·보고서 ID·기준선이 한 줄로 이어지는지 확인하는 것만으로 이 지적 대부분을 막을 수 있다.
성적서 쪽에서는 범위와 한계를 먼저 쓰는 습관 이 시험소를 보호한다. 기능안전 영역의 성적서는 사고가 나면 법적 분쟁의 증거가 된다. 모듈 31 레슨 5에서 성적서의 책임 범위를 다뤘는데, 과정 규격 성적서에서 그 범위는 "어떤 증거를, 어떤 방법으로, 어디까지 봤는가" 로만 정의된다. 수행하지 않은 것을 적지 않은 성적서는 수행한 것 이상의 책임을 떠안는다.