자동차에 탑재되는 전기전자시스템의 오동작(Malfunction)과 해저드로 인한 사고를 방지하기 위한 기준을 제공하는 기능 안전 국제 표준
위상
SW 공학 표준 분류상 “안전(Safety)” 영역의 생명주기 표준. 자동차 산업에서 A-SPICE와 함께 핵심 표준.
12개 Part 구조
| Part | 제목 |
|---|---|
| Part 1 | Vocabulary |
| Part 2 | Management of functional safety |
| Part 3 | Concept Phase |
| Part 4 | Product development on the system level |
| Part 5 | Product development on the hardware level |
| Part 6 | Product development on the software level |
| Part 7 | Production, operation, service and decommissioning |
| Part 8 | Supporting processes |
| Part 9 | ASIL-oriented and safety oriented analyses |
| Part 10 | Guideline on ISO 26262 (informative) |
| Part 11 | Guideline on application of ISO 26262 to semiconductors (informative) |
| Part 12 | Adaptation of ISO 26262 for motorcycles |
적용 대상
자동차, 모터사이클 및 상용차(트럭, 버스). 3.5t 무게 제한이 없어짐 (1st판에서 2nd판으로 갈 때).
- 제외: 특수 목적 차량(장애인 운전 차량 등), Moped(모터 달린 자전거)
판본 변천:
- 1st: Passenger Car (3.5t 이하)
- 2nd: Series production road vehicles
- Passenger Car
- Motorcycle (ISO/PAS 19695 통합)
- Truck (ISO/PWI 19284 통합)
- Bus (ISO/PWI 19284 통합)
안전 생명주기 / SW 안전 생명주기
V-Model 기반.
[Concept phase]
Item definition → Hazard analysis and risk assessment → Functional safety Concept
[Product development]
System level → HW level / SW level → Production release
[After Release of production]
Production → Operation, service & decommissioningPart 6 (SW 단계) 세부 활동
| 절 | 활동 |
|---|---|
| 6-6 | Specification of software safety requirements |
| 6-7 | Software architectural design |
| 6-8 | Software unit design and implementation |
| 6-9 | Software unit verification |
| 6-10 | Software integration and verification |
| 6-11 | Testing of the embedded software |
6-8 SW 상세설계+구현 통합: 일반 SW 개발은 상세 설계와 구현을 별도 단계로 구분하지만, 기능 안전 표준은 이를 하나의 단계로 인식한다. 상세 설계가 소스코드 전부를 명세할 수 없고, 구현 과정 자체가 지속적 상세 설계이기 때문. A-SPICE SWE.3도 동일하게 “Software Detailed Design and Unit Construction”으로 묶는다.
구조 용어: Item / System / Component / SW-Unit
차량 레벨부터 SW 단위까지의 계층 구조.
| 용어 | 정의 |
|---|---|
| Item | 차량 수준에서 기능의 일부를 구현하는 시스템 혹은 시스템들의 조합 |
| System | 최소 하나 이상의 Sensor, Controller, Actuator를 포함한 components/subsystems의 집합 |
| Component | 하나 이상의 HW-Part 또는 하나 이상의 SW Unit으로 구성된 시스템 수준이 아닌 element |
| SW-Unit | 독자적으로 테스팅 가능하며 더 이상 분류할 수 없는 (atomic level) SW 아키텍처의 SW Component |
→ Unit과 대응되지만 관점이 다르다: A-SPICE는 프로세스 평가 대상의 구조적 개체, ISO 26262는 안전 범위 정의의 기준.
핵심 개념 1: ASIL 등급
HARA 프로세스로 Hazardous Event를 Severity × Exposure × Controllability로 평가하여 결정.
- 4단계 등급: ASIL A < B < C < D (또는 QM)
- ASIL A 등급 이상에 대해 안전 목표(Safety Goal) 정의
※ ISO 26262는 IEC 61508의 SIL이 아닌 ASIL을 사용 (자동차 도메인 특화).
핵심 개념 2: 안전 요구사항의 전개
자세한 내용은 소프트웨어 요구공학 참조.
ASIL 등급별 적용 기법 예시
ISO 26262는 ASIL A~D별로 권장(+) / 강력 권장(++) 기법을 명시한다.
SW 아키텍처 단계 — Table 3
| Principles | A | B | C | D | |
|---|---|---|---|---|---|
| 1a | Appropriate hierarchical structure of the software components | + | ++ | ++ | ++ |
| 1b | Restricted size and complexity of software components | ++ | ++ | ++ | ++ |
| 1c | Restricted size of interfaces | + | + | + | ++ |
| 1d | Strong cohesion within each software component | + | ++ | ++ | ++ |
| 1e | Loose coupling between software components | + | ++ | ++ | ++ |
| 1f | Appropriate scheduling properties | ++ | ++ | ++ | ++ |
| 1g | Restricted use of interrupts | + | + | + | ++ |
| 1h | Appropriate spatial isolation of the software components | + | + | + | ++ |
| 1i | Appropriate management of shared resources | ++ | ++ | ++ | ++ |
1d (응집력) / 1e (결합도) — 소프트웨어 설계의 핵심 원칙과 직결.
SW 상세 설계 및 구현 단계 — Table 6
| Principle | A | B | C | D | |
|---|---|---|---|---|---|
| 1a | One entry and one exit point in subprograms and functions | ++ | ++ | ++ | ++ |
| 1b | No dynamic objects or variables, or else online test during their creation | + | ++ | ++ | ++ |
| 1c | Initialization of variables | ++ | ++ | ++ | ++ |
| 1d | No multiple use of variable names | ++ | ++ | ++ | ++ |
| 1e | Avoid global variables or else justify their usage | + | + | ++ | ++ |
| 1f | Restricted use of pointers | + | ++ | ++ | ++ |
| 1g | No implicit type conversions | + | ++ | ++ | ++ |
| 1h | No hidden data flow or control flow | + | ++ | ++ | ++ |
| 1i | No unconditional jumps | ++ | ++ | ++ | ++ |
| 1j | No recursions | + | + | ++ | ++ |
Table 6의 1a (one entry/exit), 1c (초기화), 1i (no goto)는 코딩 표준의 MISRA-C 2012 (15.1 goto 금지, 9.1 변수 초기화)와 일치한다.
SW 단위 테스팅 단계 예시
| Methods | A | B | C | D | |
|---|---|---|---|---|---|
| 1a | Statement coverage | ++ | ++ | + | + |
| 1b | Branch coverage | + | ++ | ++ | ++ |
| 1c | MC/DC (Modified Condition/Decision Coverage) | + | + | ++ | ++ |
→ ASIL이 높아질수록 더 엄격한 커버리지 기법이 요구됨.
SW 단위 설계·구현 검증 기법 — Table 9
SW 단위 설계와 구현을 14개 기법의 적절한 조합으로 검증해야 한다. 검토·정적 분석·테스트 3개 범주.
| Methods | A | B | C | D | 범주 | |
|---|---|---|---|---|---|---|
| 1a | Walk-through | ++ | + | o | o | 검토 |
| 1b | Pair-programming | + | + | + | + | 검토 |
| 1c | Inspection | + | ++ | ++ | ++ | 검토 |
| 1d | Semi-formal verification | + | + | ++ | ++ | 검토 + 정적 분석 |
| 1e | Formal verification | o | o | + | + | — |
| 1f | Control flow analysis | + | ++ | ++ | ++ | 정적 분석 |
| 1g | Data flow analysis | + | ++ | ++ | ++ | 정적 분석 |
| 1h | Static code analysis | ++ | ++ | ++ | ++ | 정적 분석 |
| 1i | Static analyses based on abstract interpretation | + | + | + | ++ | 정적 분석 |
| 1j | Requirements-based test | ++ | ++ | ++ | ++ | 테스트 |
| 1k | Interface test | ++ | ++ | ++ | ++ | 테스트 |
| 1l | Fault injection test | + | ++ | ++ | ++ | 테스트 |
| 1m | Resource usage evaluation | + | + | + | ++ | 테스트 |
| 1n | Back-to-back comparison test between model and code (해당 시) | + | + | + | ++ | 테스트 |
→ 검토(1a-1d) + 정적 분석 (1f-1i) + 테스트(1j-1n)의 조합. 1c Inspection은 페이건 인스펙션과 동일. 1f Control flow·1g Data flow·1h Static code·1i Abstract interpretation은 도구 기반 자동 검증.
테스트 기법 ASIL 권장도
Table 7(단위)·Table 10(통합)·Table 14(임베디드 SW)의 테스트 범주 5기법을 단계별로 통합한 표. “어떤 테스트를 수행해야 하는가?”에 답한다. 각 기법의 정의는 소프트웨어 테스팅 참조.
| Methods | Unit (A/B/C/D) | Integration (A/B/C/D) | Embedded SW (A/B/C/D) |
|---|---|---|---|
| Requirements-based test | ++ / ++ / ++ / ++ | ++ / ++ / ++ / ++ | ++ / ++ / ++ / ++ |
| Interface test | + / ++ / ++ / ++ | ++ / ++ / ++ / ++ | + / + / ++ / ++ |
| Fault injection test | + / + / + / ++ | + / ++ / ++ / ++ | + / + / + / ++ |
| Resource usage evaluation | + / + / + / ++ | + / ++ / ++ / ++ | — |
| Back-to-back comparison test between model and code (해당 시) | + / + / ++ / ++ | + / + / ++ / ++ | — |
Table 10(통합)은 Requirements-based·Interface·Fault injection·Resource usage·Back-to-back 외에 Control flow/data flow 검증, Static code analysis, Abstract interpretation 3기법을 추가로 포함. Table 14(임베디드 SW)는 Requirements-based와 Fault injection만 규정.
TC 도출 기법 ASIL 권장도
Table 8(단위)·Table 11(통합)·Table 15(임베디드 SW)를 통합한 표. “어떻게 TC를 도출해야 하는가?”에 답한다.
| Methods | Unit (A/B/C/D) | Integration (A/B/C/D) | Embedded SW (A/B/C/D) |
|---|---|---|---|
| Analysis of requirements | ++ / ++ / ++ / ++ | ++ / ++ / ++ / ++ | ++ / ++ / ++ / ++ |
| Generation and analysis of equivalence classes | + / ++ / ++ / ++ | + / ++ / ++ / ++ | + / ++ / ++ / ++ |
| Analysis of boundary values | + / ++ / ++ / ++ | + / ++ / ++ / ++ | + / + / ++ / ++ |
| Error guessing based on knowledge/experience | + / + / + / + | + / + / + / + | + / + / ++ / ++ |
| Analysis of functional dependencies | — | — | + / + / ++ / ++ |
| Analysis of operational use cases | — | — | + / ++ / ++ / ++ |
→ 단위·통합은 공통 4기법, 임베디드 SW 테스트는 기능 의존성 분석·운영 사용례 분석 2기법 추가. 블랙박스 기법과의 대응은 블랙박스 테스팅 기법 참조.
SW 통합 테스트 구조적 커버리지
통합 레벨은 단위 레벨과 달리 Function Coverage와 Call Coverage를 규정 (Statement/Branch/MC/DC는 단위 레벨).
| Methods | Integration (A/B/C/D) |
|---|---|
| Function coverage | + / ++ / ++ / ++ |
| Call coverage | + / ++ / ++ / ++ |
임베디드 SW 테스트(Table 14 범주)는 구조적 커버리지를 규정하지 않음 (소스코드 커버리지는 단위/통합 단계에서 확보).
커버리지 정의·한계·강도 비교는 화이트박스 커버리지 참조.
테스트 단계별 실행 환경 요구사항
In-the-loop 환경을 단위·통합·SW 테스트 단계별로 다르게 요구한다.
| 테스트 단계 | 허용 환경 |
|---|---|
| 단위 테스팅 | MIL / SIL / PIL / HIL (타깃 환경 실행 선호, 불가 시 환경 차이 분석) |
| 통합 테스팅 | MIL / SIL / PIL / HIL (동일 원칙) |
| SW 테스팅 (6-11) | 최소 HIL 이상 — ECU network environments, Lab car, Mule, Rest of bus, Vehicles |
→ SW 통합 후 단계는 가상 환경만으로 부족하며 실제 HW 또는 실차 수준 환경이 필수. 타깃 환경 실행이 불가능할 때는 환경 차이를 분석하여 이후 단계에서 추가 테스트로 보완해야 한다.
SW 안전 아키텍처 설계
SW 안전 요구사항을 구현하기 위해 추가적으로 필요한 SW 컴포넌트 및 컴포넌트 간 인터페이스 등을 설계에 반영하는 활동
결함 예방, 결함 감지, 결함 처리 등을 수행하기 위한 SW 안전 요구사항을 설계에 반영.
예시:
- 크루즈 시스템은 차량이 안전 거리 이내로 진입하면, 속도를 감속할 수 있어야 한다.
- 크루즈 시스템은 속도 감속 기능의 정상 동작 여부를 모니터링(감지) 해야 한다.
대표 결함 감지 기법:
- 센서 유효 영역 검사 — 입력 값이 유효 범위를 벗어나면 오류로 판단
- 메시지 타임아웃 모니터링 — 통신 메시지의 지연·누락 검출
- Fault Injection Testing — 비정상 조건을 강제 주입해 시스템 반응 확인
ISO 26262 vs SOTIF
ISO 26262는 Fault 기반의 사고를 다루지만, 자율주행 시대에는 부품이 정상 동작해도 의도된 기능의 한계로 인한 사고가 발생 → 이 영역을 SOTIF(ISO 21448)이 보완.
자율주행 아키텍처와 ASIL 분해
The Autonomous Safe Automated Driving 보고서 2판(2025-09)은 ISO 26262 기능안전성 적합이 현실적으로 ASIL 분해(decomposition)를 요구한다는 점을 강조했다. 보고서가 제시한 기능적 분할(채널 단위 DCF·레이어 단위 DCF·DSM·AD-EYE 등 비대칭 아키텍처)은 ADI를 잘 캡슐화된 서브시스템으로 나눠 ASIL 준수에 유리한 기반을 제공한다. 모놀리식 접근으로는 ASIL 분해를 통한 표준 적합 달성이 난망하다는 분석.
또한 보고서는 ISO 26262의 진단 커버리지(diagnostic coverage) 개념에 착안해 독립성 커버리지라는 새 평가 방법론을 제안했다. 의존 고장의 결합 요인별로 반정량적으로 커버리지를 부여해 ‘충분히 독립적’이라는 판단에 엄밀성을 부여한다.