기능안전의 기본개념

1. 기능안전의 도입 배경

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

 

2. 기능안전의 목적

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

 

3. 기능안전

 제품의 오작동을 방지하고 Parameter별 측정 불량방지를 위해 Hazard Analysis & Risk Assessment(HARA) 위험원 분석 및 리스크평가를 통해 안전목표를 세우고 안전목표별 Severity(S) 심각도, Exposure(E) 노출확률, Controllability(C) 제어가능성을 정의하여 차량 안전 무결성 등급을 결정한 후 기능안전 개발 협약서를 작성합니다. 시스템, 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하여 가까운 정비소를 방문할 수 있도록 도와 주는것이 바람직합니다. 

 

3-1. Development Interface Agreement(DIA) 기능안전 개발 협약서 작성

 전자제어기기 중 안전관련 항목으로 선정된 제품에 대하여 ISO26262기준으로 기능안전관리, 설계구상서 개발, 시스템/하드웨어/소프트웨어 설계 및 시험관련 열거된 항목들 중 ASIL등급에 따라 선정하여 협약을 진행하고 동일한 ASIL등급이더라도 제품의 특성에 따라 달라질 수 있습니다. 선정된 항목별 산출물은 RASI 형식에 따라 협력사가 작성하거나 고객사와 함께 작성하고(R), 고객사에 의해 승인(A)되고, 고객사에게 통보(I)해야한다. 산출물 개발에 지원을 수행하는 주체(S)의 역할은 좀더 확인해봐야할 사항입니다.

 

 

3-2. 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라고 부르기도 하니 참고합시다.

 

3-3. 설계구상서 개발 단계

 시스템구상 Concept을 정하고 설계요구사양서를 배포하며 위험원 분석 및 리스크평가 초안을 바탕으로 상세분석하여 안전목표를 재검증합니다.

 

3-4. 시스템 설계 및 시험

 기술안전 요구사항을 재검토하고 CMX&DBC에 적합한 시스템 및 아키텍쳐 디자인하고 해당내용을 설계사양서에 반영한다. 제품 기본성능을 Lab실에서 검증하여 지속적 개선하여 개발 Software를 Release한 후 Lab실 및 실차시험 및 프로젝트 차량에서 발생하는 추가적인 품질문제를 지속개선하여 시스템 안전성을 확보해간다. 개선시 필요하면 사양서도 함께 업데이트를 진행합시다. 진단 사양 구축시 제품의 오작동으로 인한 사고를 방지하기위해 경고 문구 표출 또는 기능 차단이 조건별 더 추가될 경우 ASIL 등급이 낮춰 질 수 있으니 참조하도록 합시다. 단품 Full Function 검증시 HALT 장비를 사용하면 장비가 자동으로 검증을 해주기 때문에 검증시간이 줄어들수 있으니 참고하도록 합시다.

* Can Matrix(CMX) : Can통신 신호별 송출 제어기, ID 주소, 신호 이름, 송출유형, 송출시간, 수신 제어기 등을 Table표로 한눈에 볼 수 있게 구성한 매트릭스. P-CAN, B-CAN, C-CAN, D-CAN, M-CAN, I-CAN등 CAN 토폴로지에 구성되어 있는 각각 CAN망별로 구성된 Table표

* Data Base Comunication(DBC) : CMX를 기준으로 제어기가 정상 신호를 표출하기 위해 작성하는 Database(DB)로써 기본적으로 신호 송출 제어기와 수신 제어기의 DB형태가 동일해야 정상 신호 송수신이 가능합니다. DB형태가 다르면 미동작 또는 오동작할 수 있으니 참고하도록 합시다. 사양협의 내용 또한 반영해서 배포되어야 합니다. Data Length가 다르면 송출 제어기와 수신 제어기의 DB형태가 서로 다르기 때문에 수신 제어기가 해당 신호를 읽고 반응할 수 없기 때문에 Data Length변경 유/무 또한 사전에 확인하도록 합시다. 

 

3-5. 하드웨어 개발 및 시험

 차량용 반도체 사용 및 고객사에서 제공하는 Standard에 따라 PCB 제작하며 EMC, 암전류, 기능/성능을 만족하기 위해 하드웨어통합테스트를 진행합니다. 전원단 및 능동소자의 입/출력단의 전압, 전류를 중요하게 검증하고 입력값이 소자의 용량을 초과하지 않는지 또는 회로 디자인시 Inrush(과도전압 or 과도전류) 인가시 취약하지 않은지 함께 검증하도록 합시다. Legacy 제품대비 Pin 맵 변경 또는 회로 변경이 있을경우 설계사양서의 하드웨어 중 해당항목도 업데이트 해야합니다. 

ASIL등급이 C 또는 D의 경우, Hardware Architectural Metrics(HAM) 하드웨어 아키텍쳐 메트릭스를 ASIL등급에 맞게 단일점 결함 메트릭과 잠재 결함 메트릭을 검증해야하고, Probabilistic Metric for random Hardware Failure(PMHF) 우발적 하드웨어 고장에 대한 확률 메트릭스는 ASIL등급에 맞게 하드웨어 우발고장 목표 값을 검증해야합니다.

 

HAM

PMHF

3-6. 소프트웨어 개발 및 시험

 시스템 설계 및 시험에서 구축한 요구사항분석, 시스템 디자인, 아키텍쳐 디자인을 바탕으로 모듈을 디자인하고 Software(SW)를 설계한 후 1차 구현합니다. SW 단위 테스트, 기능별 통합 테스트를 거쳐 설계시 의도한 출력이 나오는지 Timing의 오차는 없는지, 간헐적을 포함하여 기능이 오작동 또는 미작동 유무를 검증, 저전압시 쓰레기값 표출 유무 검증합니다.

Real 값과 측정 값의 괴리감을 줄이기 위해 Main loop진입전 불러온 Data들은 초기값을 0으로 리셋을 하고 진행하는게 쓰레기값 표출 Risk를 줄일수 있으니 참고합시다. 시스템을 구성하는 실제품들이 포함된 시스템을 Bench로 구축하여 제품이 시스템에 적용되었을때 상대 전자제어기기와 통신시 또는 하드웨어 입력을 받을 시 기능별 통합 테스트한 방식과 동일하게 진행하여 시스템 측면 테스트를 시스템 담당자와 진행하기도 하고 별도로 확인해 보기도 합니다. Timing 차이 발생하는 경우 보정값을 적용하기도 하고 일정구간 신호를 무시해야 하는경우 상황에 따라 chattering time 또는 Delay time을 적용하기도 합니다. 필요시 코드의 Refactoring이 진행되기도 하지만 Major 기능의 오류 또는 기능 구현을 위해 어쩔수 없이 진행필요한 경우가 아니라면 대부분 기존 코드에서만 수정이 진행되니 참조합시다. 자동차산업이 보수적인 성향이 강해서 그런것 같습니다.