자율주행차(AV) 검증을 위해 사용되는 용어는 통일화되어 있지 않으며, 이는 자동차 업계의 협력과 개발 프로세스를 더디게 만드는 이유 중에 하나입니다. 개방형 표준은 OEM 및 AV 프로그램을 위한 공급 옵션을 확장하는 동시에 안전 문제를 해결합니다. 이러한 표준이 없는 경우 자동차 제조업체는 단일 공급 업체와 협력해야 하거나 공급 업체 간 시나리오 설명 언어 또는 데이터 주석 형식의 차이로 인해 도구의 기능을 확장하는 데 어려움을 겪게 됩니다. 또한 개발 팀이 개별적으로 안전 기대치를 충족하도록 각 소프트웨어 구성 요소를 평가하는 방법을 정의하고 이를 차후에 생산 가능한 제품을 위한 평가 방법으로 변환하는 것은 매우 비효율적입니다. ADAS/AV 개발에 이미 상당한 시간과 자원이 필요하기 때문에 개발자가 안전에 중요한 시스템을 평가하는 데 사용할 수 있는 공통 표준을 사용하는 것이 합리적입니다.
또한 개방형 표준은 시스템 간 상호 운용성의 보장을 통해 더 빠른 통합을 가능하게 하며 AV 프로그램이 동일한 조직 내의 팀 그리고 OEM, 공급 업체 및 규제 기관과 같은 여러 조직에서 재사용, 공유 및 협업할 수 있도록 합니다(표 1).
자동차 산업은 개방형 표준화의 개념을 받아들이는 것으로 보입니다. 최근 몇 년 동안 OpenX 및 OSI 표준과 같은 시뮬레이션 표준의 상당 부분은 사기업에서 자동화 및 측정 시스템 표준화 협회(ASAM)로 이전되었으며 이는 미래에 이러한 표준을 정의할 수 있도록 업계에서 독립적, 비영리 기관을 지원하고 있다는 것을 보여줍니다.
Applied Intuition는 시뮬레이션 테스트용 개방형 표준을 지원하고 있으며 ASAM 표준을 밀접하게 다루고 있습니다. 이 게시물에서 Applied Intuition 팀은 시뮬레이션용 개방형 표준의 현재 상황, 한계 및 향후 범위를 요약하고 개방형 표준과 관련된 도구 개발에 관한 저희의 접근 방식을 공유합니다.
현재 상황
ASAM OpenX 표준은 협업 시나리오 기반 테스트 워크플로를 용이하게 합니다(그림 1). 목표는 시나리오 사양, 테스트 설명, 시뮬레이션 및 시뮬레이션 테스트의 객체 데이터 레이블링을 포함한 종단 간(end-to-end)) 유효성 검증 워크플로를 용이하게 만들어 데이터 검색을 교환할 수 있도록 하는 것입니다. 또한 이러한 표준은 OpenX Ontology 프로젝트에서 전체 도메인 모델 만들기를 지원하기 때문에 모든 표준이 동일한 언어를 사용할 수 있습니다.
표 2는 시뮬레이션 테스트에서 일반적으로 사용되는 OpenX 프로젝트의 상위 수준 요약을 보여줍니다.
현재 표준의 한계
현재의 OpenX 표준 세트는 낮은 자율성 사용 사례의 요구에 맞춰 설계되었으며 보다 복잡한 시스템 애플리케이션에서 사용하기에는 일부 장벽이 있습니다.
예를 들어 현재 OpenDRIVE 형식 표준에는 일부 불일치하고 정의되지 않은 변환 휴리스틱이 있어 사용에 어려움이 있습니다. 예를 들어 표준의 차선 정의 스키마의 경우 HD 지도 형식을 OpenDRIVE 형식으로 변환하는 동안 실제 도로에 대한 도로 기준 트랙이 어떤 것인지 식별하기 어렵게 만듭니다. 실제 도로(특히 복잡한 교차로)는 표준에서 제공하는 구조만으로 표현하고 정의하기 어려울 수 있습니다(그림 2). 이러한 경우 고해상도 지도의 차선을 OpenDRIVE에서 제공하는 구조로 근사할 수 있는 조각들로 나누기 위해서는 광범위한 보간 및 최적화가 필요합니다. 하지만 보간으로는 원본 HD 지도의 각 지점을 정확하게 나타낼 수 없어 OpenDRIVE 형식은 차선 표현의 정확성을 잃게 되고 시뮬레이션에서 지도의 정확도를 떨어뜨리게 됩니다. 도로 표고 및 횡단 경사의 경우에도 유사한 문제가 나타날 수 있으며, 두 가지 모두 기준 곡선과 관련된 매개 변수화된 함수로 표시됩니다.
현재` OpenSCENARIO 1.0은 시뮬레이션 도구용 하위 수준 사양 형식을 지원합니다. 추상적 정의의 부족, 불완전한 조작 및 인식, 시나리오 성공 기준에 대한 정의 누락으로 인해 현재 상태에서는 복잡한 자율성 사용 사례에 표준을 적용하기 어렵습니다. 현재 자율 주행 테스트의 필요 요건은 페가수스(Pegasus) 프로젝트에서 제시된 펑셔널투컨크리트(functional-to-concrete) 시나리오 워크플로를 실현하기 위해 매개변수 공간이 있는 더 상위 수준의 장면 설명 및 표현이 요구됩니다. 차량 조작의 경우 OpenSCENARIO 1.0은 차량 역학과 같은 영역이 불완전하기 때문에 서로 다른 알고리즘과 모델 정확도를 사용하게 되는 경우 서로 다른 시뮬레이터에서 유사한 상태 궤적을 보장하기 어렵습니다. 마찬가지로 OpenSCENARIO의 인식 사양 언어 역시 미흡합니다. 그래픽, 트래픽 및 센서와 같은 가시성 액션 클래스(Visibility Action Class)의 기존 필드의 경우 용도에 대한 설명이 거의 없습니다. 변화하는 환경과 장면에 대응하는 액터의 일관된 행동을 보장하려면 인식 모델에 대한 사양이 필요합니다. 마지막으로, 현재 시나리오에는 자율 시스템 평가의 맥락에서 정의되어야 하는 명확한 성공 기준이 존재하지 않습니다. 시나리오 테스트의 실패를 통해 문제가 있는 소프트웨어가 생산 차량에 배포되는 것을 방지해야 하기 때문에 시나리오의 성공 또는 실패를 인코딩하는 언어가 없는 경우 표준의 가치가 상당히 제한될 수 있습니다.
또한 인식 시스템의 기본 구성 요소가 되는 트레이닝 및 테스트 데이터 세트의 분류 및 설명에도 불구하고 현재 업계에는 공통된 개체 또는 시나리오 레이블링 표준이 존재하지 않습니다. 표준화가 부족한 경우 자율 주행 시스템에 따라 주변 환경을 다르게 해석하거나 조직 간 데이터 공유가 불가능하거나 데이터 주석의 품질이 저하되는 것과 같은 다양한 문제가 발생하게 됩니다. OpenLABEL은 주석 방법, 구조 및 설명 언어를 표준화하기 위해 시작되었습니다.
향후 기대
이러한 시뮬레이션 테스트 사양 표준을 개선하기 위한 노력이 계속되고 있습니다. 거시적 수준에서 프로젝트 팀은 더 높은 수준의 자율성에 필요한 기능을 조정하고 있으며 시뮬레이션 기반 테스트 도구를 더욱 대중화하기 위해 새로운 표준과 개념을 모색하고 있습니다(표 3).
Applied Intuition가 개방형 표준을 다루는 방식
Applied Intuition의 시뮬레이션 도구는 OpenDRIVE, OpenSCENARIO, OSI 및 FMI를 포함하여 기존에 존재하는 다양한 표준을 지원합니다. 앞서 언급한 것과 같이 이러한 표준의 현재 범위는 특정 사용 사례에 초점을 맞추고 있으며 다른 ODD에서 작동하는 AV 프로그램으로 안전 사례를 만드는 데 필요한 모든 테스트 시나리오를 다루지는 않습니다. 따라서 Applied Intuition는 표준이 개발되는 동안 광범위한 사용 사례를 다루기 위해 현재의 표준을 넘어서는 자체 지원을 제공합니다. Applied Intuition는 이러한 표준의 발전을 면밀히 주시하고 있으며 표준이 더욱 정의됨에 따라 표준에 대한 지원을 계속 확대할 예정입니다. 또한 Applied Intuition의 시나리오 API는 OpenScenario 2.0 이상을 포함한 기능적 시나리오 정의를 내포하고 있습니다. 시나리오 API를 포함한 Applied Intuition의 도구에 대한 자세한 정보를 확인하시려면 Applied Intuition 엔지니어 팀으로 연락하세요.
.webp)
.webp)
