DRBFM과 진리표로 추적한 Carry-over의 사각지대 - 10,362개 조건 분석과 실차 검증
▼ SDV 시대의 기능 안전 이전편 바로가기
SDV 시대의 기능 안전: ① 시스템 설계의 본질과 3가지 오해
[Summary]단품 요소 기술을 넘어선 통합 시스템 기반 기술과 분석 프레임워크를 소개합니다.자체 시스템 요구사항 개발, 시스템 아키텍처 설계, 시스템 분석으로 이어지는 시스템 설계의 핵심 3요
www.hlworld.com
SDV 시대의 기능 안전 ② FMEA∙FTA∙DFA가 하나로 맞물리는 통합 분석 프레임워크
▼ SDV시대의 기능 안전 1편 바로가기 SDV 시대의 기능 안전: ① 시스템 설계의 본질과 3가지 오해[Summary]단품 요소 기술을 넘어선 통합 시스템 기반 기술과 분석 프레임워크를 소개합니다.자체 시
www.hlworld.com
SUMMARY
- 차세대 제동 플랫폼 선행 개발 과정에서 기존 양산 부품과 로직을 그대로 재사용(Carry-over)했을 때 발생할 수 있는 시스템 사각지대와 그 해결 과정을 다룹니다.
- 소프트웨어 코드를 변경하지 않았더라도 유압 경로 등 주변 물리적 환경이 달라지면 고장 검출 전제 조건이 무너져 예상치 못한 결함이 발생할 수 있음을 실차 사례로 설명합니다.
- 설계 변경점을 넘어 시스템 전체로 시야를 넓히는 DRBFM 기법과, 10,362건의 변수 조합을 구조화한 진리표(Truth Table) 기반 분석을 도입하여 숨겨진 취약 조건을 정밀하게 규명해 냈습니다.
- 도출된 가혹 조건을 바탕으로 실차 고장 주입 시험을 진행해 최종 대안을 검증했으며, 물리적 설계의 재사용이 과거 안전성 검증의 유효성까지 보장하지 않으므로 새 환경에 맞춘 철저한 재검증이 필수적임을 강조합니다.
Author's Note
앞선 「SDV 시대의 기능 안전」 1, 2편이 기능안전의 이론과 아키텍처 프레임워크를 다뤘다면, 이번 3편은 차세대 제동 플랫폼 선행 개발 현장에서 연구팀이 맞닥뜨렸던 실제 과제를 가감 없이 복기하는 기술 추적기입니다.
설계 회의실에서는 모두를 안도하게 만드는 익숙한 한마디가 있습니다.
“이 센서와 진단 로직은 이전 양산품 그대로(Carry-over) 재사용합니다.”
수년간 필드에서 신뢰성을 입증한 부품과 코드였기에 누구도 의심하지 않았습니다. 하지만 그 완벽하다고 믿었던 설계에서, 예상치 못한 사각지대가 불거졌다면 어떨까요?
실제로 선행 개발 프로토타입을 주행 시험장 트랙에 올렸을 때, 센서 결함 상황에서도 기존 로직이 제때 반응하지 않는 예외 조건이 발견되었습니다. 개별 부품은 모두 사양대로 ‘정상’ 작동했지만, 이들이 하나로 결합된 시스템에서는 ‘오류’를 잡아내지 못한 채 침묵한 것입니다.
‘손대지 않은 설계’가 어떻게 시스템 전체의 빈틈으로 돌아왔는지, 그리고 이를 DRBFM과 진리표(Truth Table)기반 What-if 분석을 통해 어떻게 추적하고 실차 시험으로 해결했는지 현장의 치열했던 과정을 기록합니다.
1. 회의실의 안도감, 그리고 주행 시험장의 침묵
차세대 제동 플렛폼을 선행 개발할 때, 기존 양산 환경에서 수백만 km 주행을 거치며 검증된 설계를 계승하는 것은 개발 효율과 안전성을 동시에 확보하는 가장 합리적인 선택으로 통합니다.
이번 프로젝트에서도 출발은 매끄러웠습니다. 압력 센서 하드웨어는 이전 세대 부품을 그대로 채택했고, 센서 신호를 받아 고착(Stuck)결함을 가려내는 소프트웨어 진단 로직 역시 한 줄도 수정하지 않고 그대로 이식했으니까요. 이전 플랫폼의 유압 환경에서는 설계 사양성에 정의된 기준대로 고착 고장을 정확하게 잡아내던 검증된 설계였기에, 설계 검토 단계에서 의심의 여지는 전혀 없었습니다.
하지만 우리가 간과한 것이 하나 있었습니다. 코드는 그대로였지만, 그 코드가 작동하는 물리적 환경이 완전히 바뀌어 있었다는 점입니다.
신규 플랫폼으로 진화하며 제동 응답성과 성능을 끌어올리고자 유압 유로와 관련 밸브의 개폐 제어 시퀀스를 새롭게 튜닝했고, 이로 인해 이전과 전혀 다른 물리적 조건이 형성되었습니다.
기존의 고착 검출 로직은 단순히 센서에서 나오는 전기적 전압 신호만 들여다보지 않았습니다. 운전자가 브레이크 페달을 밟는 순간, 유압 라인을 타고 밀려 들어오는 ‘특정 압력 형성 패턴’을 정상 판단의 전제 조건으로 깔고 있었던 것이죠.
문제는 바로 여기서 불거졌습니다. 바뀐 유압 경로와 새로운 밸브 제어 조건 아래에서는, 특정 조건에서 고장 검출에 활용되는 압력 정보가 기존과 같은 방식으로 충분히 형성되지 않는 상황이 발생했습니다. 센서 쪽으로 압력이 도달하지 않는 물리적 사각지대가 생긴 것입니다.
이 경우 센서에 고착(Stuck) 고장이 존재하더라도 고장 검출에 필요한 압력 조건이 충족되지 않아, 기존 로직만으로는 해당 고장을 판별하지 못하는 상황이 벌어집니다. 실제 시험에서도 특정 밸브 상태에서 회로 압력이 형성되지 않아 검출 조건 자체가 성립하지 않는 Case가 확인되었습니다. 센서에 물리적 압력 자체가 도달하지 않으니, 센서가 특정 값에 멈춰버리는 하드웨어 결함이 생겨도 소프트웨어는 이를 단순한 ‘운전자가 페달을 덜 밟아 압력이 아직 안 찬 상태’로 오인해 버린 것입니다.
우리가 던져야 했던 질문의 본질은 “로직 코드를 건드렸는가”가 아니었습니다.
“그 로직이 숨 쉬기 위해 필요했던 물리적 전제 조건이, 새 시스템에서도 여전히 유지되고 있는가?”를 되물어야 했던 순간이었습니다.
2. 검토 대상은 바뀐 부분만이 아니었다
설계 변경 검토(Design Review) 회의에 들어가면 보통 CAD 도면의 수정 기호나 소프트웨어 코드의 변경 내역(diff)에만 온 신경이 쏠립니다. 하지만 시스템 엔지니어링 관점으로 시야를 넓혀보면, 전혀 손대지 않았던 기존 설계야말로 가장 치명적인 사각지대가 되곤 합니다.
엔지니어링 현장에서는 다음 두 문장을 엄격하게 구분해야 합니다.
“이 설계는 변경되지 않았다” (도면과 코드의 불변을 뜻하는 단순 사실 Fact)
“이 설계는 변경의 영향을 받지 않는다” (검증되지 않은 위험한 가정)
동일한 센서와 소프트웨어를 재사용했다는 물리적 사실만으로, 과거의 안전성 검증 결과까지 유효할 것이라 믿는 것은 위험한 판단입니다. 이전 양산에서 확보한 신뢰성 데이터는 어디까지나 ‘과거 시스템이 제공하던 유압 및 물리적 경계 조건’ 안에서만 유효하기 때문이죠. 주변 기구와 제어 시퀀스가 바뀌었다면, 재사용한 코드가 전제하고 있던 시스템 실행 환경 자체가 완전히 달라진 것과 같습니다.
3. 부품 단위의 ‘정상’이 모여 시스템의 ‘사각지대’가 되다
이번 이슈는 소프트웨어, 전자 하드웨어, 기계 유압이 복합적으로 맞물리는 ‘메카트로닉스 시스템의 경계면’에서 발생했습니다. 부품 단위로 쪼개어 보면, 어떤 결함이나 사양 위배도 없었습니다.
- 센서는 사양 범위 내에서 정상적으로 계측된 값을 출력하고 있었고,
- 유압 밸브는 정의된 제어 조건에 따라 정상 동작하고 있었으며,
- 소프트웨어 역시 설정된 고장 검출 조건에 따라 정상적으로 판단하고 있었습니다.
각 영역의 담당 엔지니어들은 저마다 “제 담당 부품은 스펙대로 완벽히 작동합니다”라고 보고할 수 있는 상황이었죠.
하지만 센서 고착(Stuck) 고장이 발생한 상태에서 변경된 유압 경로와 밸브 조건이 결합되자, 기존 검출 로직이 판단에 필요로 하던 압력 정보가 형성되지 않는 조건이 나타났습니다. 개별 부품은 모두 정의된 규칙대로 움직였지만, 이들이 결합한 시스템 레벨에서는 고장 진단이라는 핵심 기능이 상실된 것입니다. 시스템 엔지니어링에서 가장 경계하는 ‘창발적 결함(Emergent Issue)’이 나타난 순간이었습니다.
따라서 기능안전 분석의 역할은 개별 부품의 단위 시험 성적을 취합하는 수준에 머물러선 안 됩니다. 변경점이 시스템 전반에 미치는 연쇄적인 인과관계를 끝까지 추적해야 합니다.
[유압∙제어 조건 변경]
↓
[압력 정보 형성 변화]
↓
[기존 고장 검출 조건 영향]
↓
[시스템 반응 및 차량 거동]
4. DRBFM: 변경점에서 출발해 보이지 않는 영향 범위로 확장하다
이 복잡한 연쇄 영향도를 체계적으로 식별하기 위해 적용한 기법이 바로 DRBFM(Design Review Based on Failure Mode)이었습니다.
일부 현장에서는 DRBFM을 정해진 표준 양식의 빈칸을 채워 넣는 보고서 작업으로 치부하는 경우가 종종 있습니다. 하지만 DRBFM의 본질은 문서 작업이 아닙니다. 변경점이라는 작은 실마리에서 출발해 그 영향이 미치는 시스템 끝단까지 집요하게 질문을 확장해 나가는 ‘설계자 간의 다각적 엔지니어링 리뷰’ 그 자체에 있습니다.
[DRBFM 3단계 확장 질문 프레임워크]
[질문 1 : 무엇이 바뀌었는가?]
- 유압 유로 변경, 밸브 동작 시퀀스 및 개폐 듀티 제어 맵 수정
[질문 2 : 무엇이 영향을 받는가? (손대지 않은 부품의 재발견)]
- 한 줄도 고치지 않은 압력 센서 신호 처리부 및 고착 진단 소프트웨어
- 로직이 전제하고 있던 압력 형성 타이밍 및 유효성 재검토
[질문 3 : 그 결과 시스템과 차량에 어떤 일이 벌어지는가?]
- 특정 압력 미형성 영역에서 고착 고장 검출 불능
- 비상 제동 모드 전환 실패에 따른 휠 제어 편차 및 제동 안전성 저하
우리는 이 3단계 질문 프레임워크를 통해 직접 수정한 설계(유압/밸브)뿐만 아니라, 주변 환경 변화의 영향을 고스란히 받게 된 기존 설계(진단 로직)까지 선명하게 가려내어 분석 대상에 포함할 수 있었습니다.
5. 진리표로 조건을 펼쳐놓자 비로소 드러난 숨은 전제들
DRBFM으로 전체 윤곽을 잡았지만, 실제 도로 위에서 차량이 맞닥뜨릴 물리적 변수는 엔지니어의 경험이나 직관만으로 모두 예측하기 어려울 만큼 방대했습니다.
운전자가 브레이크를 처음 밟는 순간인가, 아니면 ABS(Anti-lock Braking System, 바퀴 잠김 방지 제동장치) 나 ESC(Electronic Stability Control, 전자식 차체자세제어)가 개입한 직후 다시 밟는 상황인가? 그때 밸브의 개폐 속도와 배관 라인의 잔류 압력은 어떠한가? 주관적인 경험에만 의존했다가는 검증 누락이라는 함정에 빠지기 십상입니다.
이에 따라 주요 운전∙시스템 조건을 진리표(Truth-Table)로 구조화하고, 각 조건 조합에서 고장이 발생한다고 가정했을 때 시스템 반응을 확인하는 What-if 시나리오 분석을 전격 도입했습니다.
º 조건 영역 (Input Conditions) :
브레이크 페달 조작 여부와 횟수, 페달 밟는 속도, 차량 진입 속도, 페달 입력 시점, 센서 고장 상태, 밸브 동작 상태, 유압 챔버 잔류 압력 등 주요 제동 시스템 요소를 다차원으로 교차 조합하여 분석 Case 구성
º 결과 영역 (System Responses) :
각 Case에 대해 센서 고착(Stuck) 발생 시 고장 검출 가능 여부, 판정 소요 시간, 제어 상태, 제동 영향, 안전 상태(Safe State) 천이 여부 및 추가 검증 필요 여부를 종합 평가
여기서 진리표가 ‘어떤 조건을 검토해야 하는가’를 누락 없이 구조화하는 프레임워크 역할을 했다면, What-if 분석은 ‘이 조건에서 고장이 발생하면 시스템이 어떻게 반응하는가?’를 하나씩 시뮬레이션하는 과정이었습니다. 이를 통해 고장 검출이 성립하는 조건과 그렇지 못한 조건, 그리고 제동 거동이 달라지는 물리적 경계를 명확하게 식별할 수 있었습니다.
이번 분석에서는 동일한 진리표 구조를 기준으로 기본 설계(기본안) 2,592건, 대안 설계 1안 2,586건, 대안 설계 2안 2,592건, 실차 검증 매핑 조건 2,592건을 도출했습니다. 그리고 각각의 Case에 대해 고장 발생을 가정한 What-if 분석을 수행하여, 총 10,362건의 조건별 시스템 반응을 정밀하게 검토했습니다.
💡 엔지니어링 노트 : 10,362건의 숫자가 뜻하는 것
여기서 10,362건은 시험 차량으로 트랙을 1만 번 넘게 달렸다는 의미가 아닌, 복잡하게 얽힌 시스템 변수들을 모조리 펼쳐두고, “어떤 조건의 교집합에서 센서 고착 진단이 성립하지 않았는가”를 수학적으로 가시화한 분석 모델의 케이스 수입니다. 도면과 코드 뒤에 숨어 있던 시스템 사각지대를 명시적인 데이터로 규명해 낸 작업이었습니다.
6. 같은 진리표 위에서 대안을 견주고, 가혹 조건은 실차로 증명하다
진리표 분석의 가장 큰 기술적 이점은 기존 설계와 개선 대안들을 동일한 기준 매트릭스 위에서 객관적으로 비교 검증할 수 있다는 점입니다.
조건 조합을 고정한 채 설계 파라미터만 변경하며 결과를 대조함으로써, 어떤 차이가 실제 설계 변경에서 비롯된 것인지 명확히 분리하여 파악할 수 있었습니다. 특히 특정 조건을 해결하기 위해 수정한 대안 로직이 다른 환경에서 예기치 못한 기능 누락이나 부작용(Side Effect)을 유발하지 않는지 철저히 검증했습니다.
우리는 정의된 분석 범위 안에서 기존 설계와 두 가지 대안의 고장 검출력 및 제동 영향을 비교했고, 그 결과를 바탕으로 새로운 유압 환경에 최적화된 최종 대안 로직을 도출했습니다.
분석을 마친 뒤, 실차 시험의 효율은 비약적으로 향상되었습니다. 1만여 개의 경우의 수를 맹목적으로 테스트하는 대신, 진리표 분석을 통해 ‘검출 여유도가 가장 취약한 경계 조건’만을 선별하여 실차 시험 매트릭스를 구성했기 때문입니다.
추려낸 대표 가혹 조건들을 바탕으로 연구소 시험 차량에 인위적인 결함을 주입하는 ‘실차 고장 주입 시험(Fault Injection Test)’을 진행했습니다.
실제 트랙 위에서 바퀴와 유압 관로의 압력 거동을 실시간으로 계측한 결과, 진리표 기반 What-if 분석에서 식별한 대표 조건을 실차에서 재현했을 때 시뮬레이션에서 짚어냈던 취약 지점에서 고착(Stuck) 결함이 정확하게 진단되었고, 시스템이 지체 없이 안전 상태(Safe State)로 전환됨을 확인했습니다.
진리표가 분석해야 할 조건 공간을 구조화하고 What-if 분석이 각 조건의 시스템 반응을 예측했다면, 실차 시험은 대표 Case의 실제 차량 거동을 확인해 최종 설계 판단의 타당성을 입증(Validation)한 셈입니다.
7. 과거 설계를 부정하는 일이 아닌, ‘검증의 전제’를 갱신하는 일
여기까지 읽다 보면 “그렇다면 이전의 설계가 불완전했던 것은 아닌가?”하는 의문이 들 수도 있습니다.
하지만 결코 그렇지 않습니다. 기존 양산 제품의 고장 진단 로직은 당시 유압 환경에 최적화되어 도로 위에서 뛰어난 신뢰성을 증명해 낸 자산이었습니다. 기존 차량에서는 센서 고착 결함이 발생할 경우 설계 사양에 맞춰 확실하게 검출되도록 설계되었기 때문입니다.
이번 사례는 기존 설계의 결함이 아니라, 더 빠르고 정밀한 차세대 제동 성능을 위해 ‘플랫폼의 유압 구조를 근본적으로 변경하면서 새롭게 파생된 선행 R&D 과제’였습니다. 시스템 아키텍처가 바뀌고 제어 규칙이 달라졌다면, 기존의 설계 자산 역시 새로운 물리적 동작 환경에 맞추어 다시 검증받고 갱신(Update)되어야 합니다.
양산 전 프로토타입 단계에서 DRBFM과 진리표를 통해 이 사각지대를 선별적으로 식별하고 실차 시험으로 입증해 낸 것은, 도로 위로 나가기 전 단 하나의 잠재 위험도 허용하지 않으려는 선제적 예방 품질 활동의 결실이었습니다.
이 과정은 앞선 1편에서 장훈도 책임님이 강조했던 ‘요구사항-아키텍처-분석 간의 추적성(Traceability)’이 개별 현장에서 어떻게 적용되는지를 보여줍니다. 소프트웨어 코드를 단 한 줄도 고치지 않고 그대로 가져왔더라도, 그 코드가 전제하고 있는 시스템 아키텍처 조건까지 동일한지 확인하는 작업이야말로 시스템 엔지니어의 핵심 책무입니다.
마무리하며
우리가 이번 프로젝트를 통해 얻은 결론은 명확합니다.
기존 설계를 무조건 배제하고 처음부터 다시 만들자는 뜻이 아닙니다. “설계를 재사용했다는 물리적 사실(Fact)”과 “과거의 검증 결과가 새 환경에서도 유효할 것이라는 가정(Assumption)”을 엄격히 분리해 점검하자는 제안입니다. SDV 시대로 나아갈수록 자동차 제동 시스템은 소프트웨어와 전동화 기구부가 더욱 긴밀하게 결합될 것입니다. 시스템이 복잡해질수록 엔지니어는 가장 익숙하고 당연해 보이는 문장 앞에서 의식적으로 걸음을 멈추어야 합니다.
“이 부분은 이전 양산품과 완전히 동일합니다.”
설계 검토 과정에서 이 문장을 다시 마주하게 된다면 한 걸음만 더 깊이 들어가 보시길 바랍니다. 무엇이 동일하며, 그 설계가 전제했던 유압과 신호의 물리적 동작 조건까지 정말로 동일한가? 그 집요한 질문이야말로 보이지 않는 시스템 사각지대를 해소하고, 도로 위 운전자의 안전을 가장 확실하게 보장하는 엔지니어링의 출발점이 되어줄 것입니다.
Reference
[1] SAE International, Design Review Based on Failure Modes (DRBFM), SAE J2886_202304.
(※ 본 아티클에 사용된 데이터 및 도식은 엔지니어링 방법론의 이해를 돕기 위해 보안상 개념화·추상화된 예시 데이터임을 밝힙니다.)
그림 수정 피드백 식별자 | FIG-01 · FIG-02 · FIG-03 · FIG-04
