AV와 ADAS 시스템 모두에서 자율 기능의 복잡성이 증가함에 따라, 안전에 중요한 소프트웨어를 개발하는 전통적인 방법론은 부적절해지고 있습니다. 자율 시스템은 복잡한 실제 운전 영역에서 작동하도록 설계되었기 때문에, 거의 끝없이 다양한 시나리오를 다루어야 합니다. 그리고 차량 개발 프로세스를 통해 새로운 에지 케이스와 시나리오가 발견됨에 따라 시스템 요구 사항을 추가하고 조정해야 합니다. 더욱이, 새로운 프로덕션 차량에 대한 소프트웨어 개발은 차량이 주행을 시작한 이 후에도 계속되며, 무선 업데이트를 통해 새로운 기능이 추가되어야 합니다. 결과적으로 소프트웨어 품질의 추적성과 시간이 지남에 따른 회귀를 방지하는 것은 안전하고 예측 가능한 자율 행동을 보장하는 데 매우 중요합니다.
전통적인 ADAS 개발에서 V-모델은 안전과 관련된 중요한 시스템을 개발하고 평가하기 위해 채택됩니다 (그림 1). 이러한 개발 프로세스는 요구 사항을 정의하고 각 요구 사항을 상위 구성 요소와 기본 구성 요소로 분할 테스트한 다음, 전체 요구 사항에 대해 스택의 성능을 테스트하는 것으로 구성됩니다. 자율 시스템 개발이 고도화되고 복잡해짐에 따라, 안전을 보장하기 위한 요구 사항을 정의하고 그에 따라 크게 증가하는 시나리오 확보는 매우 어려운 일입니다. 또한 실제 운전을 통해 수집되는 새로운 정보를 통해 시스템 운영 설계 영역 (ODD)가 확장되며, 그에 따른 요구 사항도 지속적으로 변경되고 조정됩니다.
이 블로그에서 Applied Intuition 팀은 기존 시스템 엔지니어링 팀에서 채택한 전통적인 방식부터 머신러닝(ML) 기반의 최신 접근 방식까지 요구사항 정의를 위한 다양한 접근 방식을 살펴봅니다. 또한 개발 기간 동안 요구 사항을 관리하고 업데이트하는 방법에 대해 논의합니다.
요구 사항 유형 : 요구사항 유형 :요구사항 유형 :요구사항 유형 :
자율 주행 시스템은 내부 엔지니어링 팀, 승객, 규제 당국 및 상업용 차량 운영자와 같은 다양한 이해관계자의 기대치를 충족해야 합니다. 또한 시스템은 여러 유형의 요구 사항을 충족해야 합니다 (표 1). 요구 사항은 일반적으로 이해관계자의 기대에 따라 개발되지만 운영 개념, 지원 전략 활성화, 효과 측정 및 산업 안전 표준과 같은 요소도 고려해야 합니다. 예를 들어, 요구 사항은 ISO/PAS 21448 (또는 SOTIF) 또는 ISO 26262와 같은 안전 표준을 따라 각각 안전하다고 선언될 수 있는 기능을 생성하고 시스템과 구성 요소가 오류를 범할 위험을 최소화해야 합니다.
요구사항 정의 방법 :
ML 기반 AV 프로그램은 자율 시스템을 개발하고 검증하기 위해 잠재적으로 막대한 양의 실차 및 시뮬레이션 데이터를 요구하기 때문에 전통적인 시스템 엔지니어링 팀과는 다른 요구 사항 정의가 필요합니다.
요구 사항 정의에 관한 기존의 접근 방식 :
전통적인 시스템 엔지니어링에서 요구 사항 정의 프로세스는 상위 요구 사항이 기능과 성능 요구 사항으로 분류되고, 자율 시스템, 하위 시스템 및 구성 요소들에 걸쳐 할당되는 계층 구조를 따릅니다 (그림 2). 이해관계자의 기대치 (예 : 프로그램의 목표, 가정, 기능/행동 기대치), 운영 개념 (제품의 라이프사이클 동안 시스템이 운영되는 방식), 그리고 인간/시스템 간 상호 작용(어떻게 하드웨어와 소프트웨어는 시스템의 인프라/인력과 상호 작용할 것인가 등)의 기술적인 문제를 식별하고 설계하기 위해 평가됩니다. 요구 사항은 정량화 가능한 성능이나 기타 기술 기준을 설정하여 추가로 정의할 수 있습니다.
세부 요구 사항이 설정된 후, 파생된 전체 요구 사항이 각 레벨(예 : 시스템, 하위 시스템)에서 초기 이해관계자의 기대치에 상응하도록 검증되어야 합니다.
이러한 접근 방식은 테스트 대상 시스템이 직면할 수 있는 모든 가능한 상황을 열거할 수 있는 덜 복잡한 환경(좁고 제어된 ODD)에 효과적입니다. 그러나 더 광범위한 자율주행 사용 사례로 확장할 때, 시스템은 매우 가변적인 환경에서 끝없이 특이 사례를 탐색해야 하며, 고려해야 할 요건과 시나리오 수가 폭발적으로 증가하게 됩니다.(이 블로그 게시물에서 해당 토픽에 대해 자세히 알아보기).
그렇다면 광범위한 ODD에서 요구사항을 정의하기 위한 대안적 접근 방식이 있을까요?
머신러닝(ML) 기반 기업이 요구 사항 정의에 접근하는 방법 :
반대로 ML 기반 AV 프로그램은 실제 드라이브 데이터에 대한 엄격한 분석을 통해 많은 요구 사항을 정의합니다. 개발팀은 먼저 주행 속도, 도로 만곡점까지의 거리, 감속, 추종 거리 등과 같은 ODD(예 : 도시 지역)에서 안전한 주행에 필요한 항목을 작성합니다(그림 3). 각 항목에 대해 팀은 승객의 편안함과 안전에 적합한 임계값을 찾기 위해 수천 개의 시나리오를 분석합니다. 예를 들어, 안전한 추종 거리를 알아내기 위해, 팀은 모든 ODD 구간의 다른 차량을 뒤쫓는 시나리오를 분석하여, 각각의 상황에서 선두 차량으로부터의 안전거리를 도출할 수 있습니다. 이러한 정량적 결과는 성능 요구사항을 알려줍니다.
요구사항 정의 프로세스는 실제 AV 스택 또는 실제 운전자가 경험한 일반적으로 알려진 문제를 기반으로 반복됩니다. 예를 들어, 실제 운전자가 2초의 평균 후속 거리를 남겨두어도, 과거 주행 데이터에 대한 연구는 선행 차량이 갑자기 브레이크를 밟으면 후행 차량이 반응하기에 충분한 시간을 주지 못한다는 것을 발견할 수 있다. 이 경우 안전한 거리를 유지하기 위해 좀 더 차간 거리를 두는 등의 요구 사항을 조정할 수 있습니다.
데이터 기반 요구 사항이 설정되면 계획 알고리즘 개발과 시뮬레이션 테스트를 위한 시나리오 생성이 동시에 이루어집니다.
개발 라이프 사이클 전반에 걸친 요구 사항 관리 :
새로운 특이 사례가 발견되고 사용자 개입이 발생하며 ODD 범위가 확장됨에 따라, 제품 개발 기간 동안 요구 사항은 끊임없이 변경됩니다. 변화하는 요구 사항 목록을 관리하기 위해 개발 팀이 취할수있는 모범 사례는 무엇일까요?
요구 사항 관리에는 일반적으로 요구 사항에 대한 성능 추적, 근본적인 원인 평가, 오류 디버깅, 요구 사항 임계값 조정 등이 포함됩니다. 시스템과 구성 요소 설계가 요구 사항을 충족하는지 확인하기 위해 테스트를 수행할 때는 먼저 요구 사항을 의미상 관련 있는 사전 정의된 시나리오로 변환하는 것이 중요합니다. 요구 사항(예 : 추종 거리)은 기능적 시나리오(예 : 도심에서 차간 간격)와 연결되어야 하며, 매개 변수가 변화되어도 적용되어야 합니다(예 : 도로 상태, 날씨 변동, 액터 차량 유형). 매개 변수 분포가 설정되면 시뮬레이션 테스트의 구체적인 시나리오 (특정 테스트가 가능한 사례)가 생성될 수 있습니다.
개별 요구 사항에 대한 AV 스택의 성능을 추적하기 위해 사전에 구현된 도구를 사용하여 시뮬레이션 테스트 결과를 원래 요구 사항으로 자동 추적하여 완전한 추적성 체인을 유지할 수 있습니다. 또한 이러한 도구를 통해 개발 팀은 확인된 요구 사항과 추가 평가가 필요한 요구 사항을 파악하여 시뮬레이션 진행 상황을 모니터링할 수 있습니다.
AV 스택이 요구 사항을 충족하지 않으면 개발 팀은 오류를 디버깅하거나 앞에서 설명한 대로 요구 사항 변경을 고려할 수 있습니다. 요구 사항을 더 엄격하게 만들면 차량에 오류에 대한 추가 보호 장치가 제공되는 경우가 대부분이지만 일부 상황에서는 요구 사항을 완화하는 것이 더 안전할 수 있습니다 (예 : 고속도로 차선 병합 시 제한 속도 초과). 이 예는 특정 ODD 맥락을 고려하여 요구 사항을 정의하는 것의 중요성을 강조합니다.
Applied Intuition의 접근 방식 :
Applied Intuition은 요구 사항에서 시나리오를 자동으로 생성하는 데 필요한 워크플로 셋업을 지원합니다. Applied Intuition 도구를 사용하여 개발 팀은 높은 수준의 기능 요구 사항에서 실현 가능한 시나리오, 논리적 시나리오 및 구체적인 시나리오를 프로그래밍 가능한 방식으로 생성하고 대규모 시뮬레이션을 실행하여 테스트 결과를 프로그래밍 방식으로 분석할 수 있습니다. Applied Intuition 엔지니어링 팀의 요구 사항 및 추적성 주제에 대해 상의하시거나 자세히 알아보시려면 이 링크를 통해 문의하십시오.
.webp)
.webp)
