이 글은 포트폴리오 목적이며 별도의 수익창출을 하지 않습니다.
이 글의 이미지는 출처를 고려하지 않고, 가져왔습니다. 문제가될 시 삭제합니다.
자동차 업계에서 기능안전은
ISO26262 표준을 준수한다는 것과 같습니다.
회사에 ISO26262 프로세스가 구축되어 있다면, 접근하기 쉬우나
그렇지 않다면, 인터넷에 자료는 입문하기에는 상당히 불친절합니다.
Aspice 표준은 인터넷에서 쉽게 원문을 구할 수 있는 반면,
ISO26262는 돈을 주고 원문을 사야합니다.
그럼으로 인터넷에 있는 최대한의 정보를 활용하여 내용을 설명하고자합니다.
추가적으로..
기능안전 ISO26262를 이해하겠다고, 원문을 본다거나 인터넷 정보를 찾는다거나하는
취준생이나, 저같은 기능안전 초보자분들이 계실거라 생각되는데요
취준생이라면, 개요정도만 알면되고, 저와같은 현직 초심자들은
사내에 구축된 기능안전 지침서나 프로세스를 참고하고
이도 없다면, 컨설팅을 받는 것이 정말 좋습니다.
들어가기전..
자동차업계에 경력이 전혀 없는데, 기능안전, 프로세스 쪽으로 직무를 결정한 분들이 있다면..
기능안전을 먼저 공부한다는 것은 순서가 맞지 않습니다.
시스템, 소프트웨어쪽으로 1~3년 이상 경험한 이후 Aspice나 기능안전 프로세스를 이해하는 것이 최고의 학습방법이라고 생각됩니다.
아래의 조건을 만족한다면 기능안전 공부를 시작하십쇼..
"나는 자동차 분야 전장품의 개발 프로세스를 어느정도 이해하고 있으며, 이를 설명할 수 있다"
기능안전 개요
우리가 자동차 전장품의 소프트웨어를 설계하는 회사에 취업을 했다면, 개발 진행에 있어서 Aspice 표준과 기능안전(ISO26262)표준을 준수하여야합니다.
그래서 대부분의 회사는 Aspice와 기능안전을 통합해서 자체 개발 프로세스를 구축하고 있습니다.
(그렇기에 Aspice 표준과 그에대한 산출물을 이해하지 못했다면 Aspice를 먼저 공부하는 것을 추천합니다.)
아래는 Apsice의 표준을 나타내는 그림입니다.
자동차 전장품은 V model에 따라
시스템 설계 -> 소프트웨어개발 -> 소프트웨어 검증 -> 시스템 검증의 순서로 개발이 진행됩니다.
ISO26262에서도 동일하게 전장품 개발에대한 내용을 Chapter 별로 구분해서 정리를 해놓았습니다.
Apsice랑 놓고보면 크게 다를게 없습니다.
그림을 보는 방법은 숫자순서대로 따라가면서 확인을 하면됩니다.
1. Vocabulary : 용어에 대한 설명입니다.
2. Magagement of Functional Safety : 기능안전 반영을 위한 관리를 어떻게 할것인지에 대한 부분입니다.
3. Concept Phase : 컨셉단계로 우리가 만드는 제품의 기능안전적인 컨셉을 정의합니다.
4. Product development at the System Level : Aspice의 System 개발과 같은 컨셉입니다. 기능안전 컨셉을 시스템에 반영하는 내용입니다.
5. Product development at the hardware Level : 하드웨어 개발 과정에서 기능안전을 반영하는 내용입니다.
6. Product development at the Software Level : 소프트웨어 개발 과정에서 기능안전을 반영하는 내용입니다.
7. Production operation service and decommissioning : 제품을 개발하고 양산(생산)하는 단계에서 적용해야하는 기능안전 내용입니다.
8. Supporting process : Aspice의 SUP에서 형상관리, 변경관리정도가 여기에 해당됩니다.
9. Automotive safety integrity level (ASIL) oriented and safety oriented and safety-oriented analyes : 자동차 안전 무결성 수준(ASIL) 지향 및 안전 지향 및 안전 지향 분석 부분인데, 이부분은 조금더 공부를 하고 작성을 하도록 하죠..
10, 11는 필요하면 찾아보면될 것이고, 12는 오토바이에대한 기능안전 내용입니다.
OEM과 협력사에따라 업무의 범위가 다르기 때문에 알아야할 Chapter가 서로 다릅니다.
(어떻게 다른지는 공개하긴 어려울 것 같군요 다만 전장품 개발 프로세스를 이해한다면 대충 보이실 겁니다.)
그러면 각 쳅터별로 내용을 살펴봅시다.
그리고 한가지 예시를 들어서 접근을 하도록 합시다.
예시) 초음파센서에 반응하는 자동문
자동차쪽으로 하면 뭔가 예시를 들기가 무서워집니다. 그래서 이전 Aspice에서도 설명했던 자동문으로 설명을 해보고자합니다.
제가 생각하는 초음파센서에 반응하는 자동문의 기능은 아래와 같습니다.
1: 초음파 센서를 통해 물체를 감지하면, 문을 움직여야한다.
2: 문은 사람의 움직임에만 반응해야한다.
3: 사람이 문에 끼이면, 다시 열려야한다.2. Management of functional safety
전체적인 기능안전 관리 체계를 수립하는 부분입니다.
ISO26262에서 요구하는 내용, 활동들이 있을 것입니다. 이 내용들이 빠짐없이 들어가야하고, 그에 대한 활동을 해야합니다.
ISO26262 원문을 확인할 수 없는 지금입장에서는 Aspice의 MAN.3와 유사한 활동이라고 생각하시면됩니다.
3. Concept Phase
컨셉단계입니다. 우리가 만드는 초음파센서 자동문에서의 아이템이라고 한다면 아래의 기능을 생각해볼 수 있습니다.
ITEM1 : 사람이 오면 문을 열고 닫는다.
그러면 위험원 분석 (HARA : Hazard Analysis and Risk Assessment) 를 진행합니다.
사람이 오면 문을 열고 닫는다. 라는 기능을 생각했을 때, 가장 먼저 떠오르는 위험은 극단적으로
신체끼임, 절단이라고 볼 수 있습니다.
그러면 아래의 이미지처럼 심각도, 노출도, 제어가능성등을 판단하여 ASIL 등급을 결정합니다.
Automotive Safety Integrity Level - Wikipedia
Automotive Safety Integrity Level - Wikipedia
From Wikipedia, the free encyclopedia Risk assessment standard Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety for Road Vehicles standard. This is an adaptation of the Safety Integrity L
en.wikipedia.org
ASIL 등급에 따라서 QM, A, B, C, D 로 나타내며, 알파벳이 뒤로갈수록 심각하다고 보면됩니다.
그리고 QM 단계라면 별도의 ISO26262활동이 필요하지는 않습니다. (권장)
자동차 전장품 입장에서 ASIL등급은 그냥 정말 간단하게 생각해서 아래와 같이 생각하면됩니다.
저는 그냥 이렇게 생각합니다.
ASIL D : 기능고장으로 내가 손도 못쓰고 죽을 수도 있다. (브레이크)
ASIL C : 기능고장으로 내가 죽을 수도 있다.
ASIL A B : 기능고장으로 내가 다칠 수도 있다. (헤드라이트, 브레이크라이트 등)
QM : 사용자의 부주의가 아닌 이상 다칠 일은 없다.
그러면 자동문의 경우 그냥 간단하게 ASIL B라고 생각해봅시다.
Functional Safety Concept ( FSC)
기능안전컨셉이라고도 부르고, 용어에 따라서는 Functional Safety Requirement (FSR)이라고도 부릅니다. 우리가 아이템으로 정의했던 내용은 이제 Safety Goal이됩니다.
ITEM1 : 사람이 오면 문을 열고 닫는다.
Safety Goal : 신체끼임 및 절단을 방지해야한다.그러면 Safety Goal을 지키기 위한 FSR을 생각해볼 수 있을 것입니다.
초음파센서 자동문은 정말 간단하게 아래와 같이 구성되어 있다고 생각해봅시다.
신체가 절단되는 상황은 주로 문이 닫히는 상황에서 발생할 것입니다.
- 모터가 고장이나서, 원치않은 상황에서 닫히는 동작을 한다면 고장이될겁니다.
- 초음파센서가 고장나면, 원치않은 상황에서 사람이 없다는 판단을 하고 문이 닫힐 수도 있습니다.
그러면 컨셉단계에서는 두가지의 FSR이 만들어졌습니다.
ITEM1 : 사람이 오면 문을 열고 닫는다.
Safety Goal : 신체끼임 및 절단을 방지해야한다.
FSR1 : 초음파센서의 고장을 감지해야한다.
FSR2 : 모터의 고장을 감지해야한다.
근데, 고장을 감지만 하는 것만 정의를 했습니다. FSR에는 고장을 감지하는 것 외에도, 어떻게 반응할 것인지도 정의를 해야합니다.
두가지를 생각할 수 있죠. 모터를 정지해서 멈추거나, 모터를 열거나
근데, 다들 한번쯤은 자동문에 끼여보신적이 있으실거 같고, 대부분 문을 열어줬었습니다. 그러니까 문을 여는거로 합시다.
(기능안전의 프로세스 설명을 위해 이렇게 적지만 실제로는 안이렇습니다.)
또, 하나가 더 있습니다. 닫히는 와중에 끼었어.. 근데, MCU에서 반응하는 시간이 막 1분 5분이러면
정말 위험할 겁니다. 그래서 FTTI 라는 용어가 등장하는데 Fault Reaction Time Interval 고장발생으로부터 반응하는 시간입니다.
그러면 편하게 1초안에 문을 열어라 라고 볼수 있죠. 그러면 우리의 FSR은 아래와 같이 완성됩니다.
ITEM1 : 사람이 오면 문을 열고 닫는다.
Safety Goal : 신체끼임 및 절단을 방지해야한다.
FSR1 : 초음파센서의 고장을 감지해야한다. 감지시 문을 1초안에 열어야 한다.
FSR2 : 모터의 고장을 감지해야한다. 감지시 문을 1초안에 열어야 한다.
4. Product development at the System Level
시스템 단계에서의 활동은 Aspice의 표준에 따라 시스템 요구사양서를 구현하는 것에서 시작합니다.
그러면 기능에대한 정의가 완료되는 시점이 있을 것입니다.
엔지니어가 어느정도 기능에대한 설계도 완료하였고, 기능안전의 컨셉도 이해하였다면 가장 중요한 단계는 안전분석입니다.
자동차 전장품을 처음 접하는 분은 도대체 시스템 개발이 뭐냐..? 라고 생각하실 수 있습니다.
간단하게 하드웨어와 소프트웨어가 잘 만들 수 있게 가장 윗단에서 설계의 방향성을 제시하는 담당이라고 생각하시면됩니다.
보통 시스템의 정의에 따라 입력과 출력을 기반으로 전장품을 설계합니다.
다시 안전분석으로 돌아와서
ITEM1 : 사람이 오면 문을 열고 닫는다.
Safety Goal : 신체끼임 및 절단을 방지해야한다.
FSR1 : 초음파센서의 고장을 감지해야한다. 감지시 문을 1초안에 열어야 한다.
FSR2 : 모터의 고장을 감지해야한다. 감지시 문을 1초안에 열어야 한다.FSR을 들고와서 시스템 개발자는 안전분석작업을 진행해야합니다.
첫번째는 FMEA(Failure Mode and Effect Analysis) 입니다. 고장 모드 및 영향 분석이라고 하는 활동입니다.
아래 페이지에 따르면 총 7단계의 Step으로 구성됩니다.
AIAG VDA FMEA 7단계 접근법_ 1 SHEET 요약본
AIAG VDA FMEA 7단계 접근법_ 1 SHEET 요약본
AIAG VDA FMEA 7단계 접근법을 한장으로 요약한 것이니 참고하세요.
www.u-mac.co.kr
기획준비 -> 구조분석 -> 기능분석 -> 고장분석 -> 리스크분석 -> 최적화 -> 결과 문서화
이런느낌으로 구조를 분석해나가고, 이에 대한 기능을 정리해갑니다.
이에 대해서 고장을 분석합니다.
그러면 이 고장을 3가지 관점에서 접근합니다. 심각도, 검출도, 발생도 말 그대로 얼마나 심각하고, 테스트로 검출할 수 있는지, 얼마나 발생하는지 등을 체크합니다.
판단 기준은 RPN 혹은 AP 등의 방법을 사용하며 RISK를 평가합니다.
HIGH, Middle, Low로 결과가 나오게되면, HIGH를 LOW로 낮추기 위한 활동을 하게됩니다.
모터의 고장을 방지하기 위해서 모터에 어떤 조치를 취했어, 그랬더니 검출도가 높아지고, 발생도가 낮아졌어 그래서 LOW로 바꿀 수 있었어
그러면 어떤 조치는 시스템의 TSR (Technical Safety Requirement) (기술안전요구사항)이 됩니다.
이 외에도 FTA (고장트리분석), DFA(의존고장분석) 등을 진행하면서 TSR을 찾고, 안전수준을 달성합니다.
듣기로는, 자동문으로 누군가 신체가 절단되는 사건이 있었다고 한다면, 법원측에 FMEA 자료를 제출해야한다고 합니다. 그정도로 중요한 활동입니다.
여기까지 구현이 되었다고 한다면, 기능안전에서 요구하는 검증은 무엇이 있을까요
ASIL 등급을 나누는 이유는 등급에 따라 다른 요구를 하기 때문입니다.
ASIL 정의/의미 올바로 이해하기, ASIL A와 ASIL C는 어떻게 다른가?
ASIL 정의/의미 올바로 이해하기, ASIL A와 ASIL C는 어떻게 다른가?
The GSEG (Global Safety Experts Group)입니다. The GESG에서는 개발 프로젝트에 몸 담고 계신 분들의 문의를 접수해 본 결과 (특히 아시아권), ASIL의 정의 및 의미를 정확히 이해하지 못하고 계신 분들이 많
iso26262engineering.tistory.com
ASIL A라면 몇몇가지 활동들이 면제가 됩니다. ASIL D라면 빡센 활동들을 진행하여야합니다.
ASIL 등급에 따라 프로세스/지원/설계/검증을 진행하는 방식이 다릅니다. 이에 대한 차이는 원문을 찾아봐야하는데..
인터넷에 검색하니 검색이 안되는거보면.. 그냥 다르다 정도로만 넘어갑시다.
4. Product development at the hardware Level
5. Product development at the Software Level
사실 가장 중요한 내용은 시스템입니다. 시스템에서 TSR을 잘 정의해주어야하기 때문이죠.
시스템에서 TSR의 정의가 완료되었다면, Hardware에서는 Hardware Safety Requirement (HSR)로 세부 구현을 진행하며, 소프트웨어는 Software Safety Requirement (SSR)로 세부 구현을 진행합니다.
그리고 이에 대한 테스트까지 진행하게되죠.. 제가 아는 내용은 여기까지입니다. 그리고 ISO26262 에서는 앞에서도 언급했지만, 어떤식으로 설계를 해야하는지 어떤식으로 검증을 진행해야하는지에 대한 내용이 적혀 있습니다.
다만, 원문이 유료로 배포되기 때문에 찾지 못했습니다.
향후에 시간이된다면, 상세하게 들어가보도록 합시다.
7. Production operating service and decommissining
잘 모릅니다. 제가 듣기로는
설계이후의 안전대책을 세우는 단계로 알고 있습니다.
설계 내용은 아니라 별로 재미는 없어서 따로 안봤습니다.
8. Supporting Process
관리에 대한 내용입니다. 위의 내용들이 기능안전 요구사항을 잘 반영함에 초점을 맞추었다면 여기는 기능안전의 개발프로세스 를 잘 준수하고 있는지
개발에 있어서 기능안전적으로 문제가 발생할 우려는 없는지를 확인하거나, 수행하는 단계입니다.
세부내용을 하나씩 보는게 낫다고 봅니다.
8-5 : Interface within distributed developments : 협력 개발에 대한 내용입니다.
8-6 : Specification and management of safety requirements : 안전요구사항을 관리하는 내용입니다.
8-7 Configuration Management : ISO26262에서 요구하는 형상관리에 대한 내용입니다. (Aspice와 겹칩니다.)
8-8 Change Management : ISO26262에서 요구하는 변경관리에 대한 내용입니다. (Aspice와 겹칩니다.)
8-9 Verification : ISO26262에서 요구하는 검증 기준입니다.
8-10 Documentation Management : 문서화관리에 대한 내용입니다.
8-11 Confidence In the Use of Software Tools (Software Tool Quailification) : 프로젝트에 사용되는 Software Tool을 파악하고 Tool의 안전성을 입증해야하는 내용입니다.
8-12 Qualification of Software Component : Software 컴포넌트에 대한 안전성을 입증해야하는 내용입니다. (컴포넌트는 어떤 기능으로 분리/개발한 소프트웨어의 단위라고 보면됩니다)
8-13 Evaluation of hardware element : 하드웨어 엘리먼트 평가인데 잘모르겠습니다.
8-14 Proven in use argument : 사용으로 입증된 안전성이라고 합니다.
8-15 Interfacing an application that is out of scope ISO26262 , 8-16 Integration of Safety-Releated Systems not developed according to ISO26262 : 처음봅니다. 잘 모르겠습니다.
그 외..
표준에는 나와있는지 모르겠습니다만, 아마 Chapter 2의 Management에 내용이 있을 수 있습니다.
각 활동에 대한 주요 키워드를 드릴테니 구글에서 검색을 하시길 바랍니다.
1. Confirmation 활동 : 각 단계에서 산출물이 요구된 안전기준을 충족하는지 확인
2. Safety Audit/Assessment 활동 : 기능안전 심사/평가에 대한 확인입니다.
3. Safety Case : 우리의 제품이 기능안전을 만족한다. 안전하다는 것을 증명하는 보고서입니다.