ISO 22448(SOTIF): 알려지지 않은 위험은 어떻게 발견할 수 있을까?

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

ISO 21448(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..

소프트웨어 아키텍처를 설명하기 위해서는 주로 비지오나 파워포인트를 이용하여 다이어그램을 그린 적이 있습니다. 처음에는 나름 잘 정리했다고 생각했고, 시스템을 구성하는 주요 소프트웨어를 박스로 나누고, 서로 주고받는 인터페이스를 선으로 연결했습니다. 중요한 데이터의 흐름도 표시했고, 필요한 곳에는 어떤 기술을 사용하는지도 적었습니다. 그런데 다양한 보고 라인을 거치면서 누군가는 전체적인 구조가 안 보인다고 이야기 하기도 하고, 어떤 사람은 그림을 보면서 어디까지가 우리가 개발하는 영역이고 어디부터가 외부 시스템인지 잘 모르겠다고 하는 한편, 또 어떤 사람은 특정 기능이 어떤 컴포넌트로 구성되는지를 물었고, 또 다른 사람은 실제로 어떤 ECU에서 실행되는지를 궁금해했습니다. 되돌아 보니, 모든 사람들이 같은..

차량 진단을 처음 접했을 때 가장 처음 접했던 단어가 UDS였습니다. 진단기로 특정 ECU에 접속하고, Diagnostic Session을 변경하고, DID를 읽거나 DTC를 확인하고, Routine을 실행하는 식입니다. 그리고 조금 더 살펴보다 보면 Security Access와 ECU Programming까지도 접하게 됩니다. 그래서 "차량 진단 = UDS"와 같이 둘을 같은 개념으로 생각하기도 했습니다. 하지만 실제 차량의 진단 환경을 조금 더 넓게 들여다보면 UDS만으로는 설명되지 않는 부분이 많습니다. 예를 들어 진단기는 ECU가 어떤 DID를 제공하는지 알아야 합니다. 해당 DID의 데이터가 2 Byte인지 4 Byte인지, 물리값으로 변환하기 위해 어떤 Scaling을 적용해야 하는지도 알..