기능안전은 개발에 얼마나 녹아들어 있는가? - From Safety Activity To Engineering Decision

1. 기능안전의 중요성은 크게 높아졌다.자동차 개발에서 "기능안전"이라는 단어가 지금처럼 자연스럽게 사용되기 시작한 것은 그리 오래된 일이 아닙니다. 10~20년 전만 하더라도 기능안전은 일부 안전 전문가나 특정 프로젝트에서 주로 다루는 전문 영역에 가까웠습니다. 그러다 보니 자연스럽게 개발자는 자신의 기능을 설계하고 구현하는 일이 중심이었고, 기능안전은 그 과정에서 필요한 경우 "별도로 검토하는 업무"로 인식되는 경우가 많았습니다.그런데 지금은 ISO 26262가 많이 보편화 되었고, 그에 따른 자동차 개발 프로세스도 어느정도 정착되었습니다. 그리고 자연스럽게 시스템 개발 전반에 녹아들어 시스템 개발의 일부 단계에만 머무르지 않습니다. 먼저 자동차 제조사에서는 Concept 단계에서 Hazard를 분석..

ISO 21448(SOTIF): 새로운 위험 시나리오는 어떻게 만들고 어디까지 상세화 해야 할까?

1. 위험 가설은 아직 시험 시나리오가 아니다어떤 시스템이 특정 조건에서 위험해질 수 있다는 생각(위험 가설)을 했다고 해서, 곧바로 시험을 시작할 수는 없습니다. 위험 가설은 어디까지나 “이런 상황에서 문제가 발생할 가능성이 있다”는 수준의 문제 제기 수준이므로, 실제 시험에서 필요한 "무엇을 변화시킬 것인지", "어떤 조건을 고정할 것인지", "무엇을 관찰할 것인지", 그리고" 어떤 결과를 위험의 징후로 판단할 것인지"가 더 구체적으로 더 정의되어야 합니다.예를 들어 “AEB가 보행자를 늦게 인식할 수 있다.”라는 위험 가설이 있다고 할 때, 이 문장은 충분히 중요한 안전 문제를 제기하고 있지만, 이 상태로는 시험 시나리오라고 보기 어렵습니다. 보행자를 늦게 인식한다는 현상이 어떤 조건에서 발생하는지..

이번 포스팅은 지난 포스팅에서 이어집니다.ISO 21448(SOTIF): 고장이 없는데도 위험하다면, 무엇을 더 분석해야 할까? ISO 21448(SOTIF): 고장이 없는데도 위험하다면, 무엇을 더 분석해야 할까?자동차의 기능안전은 오랫동안 ISO 26262를 중심으로 발전해 왔습니다. 자동차 개발 조직은 HARA(Hazard Analysis and Risk Assessment)를 통해 위험을 식별하고, 안전 목표와 안전 요구사항을 수립하며, FMEA와habana4.tistory.com지난 포스팅에서는 ISO 26262 기반 기능안전 체계에 SOTIF를 적용할 때, 차량 수준의 위험은 통합적으로 바라보되 고장과 기능적 불충분함이라는 발생 원인은 구분해서 분석해야 한다는 점을 살펴보았습니다.그런데 여기에..

자동차의 기능안전은 오랫동안 ISO 26262를 중심으로 발전해 왔습니다. 자동차 개발 조직은 HARA(Hazard Analysis and Risk Assessment)를 통해 위험을 식별하고, 안전 목표와 안전 요구사항을 수립하며, FMEA와 FTA 등을 활용하여 고장으로 인한 위험을 분석하고 있습니다. 또한 안전 메커니즘과 검증 체계를 통해 위험을 예방하거나 그 영향을 완화하고 있습니다.그런데 시스템의 모든 구성 요소가 정상적으로 동작하고, 소프트웨어가 설계된 대로 실행되고 있음에도 위험한 차량 행동이 발생한다면 어떻게 해야 할까요?예를 들어 AEB 시스템의 센서와 제어 소프트웨어가 정상적으로 동작하더라도 특정 환경, 즉 카메라가 도로의 역광으로 인해 정상적인 센싱을 수행하지 못해서 보행자를 충분히 ..

1. 기술적으로 좋은 아키텍처도 왜 현실에서는 쉽게 망가지는가소프트웨어 아키텍처를 설계할 때 우리는 주로 기술적인 구조에 집중해 왔습니다. 시스템을 적절한 컴포넌트로 분리하고, 각 컴포넌트의 책임을 명확하게 정의하며, 인터페이스를 단순하게 만들고, 결합도를 낮추는 것이 좋은 아키텍처를 만드는 중요한 방법이라고 배워왔습니다. 물론 이러한 원칙은 여전히 중요합니다.그런데 문제는 기술적으로 잘 설계된 구조가 반드시 현실에서도 잘 작동하고, 운영될 수 있는 것은 아니라는 점입니다. 잘 작성된 아키텍처 다이어그램을 보면, 시스템이 깔끔하게 잘 나뉘어져 있고, 각 컴포넌트에는 명확한 책임과 인터페이스가 잘 정의되어 있습니다. 하지만 막상 작은 기능 하나를 변경하려고 하는데에도, 다른 팀의 검토가 필요하고, 인터페이..

얼마 전 해외 협력업체를 방문해 소프트웨어 코드 리뷰를 진행할 기회가 있었습니다. 코드의 구조와 구현 방식을 살펴보고 테스트 결과를 확인하면서 이런저런 이야기를 나누던 중, 자연스럽게 Code Coverage에 대한 이야기가 나왔습니다. 소프트웨어를 개발하다 보면 Statement Coverage나 Branch Coverage를 측정하는 것은 당연한 업무 중 하나입니다. 테스트를 수행한 뒤 어느 코드가 실행되었는지, 각 분기의 True case와 False case가 충분히 수행되었는지를 확인하고, 이를 통해 테스트가 코드의 구조를 얼마나 충실하게 훑었는지를 판단하는 것은 ISO 26262에서도 반드시 수행을 권고하는 활동입니다. 그 중에서도 높은 ASIL을 갖는 제어기의 경우 소프트웨어 검증 시, MC..