기능안전(Functional Safety) 67

Code of Practice for the Design and Evaluation of ADAS

요즘 차량 레벨에서 수행하는 Concept phase, HARA 등에 대해서 고민할 일이 좀 있어서 찾아보다가 표제와 관련하여 자료를 찾게 되었습니다. 오래전에 발행되고 현재까지도 유용하고 유명한 자료라고 들었습니다. 아직 읽어보지는 않았지만, 우선 공유해봅니다. 아래 링크를 타고 들어가시거나, 구글에서 표제로 검색해보아도 쉽게 다운로드 가능하니 참고하시기 바랍니다. Code of Practice for the Design and Evaluation of ADAS https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjZsqCvsOL9AhXBbt4KHV7dBNoQFnoECAwQAQ&url=https%3A%2F%2Fwww.ace..

Functional Safety Development of Motor Control Unit for Electric Vehicles

2019 IEEE Transportation Electrification Conference (ITEC-India) https://ieeexplore.ieee.org/document/9080863 Functional Safety Development of Motor Control Unit for Electric Vehicles Due to robust framework from Government, many environmental and socio-economic benefits and fun to drive aspect, auto industry is transitioning from fuel powered vehicles to electric vehicles. Functional safety is ..

Functional Safety Terminology Landscape

FSSC 에서 발행한 표제의 제목(Functional Safety Terminology Landscape)의 페이퍼와 관련하여 아래와 같이 소개합니다. https://standards.ieee.org/ieee-whitepaper/the-functional-safety-terminology-landscape/ The Functional Safety Terminology Landscape This white paper, developed by the Functional Safety Standards Committee (FSSC), describes the landscape of functional safety terminology as used across multiple domains. It has bee..

AP: Action Priority

AIAG-VDA 가이드북을 읽다보니, RPN (Risk Priority Number) 외 AP (Action Priority) 를 통한 정의가 보이네요. 왜 포함된거지? 목적이 뭐지? 어떤 배경으로 생겨난 거지? 궁금해서 찾아보니 아래 그림으로 확실하게 이해가 되네요. 그림을 보시면 Scenario A와 Scenario B 모두 RPN 80으로 동일합니다. 우선순위와 중요도에 따라 업무(Task)를 배정하는데, 위 2 개의 Scenario는 동일하게 보아야 할까요? RPN으로만 구분한다면 그럴 수 있겠지만, 설명되어 있듯이 RPN만으로는 이러한 충분하지 못한 부분이 있음을 말하고 있습니다. Severity가 높은 시나리오부터 접근하여 분석하는 것이 필요할 것입니다. 이러한 부분을 위해서 Action Pr..

FHTI: Fault Handling Time Interval

FMEA 가이드 북을 읽다가 재미난 부분을 알게 되어서 짧게 글을 써봅니다. 몇 년전에 발표된 AIAG-VDA FMEA 가이드북에서도 글 제목과 같이 FHTI가 언급되어 있더라고요. 아래 그림을 보시면 Fault Handling Time Interval, FHTI의 정의가, Fault로부터 Failure가 발생되고, Hazardous event가 발현되는 시점까지로 정의되어 있습니다. 반면에 ISO 26262 part 1에서는 Safe state로 천이하는 시간까지를 의미합니다. ISO 26262 part 1에서, Hazardous event까지는 아래 그림과 같이 FTTI, Fault Tolerance Time Interval 로 정의되어 있습니다. 좀더 AIAG-VDA 가이드북을 읽다보니 아래와 같이..

Confirmation review checklist for Safety Plan

체크리스트를 활용한 산출물 리뷰를 하고 있습니다. 이러한 방법은 검토(리뷰)에 있어서 기준을 제공하는 기본적이지만 파워풀한 방법입니다. (개인적으로 실무에서 잘 활용하지 않는 상황이 잘못 된거라고 생각합니다.) 지금부터는 사용하고 있는 체크리스트에서 일부 참고하실 수 있는 내용들을 기록해보겠습니다. 1. Safety activities는 적절하게 식별하였는가? 예시) Impact analysis를 참고하였는지? 누락되거나 과소/과대하게 조정된 부분이 있는지 예시) 각 활동에 선/후 및 연관된 활동들을 고려하였는지 예시) Safety analysis, Functional safety audit, assessment 예시) 테일러링 된 부분들은 포함되었는지 2. Safety Manager(s)가 Safety..

Impact Analysis

Impact analysis, 영향성 분석, 영향 분석에 대해서 간단히 글을 써봅니다. ISO 26262에서는 Impact analysis를 하는 목적은 결국 Item을 수정(modification)하는지를 파악하고, 현존/개발 완료된 기존의 Element(System, HW, SW)를 re-use할 수 있는지 식별하는 것입니다. 조금 다른 시각에서 본다면, 실무를 할 때 이전 Element를 왜 re-use 했는지 근거/Rationale로 Impact analysis가 될 수 있습니다. 이러한 Impact analysis의 목표(Goal)를 아래와 같이 좀 더 상세히 정리하면, (정확한 의미 전달을 위해 ISO 26262 표준에서 사용되는 용어를 활용하여 영어로 기재합니다) •To identify re..

Relationship between ISO 26262 and others

ISO 26262, Functional Safety 또는 기능안전 여러 이름으로 각 전장을 다루는 회사에서 어려움의 대상으로 불리고 있는 기능안전... 왜 일까요? 경험에 따라 주장하는 생각에 따라서 다른 답을 할 수 있겠습니다. 저는 우리가 아직 친숙하지 않아서라고 생각합니다. V-cycle 모델은 이미 몇 십년전부터 산업에서 언급되었습니다. 또한 Agile 이라든지 다른 라이프사이클 모델을 가지고 개발에 녹여서 적용하려고 하고 있습니다만, 이 또한 Full set으로 적용하기에는 아직도 익숙해지지 않기 때문에 우리는 여러번, 반복적으로 유사한 비슷한 일들을 시도하고 있는 건 아닐까 생각합니다. 다시 기능안전으로 돌아가서, 그러면 기능안전, Functional Safety, ISO 26262가 너무 범..

GSN: Goal Structuring Notation

지나가듯이 검색해보았더니 관련해서 좋은 자료를 찾았네요. 전체 자료를 확인하기 위해서는 결국 유료회원이 되어야 하나, 일부 자료들은 무료로도 확인이 가능합니다. 제법 양질의 자료인 것으로 생각되어, 관심 있으신 분들께서 참고하시면 좋을 것 같아서 공유 드립니다. Goal Structuring Notation Goal Structuring Notation The latest version of the Goal Structuring Notation (GSN) standard (version 2) is now available. This Standard has two intended functions. Firstly, it seeks to provide a comprehensive, authoritative ..

Safety Requirements Review & Checklist

Requirement는 개발의 시작이고, 여러 단계를 수행하면서도 계속 엮여있는 output 입니다. 그래서 New development에 대해서 한번에 complete한 output을 만드는 것은 아주 어렵고 극히 드문 경우라고 생각합니다. 물론 제품의 개발 규모, 요구사항의 복잡성 등을 고려해보면 차이가 있겠지만, 그렇다고 해도 어려운 일입니다. 개인적인 경험에서 말씀 드리면, Requirement는 최초 작성할 경우에는 Inspection과 같은 Formal verification method를 적용하는 것이 바람직하다고 생각합니다. 여러 이해관계자들이 신중하고 충분하게 시간을 가지고서 검토해야 하기 때문입니다. 이후 변경되는 범위, 중요도에 따라 Walkthrough, Peer-review, te..