[ISO 26262 5강(실무)] 소프트웨어 안전 아키텍처 설계

---

Title: ISO 26262 중급 강좌 5강 – 소프트웨어 안전 아키텍처 설계 실무
Description: ISO 26262 중급 강좌 5강에서는 소프트웨어 안전 아키텍처 설계를 중심으로 ASIL 요구사항을 SW 구조에 반영하는 방법과 HW-SW 경계에서의 안전 인터페이스 설계를 실무 예제와 함께 설명합니다.
Keywords: ISO 26262, 소프트웨어 안전 아키텍처, ASIL, AUTOSAR, Watchdog, MC/DC, HW-SW 인터페이스

---

🚗 ISO 26262 중급 강좌 5강

소프트웨어 안전 아키텍처 설계

소프트웨어는 더 이상 “하드웨어를 제어하는 보조 요소”가 아닙니다.
오늘날 ECU의 안전 성능은 소프트웨어 아키텍처 설계 수준에서 거의 결정됩니다.

이번 강의에서는 ASIL 요구사항을 소프트웨어 구조에 어떻게 녹여내는지,
그리고 하드웨어 고장이 소프트웨어에 미치는 영향을 어떻게 통제하는지를 실무 관점에서 살펴봅니다. 🧠

---

1. 소프트웨어 아키텍처와 ASIL 요구사항 🔐

ISO 26262에서 소프트웨어 아키텍처 설계의 핵심은
ASIL 요구사항을 구조적으로 만족시키는 것입니다.
이는 단순히 코딩 규칙을 지키는 수준이 아닙니다.

대표적인 ASIL 반영 요소는 다음과 같습니다.

• 독립성(Independence): 안전 관련 SW와 비안전 SW의 논리적 분리
• 오류 검출(Error Detection): 런타임에서 이상 상태를 감지
• 검증 가능성: MC/DC 커버리지를 고려한 구조 설계

👉 핵심 포인트: ASIL은 “테스트 단계”가 아니라

                         아키텍처 단계에서 이미 절반 이상이 결정됩니다.
                          (출처: ISO 26262-6:2018, Clause 7)

---

2. AUTOSAR 기반 소프트웨어 안전 구조 🧩

실무에서는 대부분 AUTOSAR Classic Platform을 기반으로
소프트웨어 아키텍처를 설계합니다.

안전 관점에서 중요한 포인트는 다음과 같습니다.

• Safety SWC와 Non-Safety SWC 분리
• RTE를 통한 명확한 인터페이스 정의
• OS Task 레벨에서 ASIL 분리(Scheduling, Priority)

예를 들어, 브레이크 제어 SWC(ASIL D)는
인포테인먼트 연계 SWC(QM)와 같은 Task에 배치되면 안 됩니다.

 

📌 실무 팁: AUTOSAR에서는
                    “같은 MCU = 같은 안전 수준”이 절대 아닙니다.
                     논리적 분리가 핵심입니다.

---

3. HW-SW 경계에서의 안전 설계 ⚡

소프트웨어 안전 아키텍처에서 가장 취약한 지점은
바로 하드웨어와 소프트웨어의 경계(HW-SW Interface)입니다.

 

하드웨어 고장은 다음과 같은 형태로 소프트웨어에 영향을 줍니다.

• 센서 단선 → 비정상 입력 값
• 전원 불안정 → MCU 오동작
• 메모리 오류 → 잘못된 계산 결과

이를 방지하기 위해 소프트웨어는 다음을 수행해야 합니다.

• Plausibility Check (물리적으로 가능한 값인지 확인)
• Range / Timeout Check
• 하드웨어 상태 레지스터 모니터링

👉 중요: 하드웨어 고장을 “소프트웨어 버그”로 만들지 않는 것이
               안전 아키텍처의 역할입니다.
               (출처: ISO 26262-5/6 연계 요구사항)

---

4. Safety Mechanism 설계 예 🛠️

대표적인 소프트웨어 Safety Mechanism은 다음과 같습니다.

• Watchdog Monitoring: Task 주기 감시
• Alive Counter: 통신 데이터 무결성 확인
• End-to-End Protection: AUTOSAR E2E Profile 적용

 

---

5. 실습 예제 🧑‍💻

🔧 실습 주제

AUTOSAR 기반 소프트웨어 안전 아키텍처 설계

실습 내용

1. 브레이크 제어 ECU 기능 정의
2. Safety SWC / Non-Safety SWC 분리
3. Watchdog, Plausibility Check 삽입
4. HW 오류 → SW 대응 흐름 정의

체크리스트

• ASIL 등급별 SWC 분리 여부
• Watchdog 주기 및 타임아웃 정의
• 센서 오류 시 Safe State 전이 여부
• MC/DC 커버리지 고려한 구조 설계

👉 추천 도구: DaVinci Developer, EB tresos, Enterprise Architect

---

6. OEM / Tier1 / Tier2 관점 정리 📊

• OEM: 차량 기능 관점에서 SW 안전 아키텍처 요구사항 정의
• Tier1: ECU 단위 SW 구조 설계 및 Safety Mechanism 구현
• Tier2: MCU, BSP, Safety Library 제공 및 HW 오류 정보 명세

👉 정리하면,
       OEM은 “무엇이 안전해야 하는지”를 정의하고,
       Tier1은 “어떻게 구현할지”를 설계하며,
       Tier2는 “기반 기술의 신뢰성”을 보장합니다.

---

핵심 정리 📝

• 소프트웨어 안전은 아키텍처 단계에서 결정된다.
• ASIL 요구사항은 SWC 분리, 독립성, 오류 검출 구조로 반영해야 한다.
• HW-SW 인터페이스는 가장 중요한 안전 취약 지점이다.
• Watchdog, Plausibility Check는 필수 Safety Mechanism이다.
• OEM / Tier1 / Tier2 간 역할 분담이 명확할수록 안전 품질이 높아진다.

---

👉 다음 강의 예고: 하드웨어 / 소프트웨어 인터페이스 설계 및 검증