ISO 2626 - 하드웨어 구성 요소 별 소프트웨어 안전 메커니즘 분류

1. 개요: 왜 Software Safety Mechanism이 중요한가?

ISO 26262는 자동차 전장품의 기능안전을 규정하는 국제 표준이며, 전자 제어 시스템에서 발생할 수 있는 위험을 체계적으로 파악하고 방지하는 데 초점을 맞춥니다.
이 중 Part 5 Annex D는 소프트웨어 관점에서 고려해야 할 Safety Mechanism을 정리해 두었는데, 이는 하드웨어 고장(또는 잠재적 고장)에 대해 소프트웨어 차원에서 어떻게 검출·대응·완화할 것인가에 관한 방법들입니다.
자동차 ECU의 계산 능력과 기능 복잡도가 커짐에 따라, 하드웨어만으로 안전 문제를 모두 해결하기 어렵습니다. 이때 소프트웨어적인 진단과 보호 기법을 더해 ‘이중 안전장치’를 마련하는 것이 핵심입니다.

---

2. 하드웨어 구성 요소별 Software Safety Mechanism

아래 표는 ISO 26262 Part 5 Annex D에서 제시하는 대표적인 Software Safety Mechanism을 하드웨어 구성 요소별로 정리한 것입니다.

하드웨어 구성 요소	Software Safety Mechanism
센서	1. Failure detection by on-line monitoring 2. Input comparison / voting (1oo2, 2oo3 or beter redundancy) 3. Sensor valid range 4. Sensor rationality check
액츄에이터	1. Failure detection my on-line monitoring 2. Monitoring (i.e. coherence control)
제어기	1. Self-test by software: limited number of patterns (one channel) 2. Self-test by software cross exchange between two independent units 3. Software diversified redundancy (one hardware channel) 4. Reciprocal comparison by software 5. Stack over/under flow Detection 6. Watchdog  7. Monitoring of programme sequence
메모리 (Part 11)	1. RAM test 2. Parity bit / Checksum / CRC  3. Block replication  4. Memory monitoring using error-detection correction codes (ECC)
통신	1. Information redundancy 2. Frame counter

 

아래에서는 각 구성 요소별 소프트웨어 메커니즘이 어떤 역할을 하고, 왜 필요한지 간단히 정리하겠습니다.

2.1 센서(Sensor)

1. Failure detection by on-line monitoring
   • 센서에서 읽어 들인 값을 소프트웨어가 실시간으로 모니터링하여, 정상 범위를 벗어나거나 업데이트가 끊길 경우 고장을 감지합니다.
2. Input comparison / voting (1oo2, 2oo3 등)
   • 이중화(또는 삼중화)된 센서 입력을 비교·투표해 신뢰도를 높이는 방식입니다.
   • 예: 두 센서 중 하나만 정상 범위를 벗어나면 해당 센서를 불량으로 판정하고 나머지 센서 값을 사용합니다.
3. Sensor valid range
   • 센서 값이 물리적으로 가능한 범위 내에 있는지 검사합니다.
   • 예: 온도 센서가 -50℃ ~ 150℃ 범위 밖이면 이상으로 간주.
4. Sensor rationality check
   • 센서 값들 간 상호 관계가 합리적인지 판단합니다.
   • 예: 속도 센서와 엔진 RPM의 관계 등.

센서는 차량 주행에 필수적인 정보를 제공하기 때문에 조기 이상 감지가 매우 중요합니다.

 

2.2 액츄에이터(Actuator)

1. Failure detection by on-line monitoring
   • 액츄에이터(예: 모터, 밸브 등)의 동작 상태를 소프트웨어가 모니터링해, 목표 위치 대비 실제 위치/속도를 비교하여 이상 여부를 판단합니다.
2. Monitoring (coherence control)
   • 액츄에이터가 지령된 방향, 속도, 토크 등에 맞게 거동하는지 ‘일관성’(coherence)을 감시합니다.
   • 예: 브레이크 액츄에이터가 실제로 일정 수준의 압력을 내고 있는지 확인하여, 미작동 또는 과작동을 방지합니다.

액츄에이터는 출력부 역할을 하므로, 오작동 시 탑승자의 안전에 직접 영향을 미칩니다. 실시간 모니터링 및 이상 조치(감속, 비상정지 등)가 필수적입니다.

 

2.3 제어기(ECU)

1. Self-test by software (one channel, 제한된 패턴)
   • 실행 중인 소프트웨어가 자체적으로 몇 가지 테스트 패턴을 돌려, 간단한 기능적 문제를 스스로 진단합니다.
2. Self-test by cross exchange (독립된 2개 유닛 간 상호검증)
   • 이중화된 두 제어기 간 데이터를 교환하며 상호 결과를 비교·검증해 이상 유무를 판단합니다.
3. Software diversified redundancy (단일 하드웨어 채널에서 소프트웨어 중복)
   • 동일 하드웨어에 서로 다른 구현(알고리즘 등)의 소프트웨어를 동시에 수행해, 결과를 비교함으로써 오류 검출 확률을 높입니다.
4. Reciprocal comparison by software (상호 비교)
   • 소프트웨어 내 여러 모듈이 동일 계산을 수행한 뒤, 결과를 서로 비교하여 일치 여부를 확인합니다.
5. Stack over/under flow Detection
   • 소프트웨어가 사용하는 메모리 스택 범위를 초과(overflow)하거나 지나치게 적게 사용하는(underflow) 문제를 감지합니다.
6. Watchdog
   • 주기적으로 ‘생존 신호(Heartbeat)’를 보내지 않으면 CPU나 소프트웨어가 멈춘 것으로 판단하고, 시스템 리셋 등 대응을 수행합니다.
7. Monitoring of programme sequence
   • 소프트웨어가 정의된 순서(플로우)를 벗어나지 않는지 추적합니다
   • 예: 무한 루프, 점프 에러 등

ECU는 센서 정보, 제어 로직, 액츄에이터 지령 등 차량 내 전반적 제어의 ‘두뇌’ 역할을 합니다. 내부 진단과 모니터링 기법을 통해 정상 동작을 지속적으로 보증해야 합니다.

 

2.4 메모리(Memory)

1. RAM test
   • 시스템 가동 시 혹은 주기적으로 RAM 영역에 테스트 패턴을 써보고 읽어들이면서 물리적/논리적 결함을 확인합니다.
2. Parity bit / Checksum / CRC
   • 메모리 데이터에 대해 패리티 비트, 체크섬, CRC 등을 계산·검증함으로써 전송·저장 시 발생할 수 있는 비트 오류를 발견합니다.
3. Block replication (복제)
   • 메모리 블록을 여러 곳에 복제해 두고, 문제가 생기면 다른 블록에서 해당 데이터를 복원합니다.
4. Memory monitoring using ECC (Error Correction Code)
   • ECC 기법으로 단일비트 에러를 자동 수정하거나, 다중비트 에러를 감지해 데이터 무결성을 높입니다.

메모리 오류는 소프트웨어 전체 동작에 영향을 미치기 때문에, 오류 검출 및 복구 메커니즘이 매우 중요합니다.

 

2.5 통신(Communication)

1. Information redundancy (값 검사)
   • 통신 패킷에 반복 데이터나 체크섬 등을 추가해, 전송 도중 데이터 손상이나 비정상 변조를 검출합니다.
2. Frame counter (순서 검사)
   • 여러 프레임이 순차적으로 전송될 때, 각 프레임에 번호를 매겨 순서가 맞는지 검사합니다.
   • 패킷 손실·재전송 등의 이상 상황을 파악할 수 있습니다.

현대 차량은 각종 ECU 간에 CAN, LIN, Ethernet 등 다양한 통신 버스를 사용합니다.

통신 오류는 여러 ECU의 협조 제어에 혼선을 줄 수 있으므로, 데이터 무결성과 순서 보장이 필수입니다.

3. 마무리

이번 포스팅에서는 ISO 26262 Part 5 Annex D에서 정의하는 하드웨어 구성 요소별 소프트웨어 안전 메커니즘을 한눈에 살펴보았습니다. 실제 양산 차량 개발 현장에서는 이러한 기법들을 복합적으로 적용하여, 보다 높은 ASIL(Automotive Safety Integrity Level)을 만족시키는 방향으로 설계합니다.

• 다음 포스팅에서는 각 메커니즘별 구현 사례와 장단점을 좀 더 심도 있게 다룰 예정입니다.
• 또한 소프트웨어 안전 메커니즘을 어떻게 선택하고 우선순위를 두어야 하는지, 그리고 ASPICE나 다른 표준과의 연계성도 함께 살펴보겠습니다.

하드웨어와 소프트웨어가 긴밀히 협력해야 기능안전 목표(ISO 26262)와 성능 요구사항을 모두 달성할 수 있습니다.