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

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

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

 

오늘은 바로 그 놓치기 쉬운 포인트들을 정리하면서,
안전분석 관점에서 DFA(Dependant 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(Dependㄷnt Failure Analysis)의 실전 적용

🛠️ DFA란?

DFA는 시스템 내 여러 요소(component, software module, hardware unit 등) 간의 의존성으로 인해 복수 고장이 동시에 또는 서로 영향을 주며 발생할 수 있음을 분석하는 기법입니다. 

서로 독립적으로 설계된다고 가정하지만, 실제로는 인터페이스, 공유 자원, 운영 환경 등으로 인해 하나의 고장이 또 다른 요소의 고장을 유발하거나 검출을 방해할 수 있는 경우를 파악하는 것이 핵심입니다.

✅DFA 수행 절차

1. 요소 목록 및 구조 정의

대상 시스템의 구성요소(하드웨어/소프트웨어)의 구조와 인터페이스의 도출

2. 고장 모드 및 위험 식별

각 요소별로 발생 가능한 고장(Failure Mode)을 정의하고, 각각이 시스템 또는 다른 요소에 미치는 영향을 식별

3. 의존성 경로 도출

예상하지 못한 상호작용 경로(공유 메모리, 버스, CPU 리소스, API 등)를 면밀히 분석하여

고장이 어떻게 연쇄적으로 전파될 수 있는지 심층 평가

4. 재해석 단계

이미 수행된 FMEA(Failure Mode and Effects Analysis) 및 FMEDA(Failure Mode, Effects and Diagnostic Analysis) 결과와 비교하여, 새롭게 파악된 의존성 고장이 추가적으로 영향을 미칠 수 있는지 재검토

5. 대응 안전 메커니즘 설계

분석 결과, 시스템 내 특정 고장이 의존적으로 영향을 줄 수 있다면,

• 시간/공간적 분리(Temporal/Spatial Separation)
• Watchdog, 교차 검사(Cross Monitoring)
• 다양한 구현 방법(이질적 중복, heterogeneous redundancy) 등의 안전 메커니즘 도입을 검토

---

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

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

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

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가 따로 노는 게임이 아닙니다!
협업의 기술, 다음 강에서 알려드립니다!

---