▼ SDV시대의 기능 안전 1편 바로가기
SDV 시대의 기능 안전: ① 시스템 설계의 본질과 3가지 오해
[Summary]단품 요소 기술을 넘어선 통합 시스템 기반 기술과 분석 프레임워크를 소개합니다.자체 시스템 요구사항 개발, 시스템 아키텍처 설계, 시스템 분석으로 이어지는 시스템 설계의 핵심 3요
www.hlworld.com
[SUMMARY]
- SDV 시대 기능 안전의 본질인 '정보의 일관성'을 현장 엔지니어링 기술로 구현하기 위한 통합 시스템 분석 프레임워크를 소개합니다.
- 정적인 전통적 문서(HOQ, BOM) 대신 ALM 및 UML 기반의 현대적인 모델을 입력물로 활용하며, 글로벌 표준인 시스템 FMEA의 7단계 절차를 기준점으로 삼아 FTA와 DFA를 유기적으로 연계합니다.
- 단순한 교과서적 이론을 넘어 FMEA 작성 시의 함정, FTA의 논리 게이트 적용법, DFA를 통한 연쇄 고장 차단 등 실무 엔지니어와 심사 대응을 위한 생생한 현장 노하우를 제시합니다.
- 3대 분석 기법을 PDCA 사이클 기반의 단일 파이프라인으로 통합해 설계 초기 오류가 눈덩이처럼 불어나는 '스노우볼 효과'를 방지하고, 더 나아가 신뢰성 검증(DRBFM) 및 사이버 보안(TARA) 영역까지 아우르는 청사진을 제시합니다.
Author's Note
안녕하세요, HL만도에서 제동 제품의 플랫폼(Platform) 단위 시스템 아키텍처(System Architecture, 시스템 구조) 및 안전 분석 (Safety Analysis) 영역을 담당하고 있는 장훈도 책임연구원입니다.
지난 1편에서는 시스템 엔지니어로서의 고뇌와 설계 철학, 그리고 브이 사이클(V-Cycle)과 연계 추적성(Traceability)을 둘러싼 현업의 3가지 오해를 짚어보았습니다. 단순히 문서를 기계적으로 연결하는 링크를 넘어, 시스템 요구사항과 아키텍처, 안전 분석이 모순 없이 맞물리는 ‘정보의 일관성(Consistency)’이야말로 소프트웨어 중심 자동차(SDV, Software Defined Vehicle)안전의 본질이라는 점을 말씀드렸는데요,
이번 2편에서는 이러한 설계 철학을 현업에서 엔지니어링 기술로 구현하기 위해 어떤 현대적 도구들이 활용되며, 고장 모드 및 영향 분석(FMEA, Failure Mode and Effects Analysis), 결함 트리 분석(FTA, Fault Tree Analysis), 종속 고장 분석(DFA, Dependent Failures Analysis)이라는 대표적인 3대 안전 분석 기법이 HL만도의 ‘통합 시스템 분석 프레임워크(Framework, 분석 체계)’안에서 어떻게 톱니바퀴처럼 맞물리는지 그 실전 매핑 구조를 공유해 드리고자 합니다.
기능 안전 분석은 결코 연구실 책상 위의 이론에 머무르지 않습니다. 까다로운 글로벌 완성차(OEM) 고객과 공인 심사원 앞에서 “우리 시스템이 왜 안전한가”를 한 치의 빈틈없이 입증해 내야 하는 치열한 실전입니다. 교과서적인 설명을 넘어, 실제 개발과 심사 현장에서 엔지니어의 무기가 되어줄 생생한 노하우까지 함께 나눕니다.
1. 시스템 분석 입력물의 진화 : 종이 문서에서 살아 숨 쉬는 모델로
모든 분석 도구는 분석할 명확한 대상(System Architecture)이 있어야만 작동합니다. 과거 전통적인 FMEA 표준 가이드라인에서는 분석에 필요한 입력물로 품질의 집(HOQ, House of Quality)이나 자재명세서(BOM, Bills of Material) 같은 문서를 필수 요소로 꼽아왔습니다.
💡 Editor’s Tip 과거의 도구 vs 현대의 모델 기반 도구
- 품질의 집(HOQ, House of Quality): 고객 요구사항 (VOC, Voice of Customer)을 엔지니어링 규격으로 바꾸는 고전적 매트릭스 도구
- 자재명세서(BOM, Bills of Material): 제품 조립에 들어가는 모든 부품 및 원자재 목록표
- 통신과 제어 로직이 복잡하게 얽힌 현대의 SDV 환경에서는 정적인 스프레드시트 문서만으로 수시로 바뀌는 인터페이스를 실시간 추적하기 어렵습니다.
오늘날 전동화 및 SDV 개발 환경에서는 요구사항 관리와 추적을 총괄하는 ALM(Application Lifecycle Management System, 애플리케이션 수명주기 관리 시스템)을 기본 플랫폼으로 활용합니다. 시스템 설계 역시 표준 모델링 언어인 UML(Unified Modeling Language, 통합 모델링 언어) 기반 도구로 진행되므로, 분석 입력물 또한 현대 엔지니어링 환경에 맞게 진화했습니다.
- 품질의 집(HOQ)의 진화 → UML인터페이스 명세와 ALM 양방향 추적성
:과거 HOQ가 담당했던 부품 간 기능 정의 및 상호 인터페이스(Interface) 관계는 UML로 작성된 시스템 아키텍처의 인터페이스 명세와 ALM 도구가 지원하는 요구사항-설계 간 양방향 추적성(Traceability)을 통해 실시간으로 정합성을 검증합니다. - 자재명세서(BOM)의 진화 → 모델링 언어 기반 엔지니어링 아키텍처
: 단순 조립 순서를 나열한 생산 자재명세서(Manufacturing BOM)가 아닌, 시스템 요소(System Element)들의 계층 구조와 기능적 결합을 보여주는 설계 BOM(Engineering BOM)이 필요하며, 시스템 모델링 언어가 이를 완벽히 대체합니다.
여기에 1차 공급사(Tier 1) 입장에서 반도체와 전자 소자(E/E HW) 카탈로그(Catalogue, 표준 규격품) 부품의 규격서(Datasheet, 데이터시트)와 안전 매뉴얼(Safety Manual)에 명시된 기능 한계는 반드시 지켜야 하는 설계 제약 조건(Design Constraints)입니다. 결국 현대 시스템 분석의 필수 입력물은 추적성이 확보된 시스템 요구사항(System Requirements)과 현실적인 구현 타당성(Implementation Feasibility)을 갖춘 시스템 아키텍처 설계로 정의할 수 있습니다.
📖 [알아두면 쓸모 있는 배경지식 #1] 품질의 정의와 시스템 분석
국제표준화기구 품질경영시스템(ISO 9000:2015)에서는 품질을 ‘명시된 요구사항이나 내재된 요구사항을 충족하는 정도(Degree to which a set of inherent characteristics fulfills requirements)’로 정의합니다. 여기서 주목할 점은 단순히 문서에 적힌 요구사항(Requirements) 뿐만 아니라 제품이 본질적으로 지녀야 할 고유 특성(Inherent Characteristics)까지 포함한다는 점입니다. 회의나 메일로 온간 암묵적 요구까지 기술적으로 체계화한 것이 바로 시스템 분석의 입력 산출물입니다.
2. 왜 ‘시스템 FMEA(System FMEA)’가 전체 분석의 출발점인가?
시스템 분석 도구는 크게 상향식(Bottom-up, 귀납적)과 하향식 (Top-down, 연역적)으로 나뉘며, FMEA, FTA, 고장 모드 ∙ 영향 및 진단 분석(FMEDA, Failure Modes, Effects, and Diagnostic Analysis), DFA 등 다양합니다. 도구의 종류가 무엇이든 분석 결과물 간의 일관성(Consistency)을 확보하려면 흔들리지 않는 단 하나의 ‘시작점’이 필요한데, HL만도는 그 시작점을 ‘시스템 FMEA(System FMEA)’로 설정했습니다. 이유는 두 가지입니다.
1. 명확한 글로벌 표준 절차(Procedure)의 존재 : 결함 트리 분석(FTA)이나 종속 고장 분석(DFA)에 비해, FMEA는 글로벌 표준(AIAG-VDA FMEA Handbook 1ST Ed., 2019)에 기반한 확고한 7단계 절차(7-Step)가 정립되어 있습니다.
2. 비정형 언어(Informal Language) 기반의 유연성 : 시스템(System), 소프트웨어(SW), 하드웨어(HW) 전 영역을 아우르는 전체적 관점(Wholistic View)에서 고장을 폭넓게 정의하기에 가장 유리합니다.
이에 따라 HL만도는 AIAG-VDA FMEA[1] 7단계 절차에 맞춰 결함 트리 분석(FTA)과 종속 고장 분석 (DFA)의 단계를 1:1로 정렬하고 상호 연계하는 통합 엔지니어링 프로세스를 확립했습니다.
| Step | FMEA(Incl.MSR) [1][2] | FTA[2][3] | DFA[2] |
| 1 | 기획 및 준비 (Planning & Preparation) |
기획 및 준비 (Planning & Preparation) |
기획 및 준비 (Planning & Preparation) |
| 2 | 구조 분석 (Structure Analysis) |
결함 트리 정성적 전개 (Fault Tree Deployment) |
결합 요인 식별 (Coupling Factor Identification) |
| 3 | 기능 분석 (Function Analysis) |
정성적 해석 (Qualitative Interpretation) |
종속 고장 식별 및 분석 (Identify & Analyze) |
| 4 | 고장 분석 (Failure Analysis) |
기본 사상 발생 확률 할당 (Occurrence Probability) |
연쇄 고장 경로 분석 (Cascading Failure Path) |
| 5 | 위험 분석 (Risk Analysis) |
정량적 해석 (Quantitative Interpretation) |
안전 메커니즘 도출 및 검증 (Safety Mechanism) |
| 6 | 최적화 (Optimization) |
개선 조치 유효성 모니터링 (Action Monitoring) |
개선 조치 유효성 모니터링 (Action Monitoring) |
| 7 | 결과 문서화 (Results Documentation) |
결과 문서화 (Results Documentation) |
결과 문서화 (Results Documentation) |
(참고 표준: [1] AIAG-VDA FMEA Handbook 2019, [2] 도로 차량 기능 안전 국제 표준 ISO 26262:2018, [3] 결함 트리 분석 국제 표준 IEC 61025:2006 / IEC TR 62380)
(※ MSR: 시스템 반응 모니터링, Monitoring and System Response)
그렇다면 이렇게 정립된 7단계 프레임워크를 바탕으로, 실제 엔지니어는 현장에서 이 도구들을 어떻게 요리해야 할까요?
[1] AIAG-VDA FMEA (2019): 미국 자동차산업협회(AIAG)와 독일 자동차산업협회(VDA)가 각기 운영하던 규격을 통합하여 제정한 7단계 글로벌 표준 FMEA 핸드북.
3. 교과서를 넘어선 실전 엔지니어링 : 도구별 핵심 노하우 & 심사 대응 팁
이제 표준 문서나 교과서에 나오는 원론적인 이야기는 잠시 내려놓겠습니다. 지금부터 나눌 이야기는 딱딱한 분위기 속에서 살얼음판을 걷듯 분석 결과를 검증받던 엔지니어가, 글로벌 고객사나 심사원과 마주 앉아 편안하게 웃으며 설계 개선을 논의할 수 있게 만들어주는 현장 실전 팁입니다.
① 고장 모드 및 영향 분석(FMEA, Failure Mode and Effects Analysis)
[System FMEA : 7-Step 분석 흐름과 핵심 실무 체크포인트]
Step.1 : 기획/준비 (과거 교훈 반영) → Step.2 : 구조 분석 (설계 BOM 준수) → Step.3 : 기능 분석 (인터페이스 정의) → Step.4 : 고장 분석 (최소 3단계 인과) → Step.5 : 위험 분석 (Yellow 투명 관리) → Step.6 : 최적화 (FMEA-MSR 연계) → Step.7 : 결과 문서화 (추적성 확정)
과거 북미 중심의 스프레드시트 방식(AIAG)[2]과 유럽 완성차 중심의 구조화 방식(VDA)[3]이 나뉘어 발전하다가, 오늘날에는 두 표준이 하나로 합쳐진 AIAG-VDA FMEA 통합 핸드북(2019)이 글로벌 표준으로 자리 잡았습니다. 이 7단계(7-Step) 절차를 밟아갈 때 엔지니어가 자주 빠지는 함정과 돌파구는 다음과 같습니다.
- Step 2 구조 분석 : “기능 연결의 유혹을 뿌리치고, 설계 BOM을 지키세요”
부품 공급사 입장에서 부품 단독으로 차량 전체에 미치는 고장 영향을 완벽히 알기는 어렵습니다. 그래서 고객사가 전달해 준 안전 목표(Safety Goal)를 보거나, 가정이 포함된 위험원 분석(HARA, Hazard Analysis and Risk Assessment)의 오작동 항목을 놓고 고객사와 머리를 맞대고 “차량 레벨의 영향”부터 명확히 합의해야 합니다.
그다음 구조망을 짤 때 많은 엔지니어가 치명적인 함정에 빠집니다. 바로 부품 구조 대신 기능끼리만 엮으려는 유혹입니다. 기능의 흐름만 보고 구조를 짜면 어떻게 될까요? 나중에 설계를 최적화할 때 기능의 상하 관계가 뒤집히거나 제조 공정 FMEA로 넘겨주어야 할 핵심 부품 정보가 쏙 빠져버리기 십상입니다. 단순히 조립 순서를 나열한 생산 BOM이 아니라, 부품 간의 물리적 뼈대를 보여주는 ‘설계 BOM(Engineering BOM)’을 끝까지 기준점으로 붙잡고 가야 하는 이유가 바로 여기에 있습니다. - Step 3 기능 분석 : “인터페이스 기능 정의, 귀찮아도 생략하면 안 되는 이유”
부품 자체의 기능만 적을 것인가, 부품 사이를 이어주는 인터페이스(Interface)의 기능까지 일일이 다 적을 것인가? 현업에서 가장 고민되는 지점입니다. 인터페이스의 개수는 부품 수보다 훨씬 많기 때문에 상당한 업무 부하가 걸리기 때문인데요, 하지만 그럼에도 불구하고 인터페이스 기능은 반드시 정의해야 합니다. 이를 생략하면 실제 필드나 시험에서 문제가 터졌을 때 원인을 찾는 시간이 부품 간 조합(Combination)의 수만큼이나 기하급수적으로 폭증합니다.
혹시 실무에서 큰 고생 없이 원인을 금방 찾았던 경험이 있으신가요? 그렇다면 내 옆에 경험 많은 선배 엔지니어가 있었음에 감사하거나, 그날 운이 아주 좋았음을 인정해야 합니다. - Step 4 고장 분석 : “고장망이 끝없이 이어져야 한다는 강박을 버리세요”
고장 모드를 정의할 때는 표준 가이드워드(HAZOP)[4]를 기본으로 쓰되, 현장이나 고객사가 관례적으로 부르는 고유 용어가 있다면 그 용어를 살려주는 것이 소통에 훨씬 유리합니다.
또한, 많은 분들이 최상위부터 최하위까지 수십 개의 고장이 꼬리에 꼬리를 물고 끝없이 이어져야 완벽하다고 생각하기 쉽습니다. 하지만 고장망(Failure Net)의 본질은 ‘영향(Effect) – 고장 모드(Failure Mode) – 원인(Cause)’으로 이어지는 명확한 최소 3단계 인과관계를 세우는 데 있습니다.
만약 설계 BOM에는 서로 떨어져 있어 직접 연관이 없는데 한쪽의 결함이 다른 쪽에 영향을 준다면(열기나 전자기 노이즈 등), 눈에 보이지 않는 간섭(Interference) 인터페이스가 존재하는 것이므로 이때는 상위 요소에 해당 기능과 고장을 추가해 분석해야 합니다. - Step 5 & 6 위험 분석과 최적화 : “모든 칸을 초록색으로 칠하려는 유혹을 버리세요”
위험 매트릭스 (Risk Matrix)를 채우다 보면, 모든 분석 항목을 안전 영역인 초록색(Green, 안전)’으로 칠해 완벽한 보고서로 포장하고 싶은 강한 유혹에 빠지기 쉽습니다. 하지만 결함 확률이 0%인 완벽한 제품은 현실에 존재하기 어렵습니다.
그렇다면 어떤 항목을 ‘Yellow(주의/관리)’로 남겨두어야 할까요? 바로 차량 외부 환경이나 타 시스템 인터페이스처럼 고객사와의 협업 및 설계 가정이 지속적으로 검증되어야 하는 항목들입니다. 이런 부분들은 현실적인 ‘Yellow(주의/관리)’ 영역으로 투명하게 남겨두고, 잔류 위험을 끝까지 추적 관리하는 것이 오히려 글로벌 심사원과 고객사 모두에게 깊은 신뢰를 얻을 수 있는 비결입니다. - 실전 응용(FMEA-MSR[5]) : 모니터링과 안전 반응의 가치
안전 메커니즘(Safety Mechanism)이 위험을 ‘언제, 얼마나 줄여주는가’를 숫자로 보고 싶다면 FMEA-MSR 적용을 적극 권장합니다. 센서 결함을 스스로 감지(Monitoring)하고 안전 상태(Safe State)로 전환(Reaction)하는 과정을 분석하는 것 자체가 다중점 고장 분석(Multiple Point Failure Analysis)의 기초가 되며, 뒤이어 다룰 결함 트리 분석(FTA) 및 종속 고장 분석(DFA)로 넘어가는 튼튼한 징검다리가 되어줍니다.
[2] AIAG: 미국 자동차 산업 협회 (Automotive Industry Action Group)
[3] VDA: 독일 자동차 산업 협회 (Verband der Automobilindustrie)
[4] 위험성 및 운전성 검토, Hazard and Operability Study
[5] Monitoring and System Response : AIAG-VDA 통합 FMEA에 신설된 보충 표준으로, 제품의 설계 단계(DFMEA)를 넘어 운전 중(In-Service) 실시간 결함 감지 및 모니터링 능력, 그리고 고장 시 안전 상태(Safe State)로 전환하는 시스템 응답 메커니즘을 평가하는 기법입니다.
📖 [알아두면 쓸모 있는 배경지식 #2] FMEA는 정말 상향식(귀납적)도구인가?
과거 AIAG의 HOQ나 VDA의 기능 정의는 모두 목표 달성을 저해하는 고장을 분석하기 위해 ‘기능과 기능의 조합’을 먼저 알아야 한다는 상식적인 명제에서 출발했습니다. 즉, 고장을 분석하는 절차(Step 4~5)만 본다면 상향식 귀납(Bottom-up) 접근이 맞지만, 구조와 기능을 먼저 정의하는 사전 활동(Step 2~3)은 철저히 하향식 연역(Top-down) 접근입니다. 따라서 FMEA는 두 가지 접근법이 유기적으로 공존하는 고도의 분석 체계입니다.
② 결함 트리 분석 (FTA, Fault Tree Analysis)
HL만도의 FTA 역시 결함 원인을 1차(Primary), 2차(Secondary), 명령(Command) 결함으로 분류하는 전통적인 P-S-C [6]컨셉을 사용합니다. 다만, 일반적인 절차와 달리 정량적 해석을 추가한 이유는, 전자제어장치(ECU) 하드웨어 결함 트리 및 FMEDA와의 일관성을 확보하고 시스템 컨셉과 실제 회로∙소프트웨어 안전 메커니즘 간의 관계를 확인하기 위함입니다.
- 게이트(Gate) 및 이벤트 타입(Event Type)의 엄격한 사용: 소프트웨어 로직(SW Logic)과 기계 하드웨어를 함께 다루는 시스템 FTA(System FTA)에서는 최하단에서 추가 전개 없이 끝나는 경우가 발생합니다. 이때는 미전개 사상(Undeveloped Event)[7] 기호를 정확히 사용해야 합니다. 또한 소프트웨어 로직의 신호 진입 조건이나 고장 처리 우선순위를 표현할 때 단순 논리합/논리곱(AND/OR Gate)만 사용할 경우 고장 확률 계산에서 심각한 오류가 발생하므로, 우선순위 AND(Priority AND Gate), 배타적 OR(Exclusive OR Gate)게이트 등을 적절히 사용해야 합니다.
- ECU 하드웨어 FTA와의 분리 작성: 하드웨어 설계는 기능 최적화가 필수적이므로, System FTA를 그대로 전달받아 수행하기보다는 하드웨어 DFMEA[8]를 기준으로 작성된 FMEDA를 바탕으로 별도 작성한 뒤 상호 모델링의 적합성을 검토하는 것이 효과적입니다.
- 민감도 분석(Sensitivity Analysis): HL만도 FTA에서는 안전 메커니즘(Safety Mechanism) 추가 유무에 따른 민감도 분석을 거쳐, 해당 설계 대안의 실질적인 위험 저감 효과를 객관적으로 입증합니다.
③ 종속 고장 분석 (DFA, Dependent Failures Analysis)[9]
DFA는 주로 소프트웨어 안전 분석에 초점이 맞춰져 있으며, ISO 26262에서도 시스템 영역의 필수 예제로 제시되지는 않습니다. 그러나 FMEA와 FTA만으로 동적 특성과 시간 지연에 따른 연쇄 영향을 분석하려면 지나치게 많은 공수가 소요됩니다. 이에 HL만도에서는 동적 아키텍처(Dynamic Architecture)를 기준으로 종속 고장 유발 요인(Dependent Failure Initiator)을 정의하고, 시스템 아키텍처를 최적화하는 과정에서 기능 및 고장의 영향 간 상충되는 부분이 없는지 최종 검토하는 데 DFA를 활용합니다. 이는 안전 분석 보고서(Safety Analysis Report) 작성 시 FMEA와 FTA를 상호 보완하여 안전 메커니즘 목록을 정밀하게 정리하는 핵심 수단이 됩니다.
PDCA 사이클 기반의 엔지니어링 규율과 '스노우볼 효과(Snow-ball Effect)' 방지
도구마다 관점은 다르지만, 분석이라는 활동 자체는 동일한 문제 해결 사이클을 필요로 합니다. HL만도는 이 도구들을 개별 운영하지 않고, 품질 혁신의 기본인 ‘계획-실행-평가-개선(PDCA, Plan-Do-Check-Act)사이클을 단일 파이프라인으로 확장하여 운영하고 있습니다.
[6] 1차-2차-명령 컨셉 (P-S-C Concept, Primary-Secondary-Command): 결함의 원인을 부품 자체의 본질적 결함(Primary), 외부 스트레스 및 환경에 의한 결함(Secondary), 오작동 신호나 잘못된 제어 명령에 의한 결함(Command)으로 분류하여 전개하는 결함 트리 분석(FTA) 기법
[7] 미전개 사상 (Undeveloped Event): 결함 트리 분석(FTA)에서 추가 정보가 부족하거나 더 이상 하위 원인으로 전개할 필요가 없는 결함 항목을 나타내는 마름모꼴 기호.
[8] DRBFM (Design Review Based on Failure Mode): 기존 검증된 양산 설계 대비 '변경점(Change Point)'에 집중하여 잠재 위험을 도출하고 검증하는 예방 품질 방법론.
[9] DFA (Dependent Failures Analysis, 종속 고장 분석): 공통 원인이나 연쇄 반응으로 인해 서로 독립적으로 작동해야 할 복수의 안전 메커니즘이 동시에 무력화되지 않는지(설계 독립성)를 검증하는 기법.
💡 HL만도 프레임워크의 차별점: 계획(Plan)의 고도화와 Snow-ball Effect 방지
프로젝트 및 품질 관리에서 가장 경계하는 현상은 초기 오류의 여파가 눈덩이처럼 불어나는 ‘스노우볼 효과(Snow-ball Effect, 눈덩이 효과)’입니다.
HL만도 시스템 분석 프레임워크가 차별화되는 점은 계획(Plan)을 더욱 상세하고 완결성 있게 수립한다는 데 있습니다. 단순히 분석 범위를 명확히 하는 것에 그치지 않고, 분석 대상에 대한 '과거 고장 발생 이력(Lessons Learned)'과 '현재의 설계 구조 평가'를 초기 단계에서 함께 수행합니다. 이렇듯 첫 단추부터 철저한 검증을 거침으로써 후반부 설계 변경으로 인한 손실을 원천 차단합니다.
신뢰성과 사이버 보안으로의 확장 (Supporting Tools)
HL만도 프레임워크는 기능 안전 3대 도구 외에도 다양한 엔지니어링 방법론을 유기적으로 결합하여 분석의 완성도를 높입니다.
- Fishbone Diagram & Parameter Diagram(P-Diagram):
피시본 다이어그램을 통해 완결성이 부족한 분석 내용을 신속하게 식별하며, 파라미터 다이어그램을 활용해 시스템 내·외부의 노이즈 팩터(Noise Factor, 외란 인자)를 체계적으로 분류함으로써 신뢰성 검증(Design Validation) 시험 항목의 객관적 근거로 활용합니다. - 고장 모드 기반 설계 검토(DRBFM, Design Review Based on Failure Mode):
설계 변경점에 집중하여 잠재 고장을 예방하는 분석법입니다. DRBFM은 정해진 양식에 매몰되기보다, 진리표(Truth Table) 기반의 '가상 시뮬레이션(What-if Simulation)'을 접목할 때 가장 높은 효과를 발휘합니다.
(※ DRBFM의 실전 분석 노하우는 향후 임재현 연구원의 기고를 통해 상세히 소개해 드릴 예정입니다.) - 위협 분석 및 위험 평가(TARA[10], Threat Analysis and Risk Assessment):
고장을 다루는 기능 안전과 달리, 차량 사이버 보안 국제 표준(ISO/SAE 21434)은 외부 공격에 대한 시스템 보안을 요구합니다. 따라서 TARA를 통한 공격 경로 분석(Attack Path Analysis)이 수반되어야 합니다. 고장 기반 분석과 사이버 공격 기반 분석은 접근 관점은 다르지만 정보의 흐름과 일관성을 공유해야 하므로, 상호 연계성을 확보하는 것이 중요합니다.
[10] TARA (Threat Analysis and Risk Assessment): 자동차 사이버 보안 엔지니어링 국제 표준(ISO/SAE 21434)에 따라 차량 시스템의 잠재적 사이버 공격 위협을 식별하고 공격 경로와 위험도를 평가하는 보안 기법.
마무리하며
지금까지 2편에 걸쳐 HL만도의 시스템 아키텍처 설계 철학과, AIAG-VDA 7단계를 관통하는 통합 시스템 분석 프레임워크를 살펴보았습니다.
단품 요소 기술을 개발하는 것만큼이나, 복잡하게 얽힌 시스템 내부의 보이지 않는 결함을 사전에 규명하고 안전의 일관성을 증명해 내는 '기반 시스템 분석 체계’는 미래 모빌리티의 성패를 가르는 보이지 않는 심장이라고 생각합니다. 자율주행과 SDV 시대로 나아갈수록 시스템의 복잡도는 상상을 초월할 정도로 높아질 것입니다. HL만도는 모델 기반 시스템 엔지니어링(MBSE, Model-Based Systems Engineering)과 정교한 안전 분석 프레임워크를 끊임없이 고도화하여, 도로 위 그 어떤 순간에도 운전자와 보행자의 안전을 타협 없이 지켜내는 무결점 섀시 솔루션을 지속적으로 완성해 나가겠습니다.
