Functional Safety/ISO26262

(기능안전 19강) SW Architecture Design에서 놓치기 쉬운 포인트

알파미르 2025. 7. 18. 12:18

19강. SW Architecture Design에서 놓치기 쉬운 포인트

안녕하세요, 기능안전 개발자 여러분!
소프트웨어 아키텍처 설계를 하다 보면, 뭔가 다 챙긴 것 같은데…
"어라? 이거 왜 빠졌지?" 싶은 경험, 다들 있으시죠?

 

오늘은 바로 그 놓치기 쉬운 포인트들을 정리하면서,
안전분석 관점에서 DFA(Design Failure Analysis)를 어떻게 활용할 수 있는지
실전 감각으로 풀어보겠습니다.

기능안전은 설계의 디테일에 있다!

🎯 오늘의 주제는?

소프트웨어 아키텍처 설계에서 자주 간과되는 기능안전(FS) 관점의 포인트를 짚어보고,
안전분석(SW Safety Analysis)과 연결해서 어떻게 실수를 줄이고,
"안전한 구조"를 만들 수 있는지를 실전 감각으로 배워보는 시간입니다!

🧩 SW Architecture Design? 그게 뭔데?

SW 아키텍처 설계는 말 그대로 "소프트웨어의 뼈대"를 짜는 작업이에요.
어떤 기능이 어느 모듈에서 수행되고, 데이터는 어떻게 흐르고, 오류가 나면 어디서 감지하고 복구할지 등을 정하는 전체 설계 청사진이죠.

그리고 여기서 중요한 건!

기능안전은 이 뼈대 설계에서부터 시작된다는 사실입니다.

⚠️ 이런 설계 실수, 위험합니다

기능안전 관점에서 자주 발견되는 실수 몇 가지 알려드릴게요:

  1. 오류 감지 경로 미설계
    • 오류를 감지하는 메커니즘이 없거나, 진짜 오류인지 감별이 불가능한 경우.
  2. 공통 자원(shared resource) 무방비 사용
    • Mutex 안 쓰고 전역변수 펑펑 사용? Deadlock 위험이 큽니다!
  3. 독립성 부족
    • 안전 기능과 일반 기능을 같은 모듈에 몰아넣으면? 분리설계 원칙 위반!
  4. 안전 메커니즘 누락
    • 데이터 확인용 CRC? Watchdog Timer? 누락되기 딱 좋은 구조!
  5. 예외 상황 처리 로직 없음
    • 비정상 상황을 예외로 넘기지 않고 그냥 뭉개버리는 경우.
  6. 기능 블록 간의 오류 전파 차단 설계
    • SW 아키텍처 설계에서는 한 기능 블록의 오류가 다른 기능으로 전파되지 않도록 방어벽을 마련해야 합니다.
      예를 들면, 보조기능 오류가 핵심제어 기능을 마비시키지 않도록 기능 독립성 또는 오류 격리(Separation) 설계를 추가해야 합니다.
  7. TSR을 제대로 반영했는가?
    • Technical Safety Requirements에서 Software Safety Requirements로 잘 분해했는데도…
      막상 아키텍처에는 빠져 있는 경우 많습니다.
      이럴 땐 요구사항 추적성 매트릭스(traceability matrix)를 다시 한번 확인해야 해요.

🔍 이럴 땐 Safety Analysis로 검증하자

아키텍처 설계가 완료되면 반드시 소프트웨어 안전분석을 병행해야 합니다.
어떻게?

💡 주요 소프트웨어 안전분석 기법

분석 기법 주요 목적 활용 포인트
FMEA (Failure Mode and Effects Analysis) 잠재적인 고장 모드 식별 및 영향 평가 각 기능별로 고장 발생 가능성과 영향을 사전에 검토
FTA (Fault Tree Analysis) 최상위 사고로부터 논리적 원인 분석 트리 구조로 구성 요소 간 연관된 고장 경로 파악
DFA (Dependent Failure Analysis) 공통 원인(Common Cause) 또는 연쇄 고장(Dependent Fault) 분석 冗장 시스템, 소프트웨어 다중 채널 등에서 상호 의존적 오류 검출
STA (Software Traceability Analysis) 요구사항 간 추적 가능성 분석 SSR이 설계·코드·테스트까지 제대로 이어졌는지 확인
SFA (Static Code Analysis) 코드 수준에서의 잠재 오류 탐지 MISRA-C, CERT 등 코딩 규칙 기반 정적 분석 도구 활용

✔️ 포인트: 분석 결과는 반드시 아키텍처 수정 사항으로 반영돼야 의미가 있어요!

🧠 DFA(Design Failure Analysis)의 실전 적용

🛠️ DFA란?

설계 단계에서의 잠재적 오류 원인과 결과를 분석하여,
해당 오류가 시스템 전체에 어떤 영향을 줄 수 있는지 미리 파악하는 기법입니다.
SW에도 이걸 적용하면?
👉 안전기능 누락, 오류 탐지 실패, 상태 전이 실패 등을 조기에 발견할 수 있어요!

✅ DFA 적용 프로세스 요약

  1. 분석 대상 기능 정의
    → 안전 관련 소프트웨어 기능 단위로 분할
  2. 고장 시나리오 정의
    → 입력값 누락, 연산 오류, 상태 이상 등 구체적 고장 유형
  3. 영향 평가
    → 기능 장애, 오류 전파, 시스템 영향 등 파급력 분석
  4. 대응 메커니즘 점검
    → 오류 감지 여부, 오류 완화 메커니즘 유무, 안전 상태 이행 가능성
  5. 결과 반영 및 재설계
    → 아키텍처 차원에서 오류 격리/제어/리커버리 로직 설계

🎯 팁: DFA는 FMEA와 유사하지만, 설계단 특화라는 점에서 더욱 상세한 설계 관점으로 접근합니다.

🔒 안전 메커니즘 설계 시 고려사항

안전 메커니즘은 단순히 오류를 막는 코드 그 이상입니다.
아키텍처 수준에서 고려돼야 할 필수 구성 요소죠.

🔧 주요 안전 메커니즘 설계 요소

  1. Redundancy 구조 (이중화)
    • 예: Dual-core lockstep, backup logic
  2. Monitoring
    • 예: CPU Load 감시, 메모리 오염 탐지
  3. Error Detection & Correction
    • 예: Parity check, CRC, ECC
  4. Safe State Transition 설계
    • 예: 오류 발생 시 비상 정지 혹은 안전 모드 진입

✅ 실전 체크리스트

✔️ TSR과 SSR을 바탕으로 아키텍처에 반영된 안전 기능이 있는가?
✔️ 감시 타이머/이중화/에러 감지 로직이 설계 단계에서 정의되었는가?
✔️ 고장 모드 분석 결과가 아키텍처 개선에 반영되었는가?
✔️ 안전 관련 기능이 분리된 모듈로 설계되었는가?
✔️ 전체 시스템 흐름 속에서 안전 기능이 놓치지 않고 연결되어 있는가?

✨ 마무리 한 줄 요약!

SW Architecture는 기능안전의 설계 기반입니다.
오류를 막는 설계, 분리와 감시, 그리고 검증 가능한 구조를 잊지 마세요!

🔮 다음 강 예고!

📘 20강. 하드웨어 개발과 기능안전 연계 – 협업 실전 전략

기능안전은 HW/SW가 따로 노는 게임이 아닙니다!
협업의 기술, 다음 강에서 알려드립니다!

반응형