지능형 운전을 위해서는 다양한 전공의 사람들이 함께 일해야 하며, 모든 사람이 소프트웨어나 자동차 소프트웨어 배경 지식을 갖고 있는 것은 아닙니다. 다양한 배경을 가진 사람들이 기사의 내용을 어느 정도 이해할 수 있도록 하기 위해 이 기사에서는 매우 대중적인 언어를 사용하여 설명하고 다양한 그림으로 설명하려고 합니다. 이 기사에서는 모호한 용어의 사용을 피하고 모든 용어는 처음 등장할 때 정확한 정의를 제공합니다.
지능형 운전의 개념 모델은 단순히 세 가지 핵심 문제를 해결하는 것입니다.
1. 나는 어디에 있는가?
2. 나는 어디로 가는가?
3. 거기까지 어떻게 가나요?
첫 번째 질문 "나는 어디에 있는가?" 해결해야 할 것은 "환경 인식"과 "포지셔닝"의 문제입니다. 이해해야 할 것은 자동차 자체의 위치와 위치 주변의 정적 환경입니다. (도로, 교통표지판, 신호등 등) 및 역동적인 환경(자동차, 사람 등). 이로 인해 다양한 센서 및 알고리즘 시스템을 포함한 일련의 감지 및 위치 확인 기술 솔루션이 탄생했습니다.
두 번째 질문 "나는 어디로 가는가?" 자율주행 분야에서는 "계획 의사결정"입니다. 이로부터 "글로벌 계획", "지역 계획", "작업 계획", "경로 계획", "행동 계획", "행동 의사 결정", "동작 계획" 등과 같은 용어가 파생됩니다. 언어적 모호함 때문에 이러한 용어 중 일부는 동일한 의미를 말하는 다른 방식이며, 일부는 종종 유사하지만 경우에 따라 약간 다른 의미를 갖습니다.
특정 용어를 제외하고 일반적으로 '계획 의사결정'의 문제는 세 부분으로 분해됩니다.
1. 특정 범위 내에서 글로벌 의미의 계획(공통 용어: 글로벌 계획, 경로 계획, 작업 계획)
2. 첫 번째 단계의 결과를 여러 단계로 나눕니다(공통 용어: 행동 계획, 행동 의사 결정)
3. 각 단계마다 추가 계획을 수행합니다. 용어 : 로컬 계획, 모션 계획)
이러한 다양한 계획을 위해 문제 해결을 위한 많은 알고리즘 시스템이 파생됩니다.
세 번째 질문 "어떻게 해야 하나요?"는 일반적으로 "실행 제어", 즉 계획의 목적을 달성하기 위한 가장 작은 계획의 실제 구현을 의미합니다. 특히 자동차에서는 다양한 제어 알고리즘에 반영되는 경우가 많으며, 제어 이론은 이러한 문제를 해결합니다.
이 세 가지 문제에 대한 해결책은 모두 최종 분석에서 알고리즘 문제이기 때문에 어떤 의미에서 자율주행의 핵심은 알고리즘이라고 할 수 있습니다. 어떤 의미에서 소프트웨어 아키텍처는 이러한 알고리즘을 전달할 수 있어야 합니다. 좋은 운반 시스템이 없으면 알고리즘이 아무리 좋아도 쓸모가 없습니다.
편의상 기본 개념 모델의 세 가지 이슈를 E, P, )로 표현합니다. E-P-X의 각 세트에는 설명적인 문제 공간이 있습니다.
예를 들어 문제 공간 A를 '베이징에서 광저우로 운전'으로 정의하면 문제 E의 경우 위치 지정이 베이징의 현재 구역에 집중될 수 있으며 거리로 세분화할 필요가 없습니다. 지방고속도로 상공에는 뇌우 유무와 도로 구조 정보도 신경 써야 한다. 질문 P의 경우:
P-1: 첫 번째 단계는 고속도로, 국도 또는 지방 고속도로를 택할 전역 경로를 설계하는 것입니다.
P-2: 다음을 기반으로 일련의 행동 구성 요소를 계획합니다. 글로벌 경로, 어느 고속도로 교차로로 먼저 갈지, 몇 킬로미터 주행할지, 주유를 위해 휴게소로 이동, 다른 도로로 변경 등
P-3: 각 구간별로 구체적인 도로 경로를 계획하세요. 예를 들어, 세 번째 순환 도로를 이용하거나 네 번째 순환 도로를 고속도로 교차로로 이동하려는 경우 어떤 도로로 변경해야 할까요?
X는 P가 계획한 모든 단계를 실행해야 합니다.
문제 공간 B를 '교차로 안전 운전'으로 정의한다면, 문제 E의 경우 현재 도로 정보, 신호등 정보, 도로 위 차량 상태, 보행자 상태 등에 주의를 기울여야 합니다. P 문제의 경우:
P-1: 첫 번째 단계는 교통 규칙 및 도로 정보에 따라 현재 교차로에 도달할 차선과 대상 교차로에 진입할 차선을 포함하여 교차로를 통과하는 안전한 경로를 계획하는 것입니다.
P-2: 두 번째 단계는 첫 번째 단계의 근본 결과를 기반으로 먼저 속도를 늦추고, 목표 차선을 전환하고, 정지하고 빨간 신호를 기다리고, 출발하기 시작하는 일련의 동작 시퀀스를 계획하는 것입니다. 가속하고 교차로를 통과합니다.
P-3: 세 번째 단계는 두 번째 단계에서 각 동작에 대한 구체적인 궤적을 설계하는 것입니다. 궤적은 보행자, 차량 등의 장애물을 피할 수 있어야 합니다.
X는 문제 P의 출력을 실행하는 역할을 담당합니다.
이 문제 공간 B는 일반적인 계획 알고리즘으로 해결해야 할 문제에 가장 가깝습니다. P-1의 첫 번째 단계를 흔히 "글로벌 계획" 또는 "작업 계획"이라고 하고, P-2는 "행동 계획" 또는 "행동 의사 결정"이라고도 하며, P-3는 "지역 계획" 또는 "행동 계획"이라고 합니다. 행동 계획 ". 모션 계획". 아래 그림에서 볼 수 있듯이 E-P-X는 추상적인 기본 개념 모델을 형성하며 문제 공간 A와 B는 특정 범위에서의 구체적인 구현입니다.
그림 1 두 개의 EPX 문제 공간
A와 B는 비슷한 E-P-X 구조를 가지고 있지만 그들이 해결하는 문제의 범위는 시간과 공간에서 매우 다릅니다. 위 그림에서 A가 하는 작업은 다음과 같습니다. 그래서 실제로는 아래 그림과 같이 E-P-X 모델은 프랙탈 재귀 구조입니다.
그림 2 상위 레벨의 EPX
X의 프랙탈 재귀 구조는 실행을 위해 다음 레벨에서 항상 더 작은 단위의 E-P-X로 분해될 수 있습니다.
"프랙탈"은 "자기 유사 프랙탈"이라고도 합니다. 대중적인 이해는 사물의 부분이 전체와 유사한 구조를 가지고 있다는 것입니다. 이는 나무 가지와 전체와 같이 서로 다른 규모에서 대칭입니다. 나무는 구조가 비슷하고, 더 나아가 각 잎의 줄기맥도 비슷한 구조를 가지고 있습니다. 아래 그림에는 몇 가지 일반적인 프랙탈 구조가 나열되어 있습니다.
그림 3 프랙탈 예
이 6개의 그래픽에는 하나의 기능이 있으며 각 그래픽의 모든 부분은 전체 그래픽과 동일한 구조를 갖습니다. 해당 지역을 좀 더 확대해 보면, 지역 지역도 동일한 구조를 가지고 있는 것을 알 수 있습니다. 따라서 전체에 적용할 수 있는 일련의 비즈니스 처리 로직이 있으면 부분에도 적용할 수 있습니다. 어떤 나무를 재배하는 것과 마찬가지로 가지를 가져다가 심으면 새로운 나무로 자랄 것입니다. 소프트웨어 프로그램에 매핑된 표현은 "재귀"입니다. 이는 재귀 함수를 사용하는 것이 아니라 아키텍처 수준 재귀를 사용한다는 의미입니다.
"프랙탈"의 보다 학술적인 표현은 "1차원 선, 2차원 표면, 3차원이라는 전통적인 장벽을 뛰어넘어 객관적인 사물을 설명하고 연구하기 위해 분수 차원 관점과 수학적 방법을 사용하는 것입니다." 고체, 심지어 4차원 시공간까지 설명하는 것은 복잡한 시스템의 실제 속성과 상태에 더 가깝고 객관적인 사물의 다양성과 복잡성과 더 일치합니다." "물리적 현실"에 적합한 수학적 표현을 찾아 이를 "프로그램 현실"로 변환하면 보다 간결하고 명확하며 정확한 소프트웨어 아키텍처와 구현 방법을 찾을 수 있습니다.
E-P-X는 "물리적 현실"을 기반으로 추상화된 구조입니다. 그리고 그 대부분은 다양한 종류의 알고리즘 작업입니다. 개별 알고리즘 자체의 연구 및 개발은 미리 정의된 입력 및 출력 조건을 기반으로 독립적으로 수행될 수 있습니다. 하지만 어떻게 알고리즘을 결합하고, 적절한 시기에 올바르게 트리거하고, 그 결과를 합리적으로 사용하여 최종적으로 실용적인 기능을 구성할 수 있는지 살펴보겠습니다. "물리적 현실"에서 "프로그램 현실"로의 연결의 핵심은 소프트웨어 아키텍처입니다.
자율주행 시스템은 레벨 1부터 레벨 5까지입니다. 위로 올라갈수록 위에서 언급한 E-P-X 모델이 더 깊게 내포되어 있습니다. 소프트웨어 아키텍처가 더욱 어려워집니다. 대부분의 단일 Level1 및 Level2 기능에는 E-P-X 모델의 한 레이어만 필요합니다. AEB(자동 비상 제동)를 예로 들어 보겠습니다.
E 부분(인식): 주로 전방 대상(자동차, 사람)의 정적 인식 및 분류, 동적 추적, 거리 및 속도 감지.
P 부분: AEB는 종방향 제어만 수행하기 때문에 속도 제어를 통해 모두 구현 가능합니다. 따라서 일정 기간 동안의 속도를 계획하십시오.
X 부분: 속도 계획을 차량 제어 장치에 넘깁니다.
EPX 한 레이어만으로 AEB 기능이 간단하다는 뜻은 아닙니다. 실제로 양산이 가능한 AEB 기능을 구현하는 것은 매우 어렵습니다. 그러나 첫 번째 수준 EPX는 시나리오를 기반으로 일정을 계획할 필요가 없으며 단일 시나리오에서 EPX 구현에만 집중하면 되며 해당 소프트웨어 아키텍처는 비교적 간단합니다. 2장에서는 L2 기능의 일반적인 소프트웨어 아키텍처를 소개합니다.
가장 작은 세분성 수준의 EPX 루프에서도 하나의 EXP 구현으로 이 수준의 모든 문제를 해결할 수는 없습니다.
예: 간단한 직선 주행 사용 사례의 경우 모든 평탄한 도로, 오르막 및 내리막 시나리오를 처리할 수 있는 차량 제어 알고리즘으로 엔드 X 장치를 구현할 수 있습니다. 또한, 스케줄링 유닛(S)을 이용하면 E 유닛의 정보를 바탕으로 평탄한 도로, 오르막길, 내리막길을 서로 다른 시나리오로 식별하고, 서로 다른 다음 레벨의 EXP 사이클로 전환할 수 있습니다. 다음 레벨의 각 EXP 루프는 단일 장면을 구현합니다. 실제로 X-unit 제어 알고리즘을 사용하여 모든 평지, 오르막, 내리막 시나리오를 해결하더라도 알고리즘은 여전히 내부적으로 이러한 시나리오를 구분합니다. 실제로는 여전히 작은 단위의 EXP 루프입니다.
그림 4 EPX Scheduling
그림 4에 표시된 것처럼 장면 스케줄링(S)은 모든 수준에 있을 수 있으며, 이는 "시나리오"의 정의도 세분화되어 있음을 의미합니다. 따라서 EPX 모델은 EPX-S 모델이어야 합니다. L2 아래에는 명백한 S 섹션이 없습니다.
자동 주차 지원 기능에는 수직 주차, 수직 주차, 수평 주차, 수평 주차, 대각선 주차 등 장면 스케줄링이 필요하기 시작합니다. 모두 다릅니다. 시나리오와 해당 P 및 X 부분을 별도로 구현해야 합니다. 그러나 장면 스케줄링은 "Human-In-The-Loop" S 장치인 HMI 인터페이스를 통해 수동으로 선택할 수 있습니다.
레벨 3 위 기능 중 장시간 연속 운전에는 수동 개입이 필요하지 않습니다. 필연적으로 다양한 EXP 레벨의 자동 예약이 수반됩니다. 이러한 방식으로 소프트웨어 아키텍처는 L2 이하의 기능과 매우 다릅니다. 이것이 많은 회사가 L2와 L3+를 두 개의 다른 팀으로 나누는 이유 중 하나입니다.
실제로 소프트웨어 아키텍처가 다중 레벨 EXP-S 모델을 기반으로 의식적으로 설계되는 한 각 EXP-S 장치는 자체적으로 적절한 구현을 갖습니다. 실제로 소프트웨어 아키텍처 세트는 다음과 같이 실현될 수 있습니다. L1부터 L3+까지 지원 위의 자동운전은 기본입니다. 단지 S 유닛이 L2 이하의 기능에 약할 뿐이지만 아키텍처 상태는 여전히 존재합니다.
먼저 L2 기능의 일반적인 소프트웨어 아키텍처를 살펴보겠습니다. AEB/ACC/LKA 3가지 기능은 L2의 가장 고전적인 운전 보조 기능으로, 일반 시스템 솔루션의 인식 부분은 주로 전방 카메라 출력 대상(차량, 보행자) 정보를 수집하고 이를 전방 밀리미터파 레이더에서 제공하는 목표 데이터와 융합하여 보다 정확한 속도와 거리를 얻습니다. 시각적 인식과 레이더 인식은 대부분 Smart Sensor 솔루션을 사용하므로 Tier 1은 성숙한 Tier 2 공급업체의 제품을 선택할 수 있습니다. Tier 1의 주요 개발 작업은 인식 융합과 기능적 상태 기계 및 차량 제어 알고리즘의 구현에 관한 것입니다. 옵션 1: 시각적 인식 결과는 레이더 인식 컨트롤러로 전송되고, 레이더 인식 컨트롤러는 인식 융합 및 L2 기능 상태 머신 그림 5 구성표 1 topology 옵션 2: 독립적인 L2 컨트롤러가 비전과 레이더 스마트 센서를 연결합니다. L2 컨트롤러는 인식 융합 및 L2 기능 상태 머신 그림 6 구성표 2 토폴로지 두 가지 모든 솔루션이 채택되는 경우가 많습니다. 솔루션 1은 고성능 레이더 컨트롤러를 사용하고 일부 컴퓨팅 장치를 할당하여 융합 알고리즘과 기능 상태 머신을 구현합니다. 많은 칩 제조업체에서는 레이더 처리 칩을 설계할 때 컴퓨팅 성능의 이 부분을 고려합니다. 예를 들어 NXP의 S32R 시리즈는 레이더 ECU용으로 특별히 설계되었습니다. 다중 코어는 레이더 신호 처리와 L2 기능 구현을 동시에 수행하기에 충분합니다. 결국 가장 계산 집약적인 시각적 알고리즘은 다른 장치에서 완성됩니다. 옵션 2: L2는 L2 기능을 위한 컨트롤러로 독립적으로 구현되며, 전용 Can을 통해 두 개의 스마트 센서와 통신하여 센싱 데이터를 얻습니다. 일반적으로 이 솔루션은 향후 더 많은 L2 기능을 추가하는 것을 고려할 수 있으며, 필요한 경우 더 많은 스마트 센서를 연결할 수 있습니다. 스마트 센서를 사용하는 시스템 아키텍처의 경우 전방 스마트 카메라와 전방 밀리미터파 레이더는 각각 관찰된 환경에서 대상 물체의 의미를 제공합니다. 이 두 부분의 데이터는 Can 버스나 내부 IPC(컴퓨터 OS의 프로세스 간 통신) 메커니즘을 통해 인식 융합 및 L2 기능 구현을 담당하는 모듈로 직접 전송됩니다. 하드웨어 솔루션 1이든 솔루션 2이든 업계에서 가장 일반적으로 사용되는 소프트웨어 아키텍처는 Classic AutoSar를 기반으로 개발되었습니다. Classic AutoSar는 차량 ECU에 대한 공통 기능을 제공하고 참조 소프트웨어에 대한 실행 환경과 데이터 입력 및 출력 채널을 제공합니다. 인식 융합 모듈 및 기타 ACC/AEB/LKA 기능은 하나 이상의 AutoSar SWC(소프트웨어 구성 요소)로 구현될 수 있습니다. 각 개발자는 이러한 SWC 구성 요소를 분할할지 여부와 분할 방법에 대한 합리적인 논리를 가지고 있습니다. 그러나 기본 아키텍처는 거의 동일합니다. 물론 Classic AutoSar를 사용할 수 없으며 다른 적절한 RTOS를 기본 시스템으로 사용할 수는 없습니다. 아마도 일반적인 기능 개발이 필요하고 기능 안전 표준을 충족하는 차량 ECU의 경우 아키텍처 시스템 측면에서 더 어려울 것입니다. 응용기능 개발에서는 Classic AutoSar를 사용하는 솔루션과 별 차이가 없을 것입니다. 그림 7 ACC/AEB/LKA 및 제어 실행 알고리즘과 ACC/AEB/LKA 기능 상태 머신의 일반적인 소프트웨어 아키텍처. 그런 다음 도구를 사용하여 C 코드를 생성하고 이를 대상 플랫폼에 수동으로 통합합니다. MDB 개발 방식의 편리한 점 중 하나는 먼저 CanOE와 같은 모델 도구 및 장비를 사용하여 차량에서 직접 개발 및 디버그하거나, 시뮬레이션 플랫폼에 연결하여 개발 및 디버깅을 할 수 있다는 점입니다. 이러한 방식으로 개발 팀은 두 부분으로 나눌 수 있습니다. 한 부분은 모델 도구를 사용하여 애플리케이션 기능을 개발하고, 다른 부분은 모든 차량 ECU에 필요한 일련의 지루한 작업을 개발한 다음 이를 통합합니다. 일반적으로 전자동 주차 제품은 시각적 알고리즘(정적 장애물 인식, 동적 장애물 인식, 보행자 인식, 주차 공간 선 인식)을 통합하는 보다 통합된 솔루션을 채택합니다. 초음파 레이더 알고리즘(거리 감지, 장애물 감지) 궤적 계획 및 주차 프로세스의 제어 실행이 모두 하나의 컨트롤러에서 완료됩니다. 더 높은 수준의 통합은 자동 주차 컨트롤러의 360도 서라운드 뷰 기능도 지원합니다. 이 기능은 카메라 서라운드 이미지 수정과 2D/3D 그래픽 렌더링 비디오 출력 HMI 생성 및 기타 기능의 접합도 지원해야 합니다. 그림 8 주차 시스템의 하드웨어 토폴로지 솔루션 그림의 각 모듈은 하드웨어 선택 솔루션에 따라 배포 모드가 다릅니다. 일반적으로 실시간 처리에 사용되는 MCU는 별도의 칩을 사용합니다. 다양한 칩 제조업체에는 자체 AI 장치 솔루션이 있습니다. 일부는 고성능 DSP를 사용하고 일부는 독점 매트릭스 컴퓨팅 장치를 사용하며 일부는 FPGA를 사용하는 등의 작업을 수행합니다. 아래 그림은 자동 주차 시스템의 일반적인 소프트웨어 아키텍처입니다(단순히 단순화한 그림일 뿐이며 실제 대량 생산 시스템은 더 복잡합니다). 2.1.1과 비교 , 여기서 가장 중요한 변화는 '실시간 영역'과 '성능 영역' 시스템의 구분입니다. 일반적으로 우리는 MCU 또는 기타 실시간 코어(Cortex-R, Cortex-M 또는 기타 동급 시리즈)의 소프트웨어 및 하드웨어 시스템을 "실시간 도메인"이라고 부릅니다. SOC(Cortex-A 또는 동급 시리즈)의 대형 코어와 그 위에서 실행되는 Linux/QNX를 총칭하여 성능 도메인이라고 하며, 일반적으로 시각적 알고리즘 가속을 지원하는 소프트웨어 및 하드웨어 시스템도 포함됩니다. 대량 생산을 위한 엔지니어링 난이도 측면에서 전자동 주차 시스템은 ACC/AEB/LKA와 같은 레벨 2 능동 안전 기능보다 훨씬 작습니다. 그러나 소프트웨어 아키텍처 측면에서 주차 시스템은 훨씬 더 복잡합니다. 주로 다음과 같은 측면에 반영됩니다. 그림 9 주차 시스템의 소프트웨어 아키텍처 실시간 도메인과 성능 도메인의 분리로 인해 시스템이 복잡해지며, 이는 실시간 기반이 필요합니다. 시간 요구 사항 및 컴퓨팅 리소스 요구 사항, 계산에 따라 다른 하드웨어 플랫폼 선택 와 통합 및 조정되어야 합니다. 또한 이 소프트웨어를 통해 아키텍처를 살펴보면 Linux(또는 QNX /vxworks)의 도입을 확인할 수 있습니다. 이러한 시스템 자체는 특정 산업과 관련이 없는 컴퓨터 운영 체제이며, 자동차 전자 컨트롤러에 사용되는 경우 특정 제품 기능과 관련이 없지만 자동차 ECU로 구현해야 하는 일련의 일반 기능이 있습니다. 진단, 시계 동기화, 업그레이드 등 이 부분은 전체 컨트롤러 개발에 있어서 40%를 넘는 매우 큰 작업량을 차지하는 부분으로, 컨트롤러의 신뢰성과도 밀접한 관련이 있습니다. 네트워크 통신 장비 분야에서는 이를 관리 플레인이라고도 합니다. 그 중 다수는 AutoSar AP가 제공하는 기본 기능이기도 합니다. 실제로 CP AutoSar든 AP AutoSar든 통신을 담당하는 모듈을 제외하면 나머지 대부분은 관리 플레인 기능입니다. 차량에 여러 L2 기능이 있는 경우 함께 작동하는 방법. 아래 그림은 단순화된 다중 컨트롤러 토폴로지의 예입니다. 다중 L2 기능 컨트롤러와 도메인 컨트롤러의 그림 10 토폴로지 구성 이 토폴로지는 6개의 컨트롤러, "완전 자동 주차 시스템" 및 "전방 스마트 카메라"를 통합합니다.” 및 “전방 밀리미터파 레이더 ”는 이전에 설명한 대로 기능을 제공합니다. 왼쪽 및 오른쪽 코너 레이더는 2개의 미러링 장치로, 각각 독립적으로 작동하여 "후방 차량 접근 경보" 및 "도어 열림 경보"와 같은 기능을 실현할 수 있습니다. '운전자 모니터링 시스템'은 운전자의 상태를 감지해 운전자가 운전 중 피곤함을 발견하면 경보를 울릴 수 있다. 운전자가 완전히 움직일 수 없게 되면 다른 시스템에 알려 속도를 늦추고 차를 세우도록 한다. 이 토폴로지에는 다음과 같은 핵심 사항이 포함됩니다. 여러 개의 독립적인 운전 지원 기능 컨트롤러를 연결하기 위한 도메인 컨트롤러를 도입하고, 버스 대역폭 부족을 방지하기 위해 도메인 컨트롤러를 운전 지원 도메인의 여러 Can 버스에 연결합니다. . 소프트웨어 아키텍처 측면에서 각 운전 보조 컨트롤러는 독립적으로 작동하며 자체 기능의 시작과 중지를 독립적으로 결정합니다. 관련 제어 신호는 도메인 컨트롤러로 전송되고, 도메인 컨트롤러는 이를 전력 도메인으로 전달합니다. 운전자 지원 도메인 컨트롤러는 개별 컨트롤러의 제어 출력을 판정하는 역할을 담당합니다. 여기서 도메인 컨트롤러가 할 수 있는 역할의 관점에서 볼 때 가벼운 것부터 무거운 것까지 다양한 디자인이 가능합니다. 경량 도메인 컨트롤러 설계에서 도메인 컨트롤러는 백본 네트워크의 데이터를 필터링하여 도메인의 컨트롤러로 보내는 간단한 데이터 전달만 수행합니다. 도메인의 컨트롤러에서 백본 네트워크로 제어 신호를 보냅니다. 이 방법에는 도메인 컨트롤러의 높은 컴퓨팅 성능이 필요하지 않습니다. 도메인 컨트롤러가 더 많은 작업을 수행하면 다른 컨트롤러의 실시간 도메인 부분 계산 작업을 대신할 수 있습니다. 예를 들어 ACC/AEB/LKA의 계획 제어 계산은 모두 도메인 컨트롤러에서 수행됩니다. 이를 위해서는 다른 컨트롤러가 감지 데이터를 도메인 컨트롤러로 보내야 하며, 이 데이터는 도메인 컨트롤러에서 균일하게 처리됩니다. 이를 위해서는 더 높은 컴퓨팅 성능이 필요합니다. 동시에 도메인 내 네트워크에 대한 대역폭 요구 사항도 증가했습니다. 한 단계 더 나아가 도메인 컨트롤러는 모든 감지 데이터를 얻을 수 있기 때문에 일부 추가 기능도 개발할 수 있습니다. 예를 들어 사진의 센서를 기반으로 차선 변경 지원이나 비상 장애물 구현이 가능합니다. 도메인 컨트롤러 기능에서의 회피. 기능이 점차 도메인 컨트롤러에 집중됨에 따라 감지 부분을 담당하는 다른 컨트롤러의 인식되지 않는 부분이 점차 약화됩니다. Arbitration Mechanism 앞서 말씀드린 것처럼 ACC/AEB/LKA 기능 구현, 전자동 주차 구현 등 단일 L2 이하의 기능도 가능합니다. 하나 또는 두 개의 프랙탈 재귀 레이어가 있는 EPX-S 모델로 이해됩니다. 실제로 실제 양산되는 제품에서는 ACC/AEB/LKA 3가지 기능을 동시에 켤 수 있으며, 각각 별도의 EPX-S 사이클입니다. 이는 여러 EPX-S 루프가 동시에 병렬로 실행될 수 있음을 의미합니다. X 출력이 동시에 생성되는 경우 중재 메커니즘(중재)에 의해 중재되어야 합니다. 여러 컨트롤러가 동시에 실행되면 도메인 컨트롤러가 더 높은 수준에서 중재합니다. 그러므로 EPX-S 모델을 EPX-SA 모델로 확장해야 합니다. 아래 그림과 같이 시나리오 1과 시나리오 2는 병렬로 실행되는 두 개의 EPX-S 루프이며 이들이 생성하는 X는 중재 후 출력됩니다. 그림 11 EPX-SA 개념 모델 환경 모델 개념 제안 단일 L2 기능을 구현하는 모든 컨트롤러에는 인식 기능의 특정 측면이 있습니다. 그것들은 모두 공간 각도와 거리 또는 가시광선, 초음파, 밀리미터파, 레이저와 같은 물리적 속성으로 구분할 수 있는 차량 내부 및 외부 환경 속성의 특정 측면을 설명합니다. 전체 환경에 대해 이상적이고 완전히 정확한 3D 모델 시스템이 구축되면 각 센서는 "코끼리를 만지는 시각 장애인"처럼 모델의 필터와 동일합니다. 각 센서는 이상적인 모델 속성의 특정 측면을 표현합니다. 지능형 운전의 인식 부분은 실제로 가능한 한 많은 센서와 알고리즘을 사용하여 이상적인 모델에 근접하는 것입니다. 사용 가능한 센서가 많을수록 알고리즘은 더욱 정확해지고 이상적인 모델과의 편차는 줄어듭니다. L2의 도메인 컨트롤러에서는 필요한 경우 모든 하위 컨트롤러의 센싱 데이터를 얻을 수 있으며, 이 수준에서는 모든 센싱 결과를 바탕으로 이상적인 환경 모델의 현실적인 모델을 구성할 수 있습니다. 이상적인 모델과는 여전히 큰 격차가 있지만, 이미 전체적인 의미에서는 환경 모델입니다. 환경 모델에서 제공되는 정보는 모든 수준의 계획 모듈(P)뿐만 아니라 일정 수립(S) 및 중재(A) 단계에서도 사용됩니다. 스마트 센서의 AEB/ACC/LKA 솔루션을 활용
일반적으로 사용되는 하드웨어 아키텍처
일반적인 소프트웨어 아키텍처
고도 통합 제품 솔루션
개략적인 하드웨어 토폴로지는 다음과 같습니다. 하드웨어 토폴로지 예시
일반적인 소프트웨어 아키텍처
여러 단일 기능 ECU의 협력
EPX-SA Concept Model
위 내용은 한 기사로 지능형 주행 도메인 컨트롤러 소프트웨어 아키텍처 알아보기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
