레벨 2 - 레벨 4 자율 주행 차량 시스템에 대한 진행, 회귀 및 모듈식 테스트

자율 주행 자동차(AV) 시스템은 복잡하며 엔지니어를 지원하기 위한 강력한 테스트와 검증 프레임워크가 필요합니다. 소프트웨어 개발에 명확한 프로세스와 인프라를 사용할 수 있어 특히 대규모 개발자 기반의 환경에서 코드 버그를 방지하고 시간이 지나도 품질을 유지합니다. 지속적인 통합을 통해 자동화된 회귀 포착은 관련 소프트웨어의 기능을 정기적으로 테스트하여 전반적인 안정성을 보장하는 중요한 구성 요소입니다. 이러한 방법론은 AV 개발에도 적용되기 시작했습니다. Applied Intuition 팀은 본 포스팅에서 자율 주행 시스템의 회귀 테스트와 관련된 문제를 논의하고 테스트를 효과적으로 설정하고 오류를 디버깅하기 위한 모범 사례를 공유합니다.

자율 주행 자동차 회귀 테스트의 과제

자율 주행 시스템에 대한 시뮬레이션을 사용한 코드 개발의 일반적인 흐름은 그림 1에 나와 있습니다. 이 워크 플로우의 각 단계마다 단계만의 과제가 있습니다.

코드 개발 및 푸시:

• 여러 사람이 결과를 낸 상호 접속 코드: 상호 의존성이 다른 모듈의 복잡성의 시스템이 증가함에 따라 단위 테스트의 효과를 감소시킵니다.
  

시뮬레이션 실행: 

• 정확한 성공/실패 기준 정의: "작동하는" 소프트웨어를 정의하는 것에는 다양한 추상 레이어가 있으며 이러한 복잡한 요건을 정확하게 반영하는 것은 어려울 수 있습니다.
• 성공/실패의 적절한 평가를 위해 기본 시험의 많은 변형을 실행하고 추적할 필요가 있음: 환경의 작은 변화는 소프트웨어 동작의 큰 변화를 초래할 수 있기 때문에, 시험 변동 공간은 이를 설명하기에 이상적으로 충분히 큽니다.

결과 분석:

• 테스트 결과의 반복성: 결과는 지역의 엔지니어의 개발 데스크톱이나 회귀 테스트가 일어나는 클라우드 환경에 따라 다를 수 있습니다.
• 진행 상황 측정 및 분석: 데이터가 수집되어야 하며 다양한 청중이 쉽게 접근할 수 있어야 합니다.
  

회귀 테스트를 위한 모범 사례

팀의 자율 주행 차량 개발 진행 상황에 관계없이 시뮬레이션 및 자동화된 CI 테스트를 구현하는 타이밍이 빠른 회사는 없습니다. 도구를 더 빨리 사용할 수 있을수록 알고리즘 개발이 더 빨라집니다. 다음은 회귀 테스트를 설정하고 자율 주행 차량의 배치를 가속화하기 위해 Applied Intuition가 제안하는 몇 가지 모범 사례입니다.

유연한 배포 기능: 

소프트웨어 개발 조직은 테스트 및 개발을 위해 중앙 집중식 컴퓨팅 인프라와 함께 대량의 개인용 컴퓨터를 사용합니다. CI 및 회귀 테스트는 비용이 많이 드는 추가 설치 및 유지 보수 없이 기존 컴퓨팅 리소스를 활용해야 합니다. 프레임 워크가 전체 조직에 배포하기 쉽고 다양한 시스템에서 실행할 수 있는 경우 신규 사용자의 활성화 에너지가 현저히 낮습니다. 또한 시뮬레이션은 Docker Swarm 또는 Kubernetes와 같은 조정 플랫폼을 활용하여 오버 헤드를 줄이면서 빠른 성장을 지원할 수 있어야 합니다.

집중 테스트: 

시나리오 회귀 테스트는 결과에서 깨끗한 신호를 얻기 위해 가능한 한 좁게 타겟팅하고 분리해야 합니다. 이는 가능한 한 시나리오에서 관련 코드만 실행하는 것으로 해석됩니다. 예를 들어, 계획 모듈의 정지 신호 로직 회귀 테스트는 종합적으로 다른 작용 행위자(그림 2)의 존재 여부와 관계 없이 정지 신호 교차로와 관련된 모든 상황을 포괄적으로 다루어야 합니다. 결과적으로 이러한 모듈에 대한 모의 입력이 종종 필요합니다. 일반적인 예는 인식 입력이 가상으로 생성되고 계획 모듈만 실행되는 합성 시뮬레이션입니다. 계획 모듈에 대한 입력을 현실적으로 시뮬레이션하면 관심 있는 동작에 대한 분리된 테스트가 가능합니다.

‍

Figure 2: For a 4-way stop intersection, it's important to cover all situations comprehensively, such as an actor vehicle turning right, turning left, or going straight.

‍
쉬운 시나리오 생성: 

합성 시나리오는 신속하게 만들고 확장할 수 있어야 합니다. 즉, 10분 안에 시나리오를 만들고 수십 개의 고유한 사례를 처리하기 위해 다른 10분 안에 프로그래밍 방식으로 확장할 수 있습니다. 이를 통해 개발자는 신속하게 문제를 해결하고 발견된 문제를 해결할 수 있습니다. 시뮬레이션(재시뮬레이션)을 위해 이전 드라이브 데이터를 사용하는 것도 정말 중요합니다. 시나리오가 생성되고 커밋 테스트 스위트의 일부로 실행되면 정지 신호 논리에서 큰 회귀를 효과적으로 방지하여 개발자가 기존 기능을 손상시키지 않는 코드를 자신있게 제출할 수 있습니다.

개발 워크 플로우에 통합: 

플랫폼의 상호의존성(예: 로컬 워크스테이션에서 코드를 개발하지만 클라우드에서 시뮬레이션을 실행 중인 엔지니어)으로 인해 시뮬레이터는 개발 워크플로우에 신중하게 통합되어야 하며 클라우드에서든 로컬 머신에서든 테스트 결과를 반복할 수 있어야 합니다. 기존 CI/CD 파이프라인에 시뮬레이션을 추가하는 것은 매우 중요합니다. 시뮬레이션은 자동화된 파이프라인에서 중요한 단계가 되어야 합니다. 개발자들은 코드 변경에 대한 즉각적인 피드백을 받을 수 있습니다. 또한 시뮬레이터를 기존 데이터 처리 파이프라인과 긴밀하게 작동하도록 하는 것은 이해당사자들에게 중요한 결과에 대한 즉각적인 액세스를 제공합니다.

성공/실패 기준 및 직관적인 대시 보드에 대한 정확한 설명:

깨끗하고 효과적인 방법으로 테스트 결과를 캡처하고 보는 것도 중요합니다. 이는 시나리오 테스트 성공/실패 기준을 정의하는 것으로 시작되며, 테스트의 전체 범위와 의도를 파악하면서 최대한 구체적이어야합니다. 이상적으로 합격 / 불합격 기준은 자율 주행 시스템의 특정 요구 사항에서 직접 비롯되며 도구는 요구 사항을 프로그래밍 방식의 테스트 사례로 빠르고 쉽게 변환 할 수 있도록 지원해야합니다. 시나리오 언어는 테스트 기준의 많은 부분을 포괄할 수있는 유연성을 유지하면서 테스트 기준을 정확하게 설명할 수 있어야 합니다.테스트가 깨끗하고 신뢰할 수 있는 출력을 제공하면 실행 가능한 정보를 효율적으로 제공하기 위해 결과를 쉽게 보고 탐색할 수 있으며 즉시 이해할 수 있어야 합니다. 대시 보드는 직접 관련된 엔지니어뿐만 아니라 조직의 다양한 이해 관계자가 이해해야 합니다.

다른 테스트 카덴스:

회귀를 포착하기 위해선 두 가지 유형의 테스트를 수행해야 합니다. 커밋 검사(그림 1)은 초기에 종종 버그를 잡기위한 유용하지만, 모든 코드 저장소를 커밋에서 실행해야 합니다. 반면에 스케줄링된 평가(그림 3)는 시간이 지남에 따라 성능과 회귀 분석을 추적하는 데 유용하며, 매일 규칙적인 리듬에 실행해야합니다.

모듈식 테스트를 통한 오류 디버깅

진정한 실패가 식별되면 관찰된 성능의 근본 원인을 식별하기 위해 수행해야 할 작업이 있습니다. 팀은 종종 테스트 확장에 대해 이야기하지만 특정 코드를 격리하고 집중하는 것은 오류를 디버깅하는 데 중요합니다. 예를 들어 자율 주행 차가 보행자 앞에서 멈추지 않으면 코드의 다른 부분을 끄고 책임 코드가 보행자를 인식하고 그에 따라 행동 할 수 있을 때까지 테스트하는 것이 중요합니다.

특정 테스트 기준으로 테스트의 초점을 좁히면 테스트 케이스와 모듈식 AV 기능간 일대일 대응이 있을 가능성이 훨씬 더 높습니다. 이 경우 AV 스택의 어느 부분이 문제의 테스트 케이스를 처리해야 하는지 즉시 알 수 있으며 추가 작업이 필요하지 않습니다. 한편, 근본 원인을 파악하기 위해 분리해야 하는 두 개 이상의 상호 작용 시스템이 테스트에 의해 활용되는 스택의 구성요소를 신속하게 수정하고 재실행할 수 있는 툴을 사용하는 것이 도움이 됩니다.

목표 대비 성능을 추적하기 위한 진행 테스트

차량 플랫폼이 성숙함에 따라 향후 버전에 대한 계획은 AV 개발의 일반적인 부분이 됩니다. 팀은 시스템의 한계를 테스트한 실제 주행에서 실패를 선택하고 차세대 플랫폼에 대한 명확한 로드맵에서 미래에 원하는 기능을 함께 그룹화합니다. 새로운 플랫폼 기능은 "샌프란시스코의 모든 신호등 처리" 또는 "고속 도로의 공격적인 차단 예측"만큼 높은 수준일 수 있습니다. 진행 테스트는 시뮬레이션 또는 실제 테스트에서 관찰된 이러한 개별 사례를 캡처하여 개발 중에 가이드로 사용합니다.

진행 테스트는 일반적으로 야간 또는 시간별 시나리오 배치의 형태를 취하며, 이 시나리오는 최신 코드에 대해 실행됩니다. 진행 테스트 스위트는 테스트 중인 시스템이 시나리오를 처리할 수 있을 때까지 많은 시나리오가 매일 실패하도록 설계됩니다. "고속도로 컷인"의 예를 사용하여 일련의 공격적인 컷인(cut-in)을 리치 테스트로 전환하여 계획 또는 제어 스택에 대한 새로운 변경 사항을 자동으로 평가할 수 있습니다. 이러한 테스트 스위트는 지속적인 통합의 범위를 벗어나 존재하며, 당김 요청을 차단하지 않습니다.  팀들이 새로운 역량을 갖추기 위해 노력함에 따라 야간 주행에서 "빨간색"에서 "녹색"으로 이어지는 시나리오를 명확히 보는 것이 매우 만족스럽습니다(그림 4).

진행 테스트와 회귀 테스트의 결합은 강력한 조합입니다. 이제 엔지니어는 핵심 코드의 위험한 변경에 사용할 수 있는 명확한 지표를 갖게 되었습니다. 큰 변화가 CI의 회귀 테스트를 통과하여 진행 중인 제품군에서 새로운 시나리오가 "녹색"이 되도록 하는 경우, 진척이 이루어진 것입니다.

시스템 테스트를 위한 Applied Intuition의 도구

Applied Intuition 팀은 회귀 및 진행 테스트를 간소화하는 도구를 제공합니다. Applied Intuition의 도구는 기존 CI/CD 솔루션과 통합하고 다양한 유형의 시뮬레이션을 통해 기능을 강화하도록 설계되었습니다. 내부적으로는 본 블로그에 설명된 것과 동일한 패러다임을 적용하여 시뮬레이터의 회귀를 방지하고 시간 경과에 따른 성능을 추적하여 소프트웨어 품질이 높고 시뮬레이터 결과를 신뢰할 수 있는지 확인합니다.

자세한 내용은 Applied Intuition의 엔지니어에게 문의하십시오.