기술 및 엔지니어링 정보/Functional Safety (ISO26262)

ISO 26262 - Software Safety Mechanism 개념, 구현 사례, 장단점 정리

Junique 2025. 5. 6. 00:09
반응형

1. 개요

자동차 전자제어 시스템이 복잡해짐에 따라, 하드웨어적인 안전 대책(이중화, 보호회로 등)만으로는 충족되지 않는 부분이 늘어나고 있습니다. 이에 소프트웨어 레벨에서도 안전 기법을 적용해 하드웨어 고장 및 오동작에 대처하고, 시스템 전체의 무결성과 가용성을 높이는 것이 필수가 되고 있습니다.

이 글에서는 지난 포스팅에서 나열했던 센서·액츄에이터·제어기·메모리·통신 각각의 Software Safety Mechanism을 실제 개발 현장에서 어떻게 구현할 수 있는지 사례와 함께 살펴보겠습니다.

 

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

1. 개요: 왜 Software Safety Mechanism이 중요한가?ISO 26262는 자동차 전장품의 기능안전을 규정하는 국제 표준이며, 전자 제어 시스템에서 발생할 수 있는 위험을 체계적으로 파악하고 방지하는 데 초점

ji-se.tistory.com

2. 센서(Sensor) Software Safety Mechanisms

2.1 Failure Detection by On-line Monitoring

  • 개념: 센서 입력 값을 실시간으로 읽어들여, 정상 범위를 벗어나거나 일정 기간 업데이트가 없는 경우 고장을 감지
  • 구현 사례:
    • ADC(Analog-to-Digital Converter) 기반 센서: 소프트웨어가 정기적으로 센서 값을 읽고, 미리 설정된 최소/최대 한계를 벗어나면 에러 플래그를 설정
    • 펄스 신호 센서(예: 휠 스피드 센서): 펄스가 일정 주기 이상 미갱신 시 ‘No signal’로 판단
  • 장점:
    • 구현이 비교적 간단하고, 거의 모든 종류의 센서에 적용 가능
    • 빠른 고장 감지(실시간)
  • 단점:
    • 미세한 드리프트(drifts)나 간헐적 에러를 포착하기 위해서는 추가 로직(히스테리시스, 필터링 등)이 필요
    • 센서 자체 고장 외에 커넥터 느슨함, 노이즈 등 간접 원인은 정확히 구분하기 어려움

2.2 Input Comparison / Voting (1oo2, 2oo3 등)

  • 개념: 여러 센서를 중복 배치하고, 소프트웨어적으로 입력 값을 비교·투표하여 대표값을 결정
    • 1oo2(one out of two): 2개 센서 중 하나라도 정상 범위를 벗어나면 오류
    • 2oo3(two out of three): 3개 센서 중 2개가 일치하면 정상, 1개는 오탐 가능
  • 구현 사례:
    • 브레이크 페달 센서 2중화: 둘 중 하나의 출력이 비정상이면 시스템은 즉시 브레이크 안전 모드로 전환
    • 스티어링 토크 센서 3중화: 세 센서를 교차 비교하여 다수결로 신뢰도를 결정
  • 장점:
    • 하드웨어 고장 하나만으로 전체 시스템이 다운되지 않음(고장 허용도 상승)
    • 비교 로직이 명확해 디버깅이 용이
  • 단점:
    • 센서가 여러 개 필요하므로 비용과 공간이 증가
    • 소프트웨어 비교 로직이 복잡해질 수 있으며, 투표 전략에 따른 추가 설계 노력이 필요

2.3 Sensor Valid Range

  • 개념: 센서 값이 물리적으로 불가능한 범위를 나타낼 경우 소프트웨어에서 즉시 에러 처리
  • 구현 사례:
    • 온도 센서: -50°C ~ 150°C 사이에 있어야 하며, 이를 벗어나면 센서 고장 플래그
    • 유량 센서: 0~100 L/min 범위를 넘어서는 값은 소프트웨어에서 ‘Invalid’ 처리
    • X : 물리적 센서 값 Y : 측정된 센서 값 (전압 관점) A : 범위를 벗어난 값 (high) B : 범위를 벗어난 값 (low)
  • 장점:
    • 기본적이면서도 강력한 방어 기법
    • 센서 드라이버 레벨에서 바로 적용 가능
  • 단점:
    • 센서 오류 상황이 실제로 범위 내로 가짜 입력을 내보낼 경우(노이즈 등) 검출 못함
    • Valid Range 설정이 부정확하면 정상값도 차단할 위험

2.4 Sensor Rationality Check

  • 개념: 센서 여러 개의 상호 연관 관계(‘합리성’)를 검사하여 비정상적 상황을 감지
  • 구현 사례:
    • 차량 속도 vs 엔진 RPM: 특정 기어 단에서 속도와 RPM이 불일치하면 이상으로 판단
    • 브레이크 압력 vs 브레이크 스위치: 압력이 높아지면 스위치도 ON 상태가 되어야 함
  • 장점:
    • 단일 센서가 이상치가 아니더라도, ‘논리적 불일치’로 고장을 조기 감지 가능
    • 고장 진단 범위를 넓힐 수 있음
  • 단점:
    • 관련 센서들이 모두 정확히 동작한다는 전제 필요
    • 부정확한 모델(논리 관계 설정) 시 오검출 가능성이 큼

 

3. 액츄에이터(Actuator) Software Safety Mechanisms

3.1 Failure Detection by On-line Monitoring

  • 개념: 액츄에이터(모터, 밸브, 솔레노이드 등)의 목표값(명령)과 실제 응답(피드백) 신호를 비교
  • 구현 사례:
    • 전동 파워 스티어링(EPS): 모터 목표 토크와 실제 전류, 속도 센서 등을 비교해 이상 여부 판단
    • 스로틀 밸브: 명령각 vs 실제 각도 센서 차이가 일정 범위 이상 발생하면 오류
  • 장점:
    • 액츄에이터의 동작 오류를 직접 검출 가능
    • 소프트웨어 관점에서 구현이 비교적 단순(명령 vs 피드백 비교)
  • 단점:
    • 피드백 센서 자체가 고장나면 해석 어려움
    • 미세한 편차(장비 특성, 온도 변화 등)를 허용하기 위해 필터·파라미터 튜닝 필수

3.2 Monitoring (Coherence Control)

  • 개념: 액츄에이터가 달성해야 할 물리적 상태와 현재 시스템 상태 간 ‘일관성’을 지속 검증
  • 구현 사례:
    • 브레이크 시스템: 하이드롤릭 압력이 올라가면 차량 감속도 또한 자연스럽게 증가해야 함.
                                불일치 시 브레이크 액츄에이터 고장 가능성
  • 장점:
    • 실제 동작 결과와 시스템 반응을 종합적으로 확인
    • 단순 명령-피드백 비교보다 더 넓은 맥락 검사 가능
  • 단점:
    • 차량 주행 상황(도로 상태, 하중 등)에 따라 액츄에이터 효과가 달라질 수 있어, ‘기준 모델’ 설정이 복잡

 

4. 제어기(ECU) Software Safety Mechanisms

4.1 Self-test by Software (One Channel, 제한된 패턴)

  • 개념: 소프트웨어가 자체적으로 알고리즘 몇 가지를 수행해, ECU 프로세서나 주변장치의 정상 동작 여부를 간단히 점검
  • 구현 사례:
    • 시스템 부팅 시(POST, Power-On Self Test): CPU 레지스터, 메모리 일부, 주변 IP(Core) 테스트
    • 주기적 루틴: 특정 계산(예: CRC, 산술 연산) 결과를 미리 알고 있는 참값과 비교
  • 장점:
    • 추가 하드웨어 없이도 기본적인 이상 여부 확인 가능
    • 부팅 시점에 자동으로 오류를 걸러낼 수 있음
  • 단점:
    • 테스트 패턴이 제한적이라, 모든 고장을 커버하기 어려움
    • 실행 시간 증가 및 시스템 응답 지연 가능성

4.2 Self-test by Cross Exchange (독립된 2개 유닛 간 상호 검증)

  • 개념: 이중화된 ECU(또는 서로 다른 코어) 간에 데이터를 교환하고 연산 결과를 비교해 이상 여부를 판단
  • 구현 사례:
    • 듀얼코어 MCU: 코어 A와 코어 B가 같은 계산을 수행한 뒤 결과를 서로 교환·검증
    • 이중 ECU 구성: 주 ECU와 백업 ECU가 상호 모니터링
  • 장점:
    • 한 유닛에서 발생한 오류를 다른 유닛이 잡아낼 수 있어 고장 검출률 향상
    • 두 유닛이 독립적으로 동작하므로, 한쪽이 실패해도 다른 쪽이 안전 모드를 유지 가능
  • 단점:
    • 하드웨어 이중화(또는 듀얼코어) 필요 → 비용 증가
    • 통신/데이터 교환 로직이 복잡

4.3 Software Diversified Redundancy (단일 하드웨어 채널에서 SW 중복)

  • 개념: 동일 하드웨어에서 기능이 다른(또는 코드 구조가 다른) 2가지 소프트웨어를 동시에 돌려 결과를 비교
  • 구현 사례:
    • Safety related SW Component: 동일 기능을 알고리즘 구현 방식을 다르게(예: 정수 연산 vs 부동소수 연산, 다른 Compiler) 하여 ‘공통 원인 오류’를 줄임
  • 장점:
    • 하드웨어 중복 없이도 SW 레벨에서 다양성(분산)을 확보
    • 공통 결함이 아니라면, 한 소프트웨어 오류를 다른 쪽이 검출
  • 단점:
    • 코드 작성 및 유지보수 비용이 크게 증가
    • 동일 요구사항을 두 번 구현하므로 개발 시간·테스트 노력 배가

4.4 Reciprocal Comparison by Software (상호 비교)

  • 개념: 소프트웨어 내 여러 모듈 또는 태스크가 동일 연산을 각각 수행하고, 결과를 서로 비교
  • 구현 사례:
    • 실시간 태스크 A, B가 같은 센서 데이터를 처리해 제어값을 계산, 결과가 불일치하면 에러
  • 장점:
    • 동일 하드웨어 채널 내에서도 프로그램 상위 레벨에서 오류 검출 가능
  • 단점:
    • 모듈 분리가 확실해야 하며(독립된 실행 경로), 각 모듈 간 상관관계가 있어야 함

4.5 Stack Over/Underflow Detection

  • 개념: 런타임 중 소프트웨어 스택 영역이 설정 범위를 벗어나서(Overflow) 다른 데이터 영역을 침범하거나, 반대로 거의 사용되지 않을(Underflow) 경우를 감지
  • 구현 사례:
    • ‘Stack Sentinel’ 삽입: 스택 상·하단에 마커(특정 패턴)를 심어두고, 주기적으로 검사해 패턴이 바뀌면 Stack Error로 판단
  • 장점:
    • 프로그래밍 에러(재귀 호출 폭주, 배열 인덱스 오류 등)로 인한 메모리 침범을 조기에 발견
  • 단점:
    • 시점에 따라 검사해야 하므로, 실시간 성능 소폭 저하
    • 마커 오염 시 false positive 발생 가능

4.6 Watchdog

  • 개념: 소프트웨어가 일정 주기로 ‘생존 신호(Heartbeat)’를 보내지 않으면 시스템이 멈췄다고 판단해 리셋(또는 안전 동작)
  • 구현 사례:
    • HW Watchdog: 일정 타이머 내에 소프트웨어에서 Clear Signal을 주지 않으면 MCU 강제 리셋
    • SW Watchdog: 소프트웨어 간 상호 모니터링(타이머 체크)
  • 장점:
    • 프로그램 무한 루프나 교착 상태(Deadlock) 등 치명적 오류에 대한 빠른 대응
    • 구현이 비교적 간단하고 효과가 큼
  • 단점:
    • 오작동 시 불필요한 리셋으로 시스템 신뢰도 저하
    • Watchdog 자체가 멈추는 경우 별도 대책 필요

4.7 Monitoring of Programme Sequence

  • 개념: 소프트웨어가 지정된 실행 순서(상태 머신, 함수 호출 시퀀스)를 준수하는지 지속적으로 검사
  • 구현 사례:
    • SW 흐름 제어: 특정 함수가 호출된 후 정해진 함수가 반드시 이어져야 하며, 그렇지 않을 경우 로직 위반으로 간주
  • 장점:
    • 복잡한 소프트웨어 구조 내 비정상 흐름을 조기에 감지
  • 단점:
    • 상태/흐름 모델링이 잘 되어 있어야 하며, 상태 폭발(복잡도 증가) 위험

 

5. 메모리(Memory) Software Safety Mechanisms

5.1 RAM Test

  • 개념: 부팅 시 혹은 주기적으로 RAM 영역 일부/전체에 테스트 패턴을 쓰고 읽어들여 결함 검출
  • 구현 사례:
    • Bootloader 단계: RAM 전역 테스트, 결함 발생 시 부팅 중단 또는 안전 모드
    • 주기적 스케줄링: 미사용 RAM 영역을 분할 테스트
  • 장점:
    • 물리적/논리적 메모리 불량을 사전에 식별 가능
  • 단점:
    • 테스트 시간, 실행 중 메모리 사용 제약 존재
    • 일부 결함(간헐적 에러)은 놓칠 수 있음

5.2 Parity Bit / Checksum / CRC

  • 개념: 메모리에 저장된 데이터를 읽고 쓸 때, 추가적인 에러 검출 코드(Parity, Checksum, CRC)를 활용해 무결성 확인
  • 구현 사례:
    • Flash 메모리에 섹터 단위로 CRC 첨부, 주기적으로 읽어서 비교
    • RAM 변수에도 Checksum을 함께 기록
  • 장점:
    • 간단한 소프트웨어 로직으로 데이터 손상 여부를 빠르게 판별
  • 단점:
    • ECC만큼의 자동 수정 기능은 제공하지 못함(주로 검출 목적)
    • 오버헤드(메모리 공간, 계산 시간) 증가

5.3 Block Replication (복제)

  • 개념: 중요한 데이터를 여러 블록에 중복 저장하여, 한 블록이 손상되면 다른 블록에서 복원
  • 구현 사례:
    • EEPROM 백업: 주기적으로 동일 데이터를 여러 영역에 복제 저장
  • 장점:
    • 신뢰성 높은 데이터 유지(특히 전원 꺼질 때도)
    • 단순 구현으로도 이중화 효과 얻을 수 있음
  • 단점:
    • 저장 공간 및 쓰기 횟수 부담(특히 EEPROM/Flash 제한)
    • 동기화 로직이 필요

5.4 Memory Monitoring using ECC (Error Correction Codes)

  • 개념: ECC를 통해 단일 비트 오류는 자동으로 수정, 다중 비트 오류는 감지
  • 구현 사례:
    • ECC 내장 RAM/Flash: 하드웨어적으로 ECC를 지원하는 MCU/메모리 사용, 소프트웨어가 주기적으로 에러 카운터를 읽고 관리
  • 장점:
    • 1비트 오류는 실시간 수정 가능(Soft Error 방어)
    • 안전성 극대화, 특히 ASIL D 수준 시스템에서 자주 쓰임
  • 단점:
    • 하드웨어 측 지원이 필요(별도 설계)
    • ECC 계산 오버헤드 (대규모 메모리일수록)

 

6. 통신(Communication) Software Safety Mechanisms

6.1 Information Redundancy (값 검사)

  • 개념: 통신 메시지에 반복 데이터, Checksum/CRC 등을 포함해 전송 도중 손상이나 변조를 검사
  • 구현 사례:
    • CAN 통신: CAN 프로토콜 자체의 CRC 외에, 상위 프로토콜이 추가로 Checksum/Sequencing 처리
    • Ethernet AVB/TSN: 패킷 헤더에 버전·타임스탬프·해시 값 등을 삽입해 무결성 검증
  • 장점:
    • 통신 라인 잡음이나 오류에 강인성 확보
    • 프로토콜 계층에서 쉽게 적용 가능
  • 단점:
    • 메시지 길이가 늘어나 대역폭 사용량 증가
    • 소프트웨어 연산(Checksum/CRC) 부담 증가

6.2 Frame Counter (순서 검사)

  • 개념: 연속적으로 송신되는 프레임에 순번(카운터)을 매겨, 누락·재전송·순서 뒤바뀜 등을 감지
  • 구현 사례:
    • ADAS 센서 데이터 전송 시 프레임 번호를 삽입, 수신 측에서 번호가 어긋나면 로스트 패킷 처리
  • 장점:
    • 데이터 유실이나 지연, 맥락 위배 등을 소프트웨어적으로 즉시 파악
    • 단순하면서도 효과적
  • 단점:
    • 순번 영역 크기(오버플로 가능성), 통신 지연 등에 대한 예외 처리 필요
    • 소프트웨어 설계·해석 로직 추가

7. 결론

위에서 살펴본 다양한 Software Safety Mechanism은 실제 차량 시스템에서는 복합적으로 적용됩니다. 예를 들어, ECU 내에서는 Watchdog + Programme Sequence Monitoring + CRC 검증 등을 모두 쓰고, 센서·액츄에이터 레벨에서는 On-line Monitoring과 Rationality Check를 동시에 수행하기도 합니다.

주요 고려사항:

  1. ASIL 요구사항: 고신뢰가 필요한 ASIL D 영역은 이중화/Redundancy나 ECC 등 고장허용도 높은 기법을 적극 적용
  2. 시스템 리소스 한계: ECU 처리 성능, 메모리 용량, 통신 대역폭 등을 고려해 적절한 기법 선택
  3. 개발 비용·시간: 소프트웨어 중복 구현(Software Diversified Redundancy) 등은 개발 부담이 크므로, 효과 대비 비용 분석 필수
  4. Test & Verification: 안전 메커니즘 자체도 철저히 검증해야 하며, 단위 테스트/통합 테스트/하드웨어-인-더-루프(HIL) 시나리오에서 기능·성능 확인

결국, 하드웨어 고장으로 인한 위험이 소프트웨어적으로도 충분히 모니터링·완화될 수 있도록 다층 방어(Defense in Depth)를 구축해야 ISO 26262가 요구하는 안전 목표를 달성할 수 있습니다.

반응형