[ASPICE] 기능 안전 도입 배경과 목적 및 기본 개념

1. 기능 안전의 도입 배경

자율주행 기술구현과 친환경자동차를 위해 차량에 탑재되는 전자제어기기 수 증가와 시스템이 점점 복잡해지면서 안전관련 인식이 점차 증가하고 있는 추세이다. "시스템 오동작으로 인한 사고 방지"가 주요 Issue로 부각되었고, 자동차 기능안전 국제 표준인 ISO 26262가 제정되었다.

 

2. 기능안전의 목적

안전목표별 Automotive Safety Integrity Level(ASIL) 차량 안전 무결성 등급을 A, B, C, D으로 구분하여 제품 자체 ASIL등급은 최고등급을 적용한다. Development Interface Agreement(DIA) 기능안전 개발 협약서를 작성하고 시스템, H/W, S/W 측면 검증하여 등급에 해당되는 요구사항들을 검증하여 제품이 포함된 시스템 오동작으로 인한 사고를 방지하기 위함이 주된 목적이다. 

 

3. 기능 안전

제품의 오작동을 방지하고 파라미터별 측정 불량방지를 위해 Hazard Analysis & Risk Assessment(HARA) 위험원 분석 및 리스크평가를 통해 안전목표를 세우고 안전목표별 Severity(S), Occurrence(O), Detection(D) 을 정의하여 차량 안전 무결성 등급을 결정한 후 기능안전 개발 협약서를 작성한다. 시스템, H/W, S/W측면 개발 및 시험을 실시하여 산출물을 RASI 형식의 업무 R&R에 의해 진행한다. ASIL의 모든 등급에서 H/W측면 개발 및 유효성 확인을 위한 세분화된 Risk Management 활동을 하고 ASIL등급이 C 또는 D의 경우, 하드웨어 아키텍쳐 메트릭스와 우발적 하드웨어 고장에 대한 확률 메트릭스 검증을 추가한다. ASIL의 모든 등급에서 S/W측면 개발 및 유효성확인을 위한 V-model을 통해 세분화된 Risk Management 활동을 실시해야 한다. 정확한 ASIL 등급별 제품의 무결성뿐만 아니라 H/W의 매칭을 통해 S/W구현시 출력이 나오는 Timing 검증도 중요하다. Datasheet상 A와 B Micom들이 동일한 SPEC의 Real Time Counter(RTC)를 사용하더라도 실제 출력이 발생하는 Timing은 차이가 날 수 있기 때문이다.

현재 기능안전은 법규 규제 항목이 아니기 때문에 제품마다 기능안전을 실행하는 로직이 모두 다른 실정이다. 기능안전 동작 로직은 협력사와 고객사의 설계부문에서 양사가 합의한 사양협의 내용을 기준으로 진행되게 되며, 고객이 제품 자체 기능 불량(화면 블랙아웃)으로 느끼지 않고 경고등 표출 또는 Warning 팝업 메세지를 Display하여 가까운 정비소를 방문할 수 있도록 도와 주는 것이 바람직하다. 

 

 

* Functional Safety Management (FSM) 

거래하려는 협력사가 기능안전 수행이 가능한 수준인지 확인하는 단계로 생각하자. 협력사가 보유한 안전계획서 및 기능안전 평가 보고서를 통해 협력사 수준을 예상하고 위험원 분석 및 리스크평가 초안을 작성하여 안전목표를 도출한다.  안전목표 달성을 위한 각 요구사항들(FSR, TSR, FTTI, EOTI)을 양사가 협의한다. 각 요구사항들을 달성하기 위해 제품 안전 수명 주기를 포함한 안전 기능들을 검증 할수 있도록 Safety Case 안전 케이스 초안을 도출한다.

 

* Functional Safety Requirement (FSR)

기능안전 요구사항으로 기능안전을 만족하기 위해 고객사에서 협력사로 보내는 최소한의 요구사항

 

 

* Technical Safety Requirement (TSR)

기술안전 요구사항으로 각 기능안전 요구사항을 만족하기 위해 협력사에서 구상하는 상세한 기술적 요구사항

 

 

* Fault Tolerant Time Interval (FTTI)

결함 발생으로 인해 위험상황이 발생하는 데까지 걸리는 시간 간격으로 각 기능별 FTTI를 예측하여 진단시간 간격 및 경고등 표출 또는 기능 차단과 같은 후속조치 시간을 반영하여 위험상황이 발생하지 않도록 도와주는 지표. FDT와 FRT로 구분되어진다. 보통 진단 Table에는 FDT가 명시되어 있으며 FRT는 기능들의 Reaction 시간이 비슷하기 때문에 경고등 표출 시간/Relay 차단등 기능 차단 시간을 확인하여 FDT에 추가하면 FTTI가 된다. 

 

 

* Fault Detection Time (FDT)

결함을 판단하는 진단시간 간격

 

 

* Fault Reaction Time (FRT)

경고등 표출 또는 기능 차단과 같은 후속조치 시간

 

 

* Emergency Operation Time Interval (EOTI)

결함 발생 시점부터 안전상태 진입시점까지의 시간 간격으로 FTTI의 우려로 경고등 표출 및 기능 차단을 하더라도 일정 시간 후 정상신호가 지속적으로 진단되는경우 정상 기능을 회복하도록 설정하는 지표.

 

 

* Safety Case 

안전 케이스로 기능안전관련 요구사항들을 만족하기 위해 안전기능을 추가하고 제품 안전 수명 주기를 고려하여 검증할 수 있는 항목들을 도출한 서류. 기술안전 요구사항, 하드웨어 요구사항, 소프트웨어 요구사항이 반영된 항목들이 추가되고 Only 제품개발측면(공정개발제외) 프로젝트 시작부터 SOP후 보증기간 종료까지 단계별 검증할 수 있는 Requirement Traceability Matrix(RTM) 요구사항 추적성 매트릭스가 첨부되면 좋다. 요구사항 추적성 매트릭스의 경우 Coverage Metrics 라고 부르기도 한다.

 

 

이 글을 마치며...

 

ISO26262는 더 이상 선택의 문제가 아닌 필수라는 생각이 든다.
인증을 받아 그 규격을 준수했다는 것을 증명하는 것이 아니라 기업의 안전 관련 부품에 대한 개발에 있어 안전 문화(Safety Culture)를 구축해야 하는 취지에서다. 많은 개발 기술과 기업 경영의 관점을 포함하는 개발 문화를 바꾸는 것을 의미하며 이것은 한순간에 되는 것이 아니며 꾸준한 노력이 요구되고 많은 시간이 요구되는 과정으로 보아야 할 것이다. 특히, ISO26262를 주도하는 것은 OEM만이 가능하다고 할 정도로 완성차의 역할이 중요하다.

또한 기능안전의 도입이 어려운 중소기업에 대한 지원시스템으로 기능안전 수행 전문가를 위한 교육과정과 연구개발 인프라 및 솔루션 및 시험검증 인프라 및 솔루션에 대한 체계적인 지원이 가능하도록 정부의 현실적인 정책 마련과 지원이 절실히 요구된다.