NHTSA - Automated Lane Centering 관련 기능 안전 분석 정리

1. Introduction

ADAS(Level 2) 및 자율주행(Level 3 이상) 차량을 개발하는 엔지니어라면 차선 중앙 유지(Automated Lane Centering, ALC) 기능의 안전성 확보가 얼마나 중요한지 잘 아실 겁니다. 차선을 따라 차량을 자동으로 중앙에 유지해 주는 이 기능은 편리하지만, 잘못 동작할 경우 큰 사고로 이어질 위험이 있습니다. 그렇다면 기능 안전(Functional Safety) 측면에서 이러한 시스템을 어떻게 분석하고 안전 요구사항을 도출할 수 있을까요?

앞선 포스팅에서 설명드린 2018년 8월, NHTSA(미 도로교통안전국)는 “Functional Safety Assessment of an Automated Lane Centering System”라는 보고서(DOT HS 812 573)를 통해 이 질문에 대한 하나의 모범 사례를 제시했습니다.

 

해당 보고서의 전반적인 설명은 아래 포스팅에 정리했습니다.

 

NHTSA - Functional Safety Assessment of an Automated Lane Centering System 정리

 

이 보고서는 ISO 26262 표준의 Concept 단계(개념 단계)를 따라 시스템 수준의 위험 분석을 수행하고, 거기서 도출된 안전 목표(Safety Goals)를 바탕으로 상세한 기능 안전 요구사항(Functional Safety Requirements)을 정의하는 과정을 담고 있습니다. 특히 여러 분석 기법 (전통적인 HAZOP(Hazard and Operability Study)과 FMEA(Failure Mode & Effects Analysis), 그리고 STPA(Systems-Theoretic Process Analysis) 같은 최신 기법) 을 복합적으로 사용하여 안전성을 평가했습니다. 본 포스트에서는 해당 보고서의 핵심 내용을 소개하고, Lane Centering과 같은 레벨 2/3 시스템을 개발할 때 어떻게 응용할 수 있을지 살펴보겠습니다. 해당 포스팅에서는 다음과 같은 내용을 중점적으로 다루겠습니다:

• 시스템 수준 Hazard 분석 방법론: HAZOP과 STPA를 통해 어떤 위험 시나리오들이 식별되었는가? 구체적으로 어떤 위험 요소들(Hazards)이 파악되었나?
• 차량 수준 안전 목표(Safety Goals): 위의 Hazard 분석을 통해 도출된 최상위 안전 목표들이 무엇이며, 그 의미는 무엇인가?
• 기능 안전 요구사항(FSR): 안전 목표로부터 어떠한 기능 안전 요구사항들이 도출되었고, 그 추론 과정은 어떠했나?
• 분석 기법과 시스템 설계의 상호 작용: 시스템 아키텍처 설계, FMEA 결과, STPA 결과가 어떻게 유기적으로 결합되어 안전 요구사항을 형성했나?
• 현실적인 예시 시나리오: 실제 도로 상황에서 발생할 수 있는 대표적인 Hazard 사례들과, 이를 막기 위한 안전 메커니즘 혹은 설계 대책은 무엇인가?

 

2. Lane Centering 시스템과 초기 Hazard 분석

Block Diagram of a Generic ALC system

 

차량의 차선 중앙 유지 기능을 분석하려면 먼저 시스템의 범위와 구성을 정의해야 합니다. NHTSA 보고서에서는 “Generic ALC System”의 블록 다이어그램을 제시하여, 차량 조향을 담당하는 ALC 모듈과 이와 상호작용하는 센서/액추에이터/운전자 인터페이스 등을 한눈에 보여주었습니다. ALC 시스템은 차량 전방의 차선 정보를 인식하는 센서들, 조향 제어 명령을 결정하는 전자제어ユ닛(ALC Control Module), 실제 차량의 조향을 수행하는 하부 조향/동력 시스템, 그리고 운전자와의 인터페이스(차량 상태 표시, 운전자 입력 버튼, 운전자 주시 센서 등)로 구성됩니다. 이 밖에도 차선 변경 보조나 토크 벡터링 등 다른 차량 시스템들과의 인터페이스도 포함되어 있어, ALC가 작동 중일 때 다른 기능과 어떻게 조율할지 고려해야 합니다.

 

이러한 시스템을 토대로, NHTSA 팀은 Hazard 분석을 수행했습니다. 흥미롭게도 한 가지 방법만 사용한 것이 아니라 두 가지 서로 다른 접근법을 병행했습니다: 바로 HAZOP과 STPA입니다.

• HAZOP(Hazard and Operability Study): 원래 화학공정 등에서 안전 분석에 쓰이는 기법이지만, 여기서는 자동차 시스템에 응용되었습니다. 시스템의 주요 기능들을 목록화한 뒤 (예: "ALC 시스템 활성화", "차선 인식", "조향 명령 산출", "운전자 경고 표시" 등) 각각의 기능에 대해 “없음(No)”, “과도함(More)”, “부족함(Less)”, “늦음/Late”, “빠름/Early” 등의 가이드워드로 변화를 가정해 보는 겁니다. 예를 들어 “조향 명령 없음(No Steering Command)”이나 “필요 이상으로 과도한 조향(More Steering than Needed)” 같은 상황을 가정하고, 그로 인해 어떤 위험한 결과(Hazard)가 초래될 수 있는지 찾아내는 식이죠. 보고서에서는 ALC 시스템의 24가지 세부 기능에 대해 HAZOP 가이드워드 분석을 수행하여 총 5개의 차량 수준 Hazard를 확인했습니다.
  
  
• STPA(Systems-Theoretic Process Analysis): MIT의 Nancy Leveson 교수가 제안한 시스템 이론 기반의 Hazard 분석 기법입니다. STPA에서는 시스템을 제어 관점에서 모델링하여 컨트롤러(예: ALC 제어 유닛), 피드백 및 센서, 액추에이터(조향 시스템), 사람(운전자) 등을 포함한 제어 구조(Control Structure)를 그린 다음, 안전하지 않은 제어 행위(Unsafe Control Actions, UCA)를 식별합니다. 예를 들어 “필요할 때 조향 명령을 내리지 않음”, “불필요하거나 부적절한 순간에 조향 명령을 내림”, “ALC 해제를 요청해도 시스템이 해제되지 않음” 등 컨트롤러와 운전자 사이의 상호작용에서 발생할 수 있는 위험한 상황들을 찾아내는 것이죠. STPA의 1단계를 통해 발견된 이러한 UCA들은 다시 정제되어 차량 수준 Hazard로 정의됩니다. NHTSA의 STPA 분석 결과 HAZOP에서 나온 것들과 유사한 Hazard들이 도출되었으며, 총 6개의 Hazard가 목록화되었습니다.

두 방법을 통해 얻은 Hazard 목록을 통합 및 중복 조정하여 최종적으로 5개의 차량 레벨 Hazard가 확정되었습니다. (STPA에서 추가로 나온 하나의 Hazard인 “조향 제어 부재(Absence of Lateral Control Input)”는 논의 끝에 다른 항목에 포함시키기로 했다고 합니다. 이는 운전자와 시스템 중 누구도 조향을 하지 않는 상황을 말하는데, 결국 “운전자-시스템 간 제어 인계 미흡” Hazard의 일부로 볼 수 있었기 때문입니다.) 아래는 최종 정리된 5대 Hazard와 그 설명입니다:

• H1: 조향 부족으로 인한 차로 이탈 – ALC 시스템이 필요한 만큼 조향력을 제공하지 못해 차량이 차선을 이탈하거나 도로를 벗어나는 위험. 예컨대 센서 오작동 등으로 차선을 제대로 못 읽으면 차량이 서서히 한쪽으로 치우쳐 차선을 넘을 수 있습니다. (도로 곡률이 클수록 더 빨리 이탈할 것 입니다.)
• H2: 조향 과도로 인한 차로 이탈 – ALC 시스템이 과도한 횡조향 명령을 내림으로써 차량이 오히려 차선을 벗어나는 위험. 필요 이상으로 급격하게 조향하여 차로를 이탈하거나, 조향 보정을 잘못하여 한쪽으로 급격히 쏠리는 경우 등을 포함합니다. (예: 차량이 왼쪽으로 살짝 벗어나자 이를 보정하려고 과하게 우측으로 조향해버려 차량이 오른쪽 차선을 밟게 되는 경우).
  
  
• H3: ALC 시스템의 돌발적인 기능 상실 – 운전자에게 사전 경고 없이 ALC 기능이 갑자기 꺼지거나 작동불능 상태가 되는 위험. 이 경우 운전자가 즉시 수동으로 조향을 인계받아야 하는데, 상황에 따라 반응이 늦어져 사고로 이어질 수 있습니다.
  
  
• H4: 운전자와 시스템 간 부적절한 제어 전환 – 운전자와 ALC 시스템 사이에 조향 제어권 전환이 원활히 이루어지지 않는 위험. 여기에는 운전자에게 제어를 넘겨야 할 때 충분한 시간이나 경고를 주지 못하는 상황(Level 2/3), 운전자가 제어를 원해도 시스템이 계속 개입하는 상황 (예: 운전자가 핸들을 잡고 방향을 틀려고 하는데 ALC가 이를 무시하고 계속 중앙 유지하려고 버티는 경우), 운전자가 지금 조향을 맡고 있는지 시스템이 맡고 있는지 혼동하는 경우 등이 포함됩니다.
  
  
• H5: 다른 차량 시스템 동작 방해 – ALC 시스템이 다른 차량 기능의 정상적인 동작을 방해하여 위험을 일으킬 수 있는 경우. 예를 들어 상위 수준의 자동차선변경 시스템이나 긴급회피 시스템이 차량을 옆 차로로 이동시키려 하는데 ALC가 이를 눈치채지 못하고 계속 중앙 유지 명령을 내린다면 충돌이나 차량 불안정이 발생할 수 있습니다. 마찬가지로 차로 유지 중이라도 차량 안정화 장치(ESC)나 차동 제어(토크 벡터링) 등의 요청이 오면 ALC가 이를 적절히 양보하거나 협조해야 하는데, 그렇지 못한 경우가 hazard가 될것입니다.

이 다섯 가지 Hazard가 바로 Lane Centering 시스템에서 반드시 피해야 할 최대 위험 시나리오들입니다. Hazard 식별이 끝났으면, 다음으로는 각 Hazard의 심각도를 평가하고 대응 전략을 수립해야 합니다. ISO 26262에서는 이를 HARA(Hazard Analysis and Risk Assessment) 단계로 부르며, Hazard마다 심각도(Severity), 노출빈도(Exposure), 통제가능성(Controllability) 등을 고려해 ASIL 등급을 할당하게 됩니다. NHTSA 보고서 역시 이러한 위험 평가를 수행하여, 상황별 ASIL 등급을 결정했습니다.

 

특이한 점은, 운전자의 개입 여부나 자동화 레벨에 따라 ASIL이 달라졌다는 것입니다. 예를 들어 H1(조향 부족으로 차로이탈)의 경우 운전자가 항상 주시하고 있는 Level 2 상황에서는 ASIL B로 평가되었지만, Level 2임에도 운전자가 주의를 기울이지 않는 경우(“Driver Not Engaged”, 보고서에서 예상 가능한 오용 사례로 간주)나 Level 3 이상 자율주행 상황에서는 ASIL D까지 상승했습니다. 운전자가 바로 개입하여 제어를 되찾을 수 있느냐에 따라 안전 등급이 바뀐 것입니다. 요컨대 운전자에게 의존하는 Fail-Safe 전략이 통할 때는 ASIL이 비교적 낮게 책정되지만, 시스템 스스로 Fail-Operational해야 하는 상황이면 훨씬 높은 안전무결성 수준이 요구됩니다.

 

3. 차량 수준 안전 목표 (Safety Goals) 수립

위에서 도출한 Hazard들과 그 위험도 평가를 바탕으로, 이제 안전 목표(Safety Goal)를 정의할 차례입니다. 안전 목표란 차량 수준에서 반드시 달성되어야 할 최상위 안전 요구사항으로서, 각 Hazard를 방지하거나 완화하기 위한 목적을 나타냅니다. ISO 26262에 따르면 Hazard별로 하나 이상의 Safety Goal을 세우고, Hazard에 부여된 ASIL 등급이 그대로 그 Safety Goal에 부여됩니다. NHTSA 보고서에서는 최종 5개의 Hazard 각각에 대응되는 5개의 Safety Goal(SG1 ~ SG5)을 수립하였고, 이들은 Hazard 목록(앞서 H1~H5)과 일대일로 연결됩니다. Safety Goal의 서술은 Hazard와 거의 같지만 “~를 예방한다”, “~를 보장한다”와 같이 책임과 달성해야 할 바를 명확히 표현한 것이 특징입니다.

 

아래는 정의된 다섯 가지 차량 수준 Safety Goal입니다:

Safety Goals for the ALC System

1. SG1 – 조향 부족으로 인한 차로 이탈 방지: “ALC 시스템이 작동 중일 때 조향이 불충분하여 차량이 차선/도로를 이탈하지 않도록 예방할 것.” 즉, H1 Hazard를 예방하는 것이 목표입니다.
2. SG2 – 조향 과도로 인한 차로 이탈 방지: “ALC 시스템이 작동 중 과도한 횡방향 제어로 차량이 차선/도로를 이탈하는 사태를 막을 것.” (H2 예방)
3. SG3 – ALC 기능의 돌발 상실 방지: “ALC 시스템의 예기치 못한 작동 중지/해제를 방지할 것.” (H3 예방)
4. SG4 – 운전자-시스템 간 올바른 제어권 전환 보장: “운전자와 ALC 시스템 사이에 제어 권한 전환이 적절하게 이루어지도록 할 것.” (H4에 대응. 예컨대 시스템이 운전자에게 제어를 넘길 때 충분히 인지시키고 안전하게 넘긴다든지, 운전자가 조향을 원하면 즉시 시스템 개입을 줄이는 등)
5. SG5 – ALC와 다른 차량 시스템 간의 제어 조정 보장: “ALC의 횡향 제어 동작이 차량 내 다른 시스템/기능들과 조율되도록 할 것.” (H5 대응. 다른 시스템의 요청을 방해하지 않고, 필요시 자신을 일시 중지하거나 협력 작동해야 한다는 것)

각 Safety Goal에는 해당 Hazard에서 도출된 ASIL 등급이 그대로 부여됩니다. 예를 들어 SG2(조향 과도 방지)의 경우 모든 상황에서 ASIL D로 지정되었는데, 이는 Hazard H2가 Level 1~5 자동화 어느 경우에도 치명적이라 판단되었음을 뜻합니다. 반면 SG1(조향 부족 방지)은 운전자가 개입 가능한 Level 1~2에선 ASIL B로, 운전 미개입 또는 L3+에선 ASIL D로 책정되었습니다. 이러한 차이는 설계 시 필요한 안전 메커니즘의 강건성 수준을 결정하는 데 중요합니다. 예컨대 SG1을 ASIL D로 만족시키려면 이중화 등 결함허용(Fail-Operational) 설계가 필요할 수 있지만, ASIL B 수준이라면 적극적 결함 감지 및 안전상태 전이(Fail-Safe) 정도로도 달성될 수 있을 것입니다.

 

요약하자면, Safety Goal은 “어떠한 일이 있어도 시스템이 이러이러한 위험을 일으켜선 안 된다”는 최고 수준의 안전 요구 사항입니다. 이제 다음 단계는, 이러한 추상적인 목표들을 실현하기 위해 좀 더 구체적인 시스템 차원의 안전 요구사항들을 뽑아내는 것입니다.

 

4. Safety Goal 에서 기능 안전 요구사항 (FSR) 도출

ISO 26262의 Concept 단계에서는 Safety Goal을 확정한 뒤, 기능 안전 컨셉(FSC: Functional Safety Concept) 작업을 통해 각 목표를 달성할 수 있는 구체적인 방법을 구상합니다. 이 과정에서 나오는 산물이 바로 기능 안전 요구사항(FSR)들이죠. FSR은 시스템 혹은 서브시스템 수준에서 구현되어야 할 요구사항으로, Safety Goal을 만족시키기 위한 구체적이고 검증 가능한 조건들입니다. 쉽게 말해 Safety Goal이 “무엇을 지켜야 하나”를 말한다면, FSR은 “그걸 지키려면 시스템이 어떻게 행동해야 하나”를 말해줍니다.

 

Functional Safety Concept Process

 

NHTSA 보고서 팀은 FSR 도출을 위해 앞서 수행한 안전 분석 결과(FMEA와 STPA 결과)를 적극 활용했습니다. 기능 FMEA를 통해 얻은 구성요소별 고장 시나리오와, STPA Step 2를 통해 얻은 안전상 위험 유발 인과관계 등을 모두 검토하여, Safety Goal을 만족시키는 데 필요한 요구사항들을 체계적으로 수립한 것입니다. 그 결과 총 47개의 기능 안전 요구사항이 도출되었고, 여기에 추가로 26개의 보조적 안전 요구사항까지 제시되었습니다. (추가 요구사항들은 주로 진단 기능 향상이나 테스트 시나리오 등에 관한 것으로, STPA 단계에서 파생된 것들입니다.)

 

FSR들은 시스템 설계 관점에서 여러 범주로 나눠볼 수 있습니다. 보고서에서는 일반 시스템 요구사항, ALC 제어모듈 관련, 차선센서 관련, 운전자감지 센서 관련, 운전자 입력장치 관련, 전원 및 통신 관련, 인터페이스 시스템 관련 등으로 분류하여 표로 정리하였는데, 여기에서는 그중 핵심적인 내용을 살펴보겠습니다. 전반적으로 FSR들은 ISO 26262에서 권장하는 안전 전략들을 골고루 반영하고 있습니다:

• 결함 검출 및 진단(Detection): 시스템 요소에 결함이나 이상 상황이 발생하면 즉시 이를 감지하고 대응해야 합니다. 예를 들어 ALC 제어모듈이 비정상적으로 큰 조향토크 명령을 내리는 경우 이를 감지하는 모니터링 요구사항이 포함되었습니다. 또 센서 신호가 상식적인 범위를 벗어나면 이를 감지하여 사용을 중지하는 기능, 통신 메시지에 에러 체크(sum check, parity 등) 적용 등의 요구도 있죠.
  
  
• 결함 허용(Fault Tolerance): 하나의 결함만으로 곧바로 안전 목표가 위배되지 않도록, 시스템에 여유도나 백업을 두는 것입니다. 예를 들어 중요 센서 입력은 이중화하거나 교차검증해야 하며, 주요 연산은 두 개의 독립된 프로세서에서 수행하여 하나가 고장나도 다른 하나가 조향 제어를 지속하도록 설계해야 한다는 요구사항이 제시되었습니다. 이는 특히 ASIL D로 분류된 목표(SG2 등)를 만족하기 위해 필수적인 전략입니다. 보고서 그림에서는 이를 위해 ALC 제어모듈을 두 개 두고 투표기(voter)로 검증하는 이중화 예시가 제시되기도 했습니다(이에 대해서는 뒤에 더 설명).
  
  
• 안전 상태 전환(Safe State Transition): 문제가 발생했을 때 시스템을 완전히 끄거나 축소된 기능 모드로 전환하여 안전한 상태로 유도해야 합니다. 예컨대 조향 명령 계산값이 물리적으로 말이 안 되게 크다면, 시스템이 즉시 자동조향을 해제하고 운전자에게 경고를 주도록 요구하고 있습니다. 이때 차량이 급격히 불안정해지지 않도록 조향 토크를 서서히 0으로 줄인다든지, 차량이 차로를 이탈하지 않게 다른 안정화 시스템과 협조하는 것이 중요합니다. 요컨대 “고장 시 안전하게 실패”하도록 설계하는 것입니다.
  
  
• 운전자 경고 및 인식(Warning and Awareness): 운전자의 역할이 남아있는 Level 2/3 시스템에서는 운전자에게 상황을 명확히 알리는 것 자체가 하나의 안전 기능입니다. 그래서 ALC가 자기가 꺼졌음을 즉시 운전자에게 알릴 것, 운전자의 핸들 조작 의지를 센서로 모니터링하여 운전자가 개입하려 하면 시스템이 재빠르게 양보할 것, 운전자의 주의력이 떨어지면 경고를 줄 것 등의 요구사항도 포함되었습니다.
  
  
• 인터페이스 및 조율(Coordination): ALC가 차량의 여러 시스템과 연계되어 있으므로, 다른 시스템으로부터 오는 신호나 요청을 정확히 해석하고 상충되는 명령이 없도록 해야 합니다. 예를 들어 운전자가 방향지시등을 켜면 ALC는 이를 감지하여 차로 변경 의도를 파악하고 즉시 차선유지 제어를 완화하거나, 상위 자동주행 시스템이 “ALC 일시정지” 명령을 보내오면 즉시 이를 따를 것 등이 요구됩니다. 또한 차량의 속도제어나 자세제어(ESC) 등 종방향/수직방향 시스템과도 데이터를 교환하여, 조향 제어가 차량 안정성에 미치는 영향을 서로 고려해야 합니다.

위의 FSR 예시들은 Safety Goal을 실현하기 위한 여러 수단들을 보여줍니다. 예를 들어 “조향 과도 방지”(SG2) 목표를 달성하려면, 센서/모듈의 잘못된 동작을 사전에 탐지하고(Detection), 어느 하나의 센서 고장으로는 잘못된 조향 명령이 나오지 않게 이중화하며(Fault Tolerance), 만약 그런 상황이 발생해버리면 즉시 시스템을 종료하고 운전자에게 알려 차량을 안정화(Safe State & Warning)하는 식으로 다층 방어를 해야 함을 알 수 있습니다.

보고서에서는 이러한 과정을 Table 29에 정리하면서, 첫 번째 요구사항은 결함 검출 전략, 두 번째는 결함 허용 전략, 세 번째는 안전상태 전이 및 운전자 경고 전략의 예시임을 설명하고 있습니다.

마지막으로, 도출된 모든 FSR들은 시스템의 초기 아키텍처 요소들에 할당됩니다. 예컨대 “이중 센서 적용” 요구사항은 차선 인식 센서 설계에 할당되고, “운전자 경고” 요구는 계기판/경고 시스템에 할당되는 식입니다. 이렇게 함으로써 각 요구사항이 누가 책임지고 구현해야 할 사항인지 분명해집니다. 또한 일부 Safety Goal은 운전자 교육이나 정기 정비 같은 차량 외적 조치(external measure)로 완화될 수도 있는데, 그런 경우도 함께 고려합니다. (예를 들어 “운전자가 항상 주의를 기울일 것” 같은 부분은 기술적 요구사항이라기보다 운전자 설명서나 HMI 설계 원칙으로 반영될 수 있겠죠.)

 

정리하면, Safety Goal에서 FSR을 도출하는 과정은 추상적인 목표를 구체화하고, 이를 시스템 설계 요소와 연결짓는 작업입니다. NHTSA의 사례에서는 다양한 분석기법의 결과를 활용하여 이 과정을 체계적이고 꼼꼼하게 수행했음을 알 수 있습니다.

 

5. 시스템 설계, FMEA, STPA 연계

위에서는 Hazard→Safety Goal→FSR의 흐름을 살펴봤지만, 이 모든 과정 내내 시스템 설계도 함께 고려되었다는 점을 인지하고 있어야 합니다. 기능 안전은 분석 결과와 설계 간의 상호작용 속에서 달성되는 것이기 때문입니다. NHTSA 보고서는 이를 잘 보여주는데요, 특히 FMEA와 STPA를 병행하여 얻은 통찰이 어떻게 설계 전략에 반영되는지 흥미로운 사례가 많습니다.

 

먼저 기능 FMEA 측면을 보겠습니다. 보고서에서는 ALC 시스템을 구성하는 각 주요 하위 시스템에 대해 FMEA를 수행하여 총 53가지의 고장 모드와 211개의 잠재적 결함 원인을 분석했습니다. 예를 들어:

• 차선 인식 센서의 고장 모드로는 “좌측 차선 인식 불가”, “차선 잘못 인식(오인식)” 등이 있을 것이고, 그 원인으로는 카메라 렌즈 오염, 센서 통신 오류 등이 제시됩니다.
• ALC 제어모듈의 고장 모드로는 “잘못된 조향각 계산”, “제어 루프 정지(프로그램 프리즈)”, “오류 있는 차량 속도 신호 처리” 등 다양하게 식별됩니다. 원인으로는 메모리 비트 플립, 소프트웨어 버그, 연산 오버플로우 등이 있을 수 있겠죠.
• 운전자 인터페이스 쪽으로는 “경고 표시 누락”, “잘못된 상태 표시” 같은 것이, 조향 액추에이터 쪽으로는 “요구 토크 미달”, “요구와 무관한 자발적 조향 발생” 등의 고장이 고려됩니다.

이러한 FMEA 결과는 각각 어떤 Safety Goal에 영향을 주는지 연결지어졌습니다. 예를 들어 “경고 표시 누락”은 SG3(돌발 상실 방지)나 SG4(제어 전환 보장)에 치명적이므로 그에 대한 요구사항(예: 경고 신호 이중화나 진단)이 도출되었을 것입니다. “잘못된 조향각 계산” 오류는 SG1/SG2(차로이탈 방지)에 직결되니, 그에 대한 결함 검출 로직이나 보조 알고리즘(예: 이중 계산 비교)이 요구되었겠지요. 이렇듯 FMEA는 각 부품/기능의 고장이 시스템 Hazard로 이어지는 고리를 구체적으로 확인해 주므로, Safety Goal 달성을 위해 어떤 설계조치가 필요한지 직접적인 힌트를 제공합니다.

 

다음으로 STPA 측면을 보겠습니다. STPA는 앞서 Hazard 식별에도 쓰였지만 2단계에서는 각 Unsafe Control Action의 발생 원인 시나리오를 분석합니다. 이는 단순 하드웨어 고장이 아닌 시스템/소프트웨어 논리 상의 문제나 운전자와의 상호작용 문제까지 포괄합니다. 예를 들어 STPA는 다음과 같은 시나리오 원인을 찾아낼 수 있습니다:

• 운전자가 개입 불능 상태인데 시스템이 그를 과신하는 경우: 운전자가 한눈 판 상황에서 ALC가 꺼지면 안 되는데, 혹시 운전자 모니터링 기능이 부정확해서 운전자가 주시하지 않는데도 주시 중으로 잘못 판단할 수 있습니다. 이는 Hazard H4/H3과 관련된 STPA 원인 시나리오이며, 운전자 상태 오인 방지 요구사항 등으로 이어졌을 것입니다.
  
  
• 제어 신호 타이밍/논리 오류: 예컨대 ALC 모듈이 차선 인식을 늦게 받아 급조향 명령을 내리거나, 차선 변경중임을 알리는 신호를 무시하고 계속 중심 유지 명령을 내리는 논리 오류도 STPA에서 드러납니다. 이러한 원인은 소프트웨어 동기화, 신호 유효성 검증 등의 요구사항으로 대응되었을 것입니다.
  
  
• 휴먼-머신 인터페이스 착오: 운전자가 ALC를 켠 줄 알았는데 실제론 꺼져 있다거나 (또는 반대로) 하는 모드 혼동 상황도 STPA Hazard 인과로 지목됩니다. 이에 대해 명확한 HMI 표시 요구사항, 모드 혼동을 줄이는 UX 설계 등이 필요하다는 통찰을 줍니다.

특히 STPA는 인적 요소(Human factor)나 시스템 간 상호작용에서 기인하는 위험을 찾아내는 데 강력합니다. FMEA로는 잡아내기 어려운 이러한 시나리오들을 STPA 결과가 보완해준 것입니다. 실제로 보고서에서 STPA 분석으로 하나 추가 식별되었던 Hazard가 바로 “조향 제어 부재(운전자도 시스템도 조향 안 함)” 상황이었다고 앞서 언급했는데요, 이는 운전자 미개입 + 시스템 정지라는 조합 상황으로, 전통적 고장 분석만으로는 간과하기 쉽지만 STPA로는 자연스럽게 떠올릴 수 있는 위험이었습니다.

 

결과적으로 NHTSA 팀은 FMEA와 STPA에서 나온 인사이트들을 모두 반영하여 설계를 보완했습니다. Safety Goal 달성에 필요한 여러 가지 안전 메커니즘들이 여기서 도출되었죠. 그리고 이러한 메커니즘은 시스템 아키텍처 설계에 구체적으로 녹아들게 됩니다. 예를 들어:

Example Fail-Safe Concepts for ALC System Components

• Fail-Safe(수동 안전) 방식으로 할지, Fail-Operational(능동 안전) 방식으로 할지 결정되었습니다. Fail-Safe란 고장 시 시스템을 즉시 종료하고 운전자에게 맡기는 전략이고, Fail-Operational은 고장 상황에서도 일정 시간/기능을 유지해 안전을 지키는 전략입니다. 보고서에서는 두 가지를 대비하며 설계를 논했는데, 레벨 2 (운전자 개입 가능)까지는 Fail-Safe로도 안전 목표를 만족할 수 있지만 운전자가 바로 개입 어려운 상황(레벨 3~)에서는 Fail-Operational 구조가 요구됨을 지적합니다.
  
  

  

  Example Fail-Operational Concepts for ALC System Components

• 이중화 아키텍처 적용: 예를 들어 듀얼 ALC 제어모듈 + 투표 로직 구조를 제시하여, 하나의 컨트롤러에 오류가 생겨도 다른 하나가 계속 조향을 담당하게 했습니다. 보고서 그림 예시(위 두 그림)에서는 센서퓨전-제어모듈 두 채널과 2중 투표기/차단기 블럭이 보여지는데, 첫 번째 고장에서는 시스템 기능을 잃지 않고 계속 작동하는 Fail-Operational을 구현한 모습입니다. 대신 두 번째 고장이 겹치면 그때는 안전하게 종료(Fail-Safe)하는 계층적 접근도 설명합니다.
  
  
• 전원 공급 및 차량 하부시스템의 안전성: 조향을 위한 전원이나 파워스티어링 등의 하부 시스템은 Fail-Operational 구현이 어려울 수 있는데, 그런 경우 제한된 시간 동안이라도 전원이 유지되도록 요구하거나(예: “Low-voltage 전원이 안전상태 도달 시까지는 유지되어야 한다”), 기계적 백업(운전자가 직접 조향 가능한 상태 보장)을 고려했습니다. 브레이크나 ESC 개입 시에는 ALC가 토크 요청을 조정한다든지 하는 협조 전략도 설계에 반영되었습니다.

이처럼 안전 분석 → 설계 요구사항 → 아키텍처 구현이 하나의 흐름으로 연결됩니다. 중요한 것은, 분석 결과가 설계로 끝나는 게 아니라 설계 결정을 하면 다시 새로운 분석이 필요할 수 있다는 점입니다. NHTSA 보고서도 이를 언급하는데요, 일단 1차로 도출된 Safety Concept을 적용한 설계를 가지고 나면, 그 구체적인 설계 하에서 추가로 나타날 Hazards나 필요한 요구사항이 없는지 재검토해야 한다는 것입니다. 예컨대 이중화 설계를 하면 "dual-channel 시스템 특유의 hazard (예: 둘다 오작동하여 같은 잘못된 명령을 내리는 경우)" 같은 게 새로 생길 수 있고, 또 다른 보완책이 필요할 수 있습니다. 따라서 기능 안전 활동은 반복적(Iterative)으로 진행되며, 분석과 설계가 끊임없이 피드백 루프를 이루어야 합니다.

 

6. 현실 시나리오 예시와 안전 메커니즘

이론적인 내용이 다소 길었는데, 이번에는 보고서에 나온 구체적인 시나리오 예시를 통해 앞서 언급된 Hazard와 안전 메커니즘을 더 생생하게 이해해 보겠습니다. NHTSA 팀은 도출된 Safety Goal 각각에 대해 현실적인 주행 시나리오를 가정하고, 그 시나리오에서 어떤 고장을 주입하면 안전 목표가 어떻게 위협받는지 시험하는 식으로 접근했습니다. 이 과정은 곧 테스트 케이스 설계로 이어지는데, 여기서는 몇 가지 시나리오를 추려 설명하겠습니다.

• 시나리오 1: 고속도로에서의 조향 부족 (SG1 관련) – 운전자가 고속도로를 주행하며 ALC를 켠 상황을 가정합니다. 차로는 완만한 곡선이고, 차량은 초기에는 차로 중앙에서 조금 오른쪽으로 치우쳐 있으며 한쪽 차선 경계 쪽으로 서서히 접근하고 있습니다. 이제 여기에 어떤 결함을 발생시켜 볼까요? 대표적으로 차선 인식 센서가 장애를 일으켜 오른쪽 차선을 못 보게 만드는 고장을 주입할 수 있습니다. 그러면 ALC 제어모듈은 차량이 오른쪽으로 치우치는 것을 제대로 인식하지 못하고 충분한 왼쪽 조향 보정을 하지 않을 겁니다. 결과적으로 차량은 계속 오른쪽으로 흐르다가 차선을 밟고 이탈하게 되겠죠. 이 상황이 바로 Hazard H1: 조향 부족으로 차로 이탈의 한 예입니다. 보고서에서는 이를 Level 2 운전자 개입 여부에 따라 두 가지로 나눠 봤습니다:
  • Case 1: 운전자가 전방을 주시하고 즉각 개입할 준비가 되어 있는 경우 – 센서 고장을 운전자 대신 시스템이 먼저 감지하여 대시보드에 경고등을 켜고 경고음을 울립니다. 동시에 ALC 기능을 점진적으로 끄면서 차량 조향 권한을 운전자에게 이양합니다. 운전자는 경고를 인지하고 바로 핸들을 잡아 차량을 다시 중앙으로 복귀시킵니다. 이때 운전자의 개입까지의 시간 지연이 짧기 때문에 차량이 차선을 살짝 밟더라도 크게 벗어나기 전에 수습될 수 있습니다. (ASIL B 수준 대응)
    
    
  • Case 2: 운전자가 한눈을 팔거나 졸고 있어서 바로 개입하지 못하는 경우 – 이 경우 시스템이 최대한 시간을 벌어줘야 합니다. 센서 고장을 감지하면 즉시 백업 시스템이나 이중화 알고리즘을 통해 일정 시간동안은 차로 유지 기능을 계속 수행합니다. 예를 들어 다른 카메라나 지도 정보를 활용하여 “어렴풋이” 차선을 추정해서라도 차량을 중앙 근처에 유지하려 시도하거나, 차로 경계에 가까워지면 차량을 차선 중앙이 아닌 도로 경계선이라도 따라가도록 제한적으로 조향하는 방법도 있을 것입니다. 동시에 운전자에게는 더 강한 경고 (시트 진동이나 큰 경고음 등)로 깨우려고 합니다. 이러한 Fail-Operational 동작 덕분에 차량이 바로 도로를 이탈하지 않고 수 초간은 차로 내에 머물게 되고, 운전자가 뒤늦게라도 개입하여 조향을 인계받을 시간을 벌게 됩니다. 만약 그 시간 내에도 운전자 반응이 없다면, 최후에는 차량을 서서히 속도를 줄이며 차선 내에 정차시키는 식의 Minimum Risk Manoeuvre까지 고려될 수 있습니다. (ASIL D 수준 대응)
  위의 두 케이스는 동일한 Hazard(H1)에 대한 대응이지만 운전자 주시(Engagement)에 따라 Fail-Safe vs Fail-Operational 전략이 어떻게 달라지는지를 보여줍니다. 보고서의 테스트 시나리오에서도 “Driver Engaged”(운전자 주시) 상황과 “Driver Not Engaged”(운전자 미주시) 상황을 나눠 고장 주입 테스트를 구상한 것이 인상적입니다. 결국 조향 부족으로 인한 차로 이탈이라는 Safety Goal 위협 시나리오에 대해, 시스템은 운전자 상태를 고려한 다층 대비를 해야 함을 알 수 있습니다.
  
  
• 시나리오 2: 잘못된 조향으로 인한 급격 차로 이탈 (SG2 관련) – 이번에는 ALC 시스템이 너무 과도한 조향 명령을 내리는 바람에 차량이 자기 차로를 벗어나 버리는 상황을 가정해봅시다. 예를 들어 차량이 완만한 직선 도로를 주행 중인데, 제어모듈의 버그로 인해 갑자기 핸들을 오른쪽으로 크게 꺾으라는 명령이 나왔다고 상상해보죠. 그러면 차량은 본인 차로에서 급격히 오른쪽으로 움직여 옆 차선이나 도로 밖으로 뛰쳐나갈 수 있습니다. 이는 명백히 Hazard H2: 조향 과도로 인한 차로 이탈에 해당합니다. 이러한 상황을 막기 위해 시스템에는 여러 안전장치가 설계되어 있습니다:
  • 조향 명령 제한: 정상적인 상황에서 ALC가 요구하는 조향 각도/토크는 물리적으로 한계가 있습니다. 예를 들어 차선을 따라 조향하는데 필요한 각도는 대개 몇 도 이내일 것입니다. 따라서 제어모듈이 터무니없는 명령(예: 현재 속도에서 불가능한 급조향)을 내려도 실제 조향 액추에이터가 그 이상으로 반응하지 않도록 제한(Torque/Angle Limit)을 겁니다. 일종의 “안전 울타리”를 쳐 놓는 것이죠.
    
    
  • 이상 조향 검출: 그와 동시에, 이상치 검출 알고리즘이 필요합니다. 만약 제어모듈이 짧은 시간 내에 너무 빈번하게 큰 조향 명령을 낸다거나, 좌우로 심하게 흔들리는 명령을 내릴 경우 이를 소프트웨어적으로 감지하도록 합니다. 보고서에서는 이를 Detection 전략의 예로 언급했는데, 예컨대 “계산된 조향 토크 또는 요레이트가 임계치를 넘으면 시스템은 안전상태로 전환하고 운전자에게 경고한다”는 식의 요구사항이 그에 해당합니다.
    
    
  • 결함 허용/이중화: 그런데 만에 하나 액추에이터 쪽 오류로 기계적으로 핸들이 꺾여버리는 경우도 고려해야 합니다. 이를 위해 조향 장치 자체에도 이중 안전 메커니즘(예: 조향각 센서 2중화 및 차이 비교, EPS 모터 과전류 차단 등)을 넣고, 브레이크/ESC와 연계하여 차량이 급조향으로 거동이 불안정해지면 ESC가 개입하도록 협조합니다. 따라서 한쪽으로 확 쏠리려는 차를 ESC가 순간 제동으로 바로잡거나, 엔진 출력을 제한해 속도를 줄이는 등의 보조를 해줄 수 있습니다.
    
    
  • 운전자 경고 및 개입: 동시에 운전자에게도 이상상황을 알립니다. 사실 차량이 갑자기 꺾이면 운전자도 바로 눈치채겠지만, 경고음/계기판 표시로 “LKA 오류 발생” 등을 띄워 즉시 운전자가 수동 운전으로 전환하도록 유도합니다. 운전자는 핸들을 잡고 시스템을 끄면서 차량을 제어해 원래 차로로 복귀시키거나 안전한 곳에 정차하게 될 것입니다.
  위 대책들은 조향 과잉으로 인한 위험을 줄이기 위한 것으로, 이미 ALC 양산차량들에서도 종종 찾아볼 수 있는 메커니즘입니다. 예를 들어 많은 LKA(차로 유지 보조) 시스템들은 운전자가 일정 힘 이상으로 핸들을 조작하면 즉시 제어를 운전자에게 양보하도록 되어 있는데, 이는 만약 시스템이 오작동해 핸들을 틀더라도 운전자가 힘을 주어 제어권을 쉽게 되찾을 수 있게 한 안전장치입니다. 또한 EPS(Electric Power Steering) 유닛은 토크 요청 신호에 대해 하드웨어적인 상한을 두고 있고, 차량 네트워크에서는 비현실적인 조향각 요청은 무시하도록 설계하는 등 다중 안전장치가 적용됩니다. NHTSA 보고서의 분석을 보면 이러한 기존의 모범 사례들도 잘 반영되어 있다고 볼 수 있습니다.
  
  
• 시나리오 3: 시스템 돌연 종료 (SG3 관련) – ALC 시스템이 주행 도중 아무 예고 없이 꺼져버리는 상황을 가정합니다. 예를 들어 제어모듈 소프트웨어가 버그로 크래시되어 리셋된다면, 운전자는 갑자기 조향 도움이 사라진 것을 느끼게 될 것입니다. 만약 직선 도로라 당장 문제는 없더라도, 커브길 한복판이었다면 큰일이겠죠. 이런 돌발적인 기능 상실을 예방/완화하기 위한 기법으로는:
  • 프리페일(Pre-fail) 경고: 완전히 고장나기 전에 징후를 포착해 운전자에게 미리 경고하는 것이 최선입니다. 예를 들어 센서 신호 품질이 떨어지거나 통신 지연이 심해지는 등 문제가 감지되면, 아직 제어 가능해도 “조만간 기능이 제한될 수 있습니다”라는 경고를 띄우는 것입니다. 운전자는 그 신호를 보고 미리 대비할 수 있습니다. (요즘 차량들도 카메라 시야 불량시 “LKA 일시 제한됨” 같은 메시지를 주죠.)
    
    
  • 디그레이드 모드(Degrade Mode): 완전 꺼지기보다는 부분 기능이라도 유지하는 방향입니다. 예를 들어 메인 제어모듈에 문제가 생기면, 간소화된 백업 알고리즘(혹은 서브 컨트롤러)이 차선을 계속 추종하려 노력하면서 “긴급 모드”로 동작하는 겁니다. 이때 성능은 떨어질 수 있지만, 운전자가 개입할 시간을 벌어줍니다.
    
    
  • 안전 해제 및 경고: 결국 시스템이 꺼질 수밖에 없다면, 최소한 운전자에게 즉각 알려주고 안전하게 해제해야 합니다. 보고서에서도 “시스템이 해제되거나 고장나면 운전자에게 경고” 기능을 Safety Goal 차원에서 강조했습니다. 구체적으로는 청각 경고 + 시각 경고를 조합하고, 야간이라면 경고등 깜빡임 등 강한 신호로 운전자가 바로 알아차리게 합니다. 그리고 핸들에 모터 도움을 서서히 줄여 운전자가 이질감 없이 조향을 넘겨받도록 하는 등 HMI 측면도 고려됩니다.
    
    
• 시나리오 4: 제어권 혼동 (SG4 관련) – 운전자와 시스템의 조향 권한이 뒤섞여 혼란이 생기는 사례입니다. 가령 운전자가 급하게 장애물을 피하려고 핸들을 꺾는데 ALC가 이를 “차선 이탈”로 오인해 반대쪽으로 조향을 시도하면 서로 핸들을 두고 싸우는 형국이 될 수 있습니다. 이런 문제를 막기 위해 대부분의 차선 유지 시스템은 운전자 입력에 즉각 양보하는 설계를 취합니다. 즉 운전자가 어느 정도 힘으로 조향을 시도하면 센서가 이를 감지하고 ALC는 즉시 개입을 중단하는 것이죠. 한편 반대 상황으로, ALC가 해제를 요구했는데 운전자가 못 알아들어 제어 공백이 생기는 경우도 있습니다. 이를 위해선 운전자 모니터링이 핵심입니다. 보고서에서는 운전자 주시 센서를 통해 운전자의 몰입도를 판단하고, 필요 시 더 강한 경고나 자동 개입 중지까지 고려하고 있습니다. 예컨대 Level 3 상황에서 운전자가 자꾸 눈을 감거나 한눈을 팔면 차량이 스스로 차로를 유지한 채 서서히 감속하면서 깨우는 절차가 필요할 수 있습니다 (일부 상용 차량은 이미 이러한 콜버트 플랜을 구현). 결국 SG4 관련 안전 요구는 “운전자가 언제 제어를 다시 잡을 수 있는지 확실히 알고, 또 시스템이 운전자 의도를 잘 알아차릴 것”으로 요약됩니다.
  
  
• 시나리오 5: 타 시스템과의 충돌 (SG5 관련) – 마지막으로, ALC와 다른 기능 간의 인터페이스 사례입니다. 예를 들어 차량에 자동 차선변경 보조(TJA) 기능이 있어, 방향지시등을 켜면 자동으로 옆 차로로 넘어가도록 설계됐다고 합시다. 운전자가 차선 변경 버튼을 눌렀을 때, ALC는 즉시 자기 임무를 내려놓고 상위 기능의 조향 요청을 받아들여야 안전합니다. 만약 ALC가 이를 무시하면 차량은 차로 변경 중에 원래 차선으로 끌려 돌아가려는 힘과 싸우게 되겠죠. 이러한 문제를 예방하려면 시스템 간 명령 우선순위를 명확히 정하고 소통해야 합니다. 보고서에서는 ALC가 다른 시스템 (ACC, ESC, AEB 등)으로부터 들어오는 “지금은 차선유지 하지 마” 신호에 반응하도록 요구하고 있습니다. 실제 구현에서는 차량 통합제어기가 각 기능 모듈을 조율하거나, ALC 모듈 자체에 다른 시스템 신호 인터페이스를 넣어 Arbiration 로직을 타게 합니다. 또한 ALC와 ESC가 동시에 조향을 제어할 수는 없으므로, ESC 개입 시 ALC는 일시적으로 제어를 낮추고 ESC가 끝나면 다시 복귀하는 식의 협조도 필요합니다. 이러한 인터페이스 안정성은 시나리오로 테스트하기는 어렵지만, 소프트웨어 아키텍처 설계와 통합 테스트 단계에서 매우 중요한 부분입니다.

이상으로 몇 가지 현실 시나리오를 통해 Lane Centering 시스템의 Hazard와 그에 대응하는 안전 기법들을 살펴봤습니다. 각각의 상황에서 시스템이 어떻게 반응하도록 설계되어야 하는지가 감이 오실 것이라고 생각됩니다. 요컨대, "문제가 발생해도 사고로 이어지지 않도록 여러 겹의 안전망을 구축하는 것"이 기능 안전 설계의 핵심임을 알 수 있습니다. 또한 운전자 개입 가능 여부나 다른 시스템과의 관계 등 맥락(Context)에 따라 요구되는 안전 대책이 달라지는 점도 중요합니다. 이런 부분들을 체계적으로 관리하기 위해 ISO 26262 같은 표준에서는 초기 Concept 단계에서부터 꼼꼼한 Hazard 분석과 안전 요구사항 정리를 하도록 권고하고 있는 것입니다.

 

7. 맺으며

 ADAS/자율주행 기능의 안전 설계는 단순히 부품 신뢰도를 높이는 것을 넘어, 시스템 전체의 거동을 폭넓게 고려해야 하는 도전적인 작업입니다. 이번에 소개한 NHTSA의 2018년 보고서는 Lane Centering 시스템을 예로 들어, ISO 26262 기반의 기능 안전 프로세스를 현실적으로 적용하는 과정을 상세히 보여주었습니다. 특히 HAZOP, FMEA, STPA 등 여러 분석 기법을 통합하여 Hazard를 식별하고 안전 요구사항을 도출한 점, 그리고 운전자 행동이나 시스템 상호작용까지 포함한 넓은 시야의 안전 설계를 한 점은 많은 엔지니어들에게 시사하는 바가 큽니다.

 

 이 보고서가 제시한 Safety Goals (예: 차로 이탈 방지, 기능 돌발상실 방지 등)과 그로부터 파생된 다양한 요구사항들은, Lane Centering뿐만 아니라 다른 L2/L3 기능들을 설계할 때도 유용한 참고가 될 것입니다. 예를 들어 어댑티브 크루즈 컨트롤(ACC)이나 자동 비상제동(AEB)을 다룬다면 종방향 제어 관점의 Hazard로 치환될 뿐, 비슷한 개념의 Safety Goal과 FSR을 생각해볼 수 있습니다. 또한 Fail-Safe vs Fail-Op 아키텍처 결정, 운전자 모니터링의 중요성, 시스템 간 협조 등은 모든 자율주행 기능 개발에 공통적으로 적용되는 원리입니다.

 

 물론, 보고서의 내용이 정답은 아닙니다. 기능 안전은 차량의 구체적인 아키텍처나 개발 조직의 프로세스에 따라 다양한 접근이 가능하기 때문에, 본 사례를 참고하여 각자 시스템에 맞게 응용하는 것이 중요합니다. 예를 들어 이중화가 어려운 저가 차량 플랫폼이라면 ASIL D 대신 기능 제한과 운전자 경고로 대안을 삼을 수도 있고, 반대로 완전 자율주행을 지향한다면 여기서보다 더 고도화된 Fail-Operational 설계를 해야 할 수도 있습니다. 중요한 것은 어떤 경우든 체계적인 Hazard 분석과 안전 목표 수립 절차를 통해 논리적으로 안전성을 입증하는 것입니다.

 

 마지막으로, NHTSA 보고서처럼 테스트 시나리오까지 도출해 보는 것을 권장합니다. 안전 요구사항을 책에 쓰는 것에서 끝내지 말고, “이 요구사항을 검증하려면 어떤 상황을 테스트해야 하지?”를 고민해 보면 요구사항의 빈틈이나 구현상의 현실적 한계를 더 잘 알 수 있습니다. 예컨대 “운전자 미주시에도 4초간 차로 유지 지속” 같은 요구가 있다면, “4초 후엔 어떻게 될까?”, “그 4초 동안 여러 고장이 동시 발생하면?” 등의 시나리오를 떠올려 볼 수 있죠. 이런 사고 실험(thought experiment)이 거듭될수록 시스템의 안전 강건성은 높아질 것입니다.

 

 ADAS 및 자율주행을 개발하시는 엔지니어 분들이 이번 글을 통해 기능 안전 분석의 큰 그림을 그려보고, 실무에 적용할 수 있는 아이디어를 얻으셨길 바랍니다. 안전 설계는 다소 번거롭고 보수적인 작업처럼 느껴질 수 있지만, 결국 사용자의 생명과 직결되는 책임이기에 소홀히 할 수 없는 부분입니다. 앞으로도 끊임없이 진화하는 자동차 안전 분야에 대해 함께 고민하고 지식을 나누면서, "안전하면서도 똑똑한 차량"을 만들어 나갔으면 합니다.

 

(참고: 본 글에서는 “Functional Safety Assessment of an Automated Lane Centering System” (NHTSA, 2018) 보고서를 기반으로 내용을 구성하였습니다. 필요하신 분은 해당 원문 보고서를 참조하시길 추천드립니다)