자율주행 소프트웨어와 하드웨어 디커플링 기술 및 동향 연구

“소프트웨어 정의 자동차 시대에 소프트웨어의 위상은 점점 높아지고 있으며, 스마트카 산업의 발전을 위해서는 소프트웨어와 하드웨어의 분리가 필요합니다.”

말은 누구나 익숙할 거라 믿습니다. 위와 같이 스마트 자동차에서는 지난 몇 년간의 개발 과정에서 자동차 공급망의 구성이 엄청난 변화를 겪었고, 소프트웨어와 하드웨어의 분리는 OEM과 공급업체 모두가 해결하려고 노력해 온 문제가 되었습니다. .

그러나 여전히 표준은 통일하기 어렵고, 각 회사의 인터페이스는 여전히 다릅니다. 오랜 세월이 지난 후에도 소프트웨어와 하드웨어의 분리는 여전히 많은 어려움에 직면해 있습니다.

01 소프트웨어와 하드웨어 분리의 배경

EE 아키텍처의 진화

(이 부분에 익숙한 독자는 건너뛰고 다음 섹션으로 바로 이동할 수 있습니다.)

이전에는 차량에 ECU가 12개에서 20개에 불과했습니다. 그러나 전자 엔터테인먼트 소비주의가 사람들의 삶의 모든 측면에 계속 침투함에 따라 분산 아키텍처의 맥락에서 자동차에 대한 사람들의 기능적 요구 사항이 점차 증가했습니다. 해당 ECU를 지속적으로 추가해야 합니다. 자율주행차의 경우 특히 그렇습니다. 그 결과 자율주행차의 ECU 수가 기껏해야 1~200개 가까이 늘어났습니다.

ECU의 지속적인 증가로 인해 데이터 전송을 위한 와이어링 하니스의 총 길이와 총 비용이 계속 증가하고 있습니다. (Zos Automotive Research의 계산에 따르면 현재의 분산 아키텍처가 지속된다면 자율주행차의 와이어링 하니스 비용은 1,000달러보다 낮지 않을 것임), 공급업체 관리의 어려움도 커졌습니다.

그리고 분산 아키텍처에서는 ACC, AEB 등의 기능이 센서(그 안의 MCU)에 묶여 서로 분리되어 있습니다(이것은 첫 번째 원칙에 어긋납니다. 사람들이 운전할 때는 그렇지 않습니다. ), 그리고 높은 수준의 자율주행을 위한 요구사항은 각 기능이 유기체이기 때문에 동일한 SoC를 통해 구현되어야 한다는 것입니다.

이러한 맥락에서 제한된 공간에서 공간 활용도를 높이고 ECU 성능을 극대화하는 방법이 업계의 다음 발전 방향이 되었습니다. 그 결과, 자동차 EE 아키텍처는 분산형 아키텍처에서 중앙집중형 아키텍처로 진화할 수 있는 문을 열었습니다. 이를 위해 많은 ECU가 도메인 컨트롤러로 대체되기 시작했고, 메인 제어 칩도 기존에서 업그레이드되었습니다. 이전 MCU에서 SoC로.

ECU는 지속적으로 감소하고 있으며, 자동차에 남아 있는 ECU도 계산의 일부를 담당하는 것에서 대부분의 실행 기능만 담당하고 처리 능력이 약화되는 "나사"로 변모했습니다(ECU는 여전히 계산을 처리하는 원래 기능이 있지만 일부 계산을 처리하는 데 더 이상 기능적으로 필요하지 않습니다.

EE 아키텍처가 분산에서 도메인 중앙 집중화로 진화하고 MCU를 대체하는 SoC는 자동차 산업이 "하드웨어 왕" 시대에서 도메인 전반에 걸쳐 "소프트웨어 정의 자동차" 시대로 전환하기 위한 전제 조건을 만들었습니다.

SoC 칩은 DSP, GPU, NPU와 같은 여러 모듈을 통합합니다. 제어 장치뿐만 아니라 수많은 컴퓨팅 장치도 통합합니다. 이를 통해 SoC 칩은 동시에 다중 작업을 수행할 수 있을 뿐만 아니라 대량의 데이터를 처리할 수도 있습니다. 일부 MCU를 SoC 칩으로 교체하는 것은 회사의 여러 부서의 일반 리더를 100대 1에 해당하는 매우 뛰어난 CEO로 교체하는 것과 같습니다.

하드웨어가 왕인 시대에 소프트웨어와 하드웨어 간의 결합도가 높기 때문에 OEM은 먼저 컨설팅 회사를 찾아 향후 5~8년 동안 자동차 기능 요구 사항에 대한 분석 보고서를 작성한 다음 보고서 소프트웨어 및 하드웨어 통합 솔루션을 기반으로 5-8년 계획을 수립합니다. 소프트웨어와 하드웨어가 생산 라인 생산에 투입되면 차량 제조업체가 다양한 구성 요소를 설치하고 차량을 배송할 때까지 5~8년 내에 차량의 소프트웨어나 하드웨어를 변경하기가 어렵습니다.

소프트웨어 정의 자동차 시대에도 여전히 원래 자동차 공장의 통합 프로세스를 따르고 5~8년의 자동차 제조 계획을 한 번에 설정한다면 처음 몇 년 동안은 문제가 그다지 두드러지지 않을 것입니다. 그러나 이 프로그램 기간의 후반부에는 자동차가 사용자에게 인도되고 자동차에 장착된 하드웨어와 소프트웨어는 모두 훨씬 오래되었습니다.

따라서 제품 설계 단계에서는 후속 반복 문제를 고려해야 합니다. 반복 문제를 해결하려면 소프트웨어와 하드웨어를 별도로 개발해야 합니다.

다양한 자동차 제조업체의 하드웨어 구성이 통합되면 하드웨어가 "롤러블"이 됩니다. 차별화를 달성하려면 OEM은 매우 빠른 응답 기능으로 사용자의 변화하는 요구를 수집하고 그에 따라 조정할 수 있어야 합니다. 반복. 현재 OEM에게는 두 가지 옵션이 있습니다. 하나는 소프트웨어와 알고리즘을 자체 개발하고 소프트웨어와 하드웨어 분리를 포함한 모든 문제를 스스로 해결하는 것이고, 다른 하나는 소프트웨어와 하드웨어를 분리한 후 반복 요구 사항을 제공할 적합한 공급업체를 찾는 것입니다.

첫 번째 길을 택하려면 OEM이 매우 강력한 힘을 필요로 하지만 모든 OEM이 그런 능력을 갖춘 것은 아니기 때문에 대부분의 OEM은 두 번째 길을 선호할 것입니다. 그 결과, 소프트웨어 알고리즘 기업의 위상이 향상되기 시작했고, 자동차 공급망 관계는 원래의 명확한 Tier1, Tier2, Tier3에서 경계가 모호한 관계로 바뀌었습니다.

이러한 맥락에서 더욱 강력한 경쟁력, 더 나은 독립적 개발, 더 나은 협력 생태계를 위해 다양한 소프트웨어 및 하드웨어 공급업체 간의 소프트웨어 및 하드웨어 분리가 필요합니다.

그러나 소프트웨어와 하드웨어의 분리라는 슬로건을 수년간 외쳐왔지만 그 효과는 이상적이지 않습니다.

센서, 칩 및 알고리즘을 분리하는 것은 어렵습니다.

알고리즘과 센서는 바인딩이 높기 때문에 실제 응용 프로그램에서는 이러한 바인딩으로 인해 알고리즘 엔지니어에게 많은 문제가 발생합니다. 예를 들어, 이전에 자동차에 사용되었던 카메라가 200만 화소에서 800만 화소로 변경된 후에는 알고리즘을 다시 작성해서는 안 됩니다.

또한 Tier1 알고리즘 엔지니어:

"센싱 알고리즘과 센서를 분리할 수 있는 능력이 있더라도 분리 후 센서를 교정하는 것이 특히 어렵습니다." 하드웨어 결합도가 높고 센서 데이터도 센서에 대한 바인딩이 높습니다. 센서가 교체되면 이전에 값비싼 데이터 주석이 모두 무효화되고 새로운 수집 라운드가 시작되어야 합니다. 알고리즘 회사들에게는 매우 중요한 문제라고 하는데, 현재로서는 이 문제에 대한 마땅한 해결책이 없습니다.

또한 차량마다 센서 구성, 설치 위치, 설치 각도가 다르기 때문에 알고리즘도 다릅니다. 감지 알고리즘도 다르고 제어 알고리즘도 다릅니다.

알고리즘과 센서의 디커플링이 그저 귀찮다면, 알고리즘과 칩의 디커플링은 매우 어렵습니다.

예를 들어, 저자가 소프트웨어와 하드웨어 분리와 관련된 문제에 대해 많은 알고리즘 엔지니어와 소통했을 때, 그들이 모두 공유하는 공통적인 문제점 중 하나는 작업의 어려움으로 인해 많은 추가 작업이 필요하다는 점을 발견했습니다. 알고리즘 이식.

알고리즘 마이그레이션 빈도를 예측할 수 없기 때문입니다. 칩 제조업체의 경쟁과 제품 반복은 시장 선호도에 영향을 미치는 경우가 많습니다. 다음 추세에서 더 나은 새 칩이 인기를 끌지 여부는 확신할 수 없습니다.

시장 선호도의 변화로 인해 OEM은 교체 칩을 지정하게 됩니다. 현재 알고리즘 엔지니어의 경우 이 칩을 기반으로 하는 알고리즘이 개선되었을 수 있으며 새로운 알고리즘 이식 요구 사항이 있을 수 있습니다.

위 현상이 나타나는 이유는 알고리즘과 칩 사이의 강한 결합 관계 때문입니다. 서로 다른 칩은 서로 다른 BSP를 제공하므로 칩과 알고리즘을 분리하는 데 사용되는 미들웨어를 재사용하기 어렵고, 서로 다른 칩에 대해 서로 다른 맞춤형 조정이 이루어져야 합니다.

모 OEM의 지능형 주행 시스템 담당자는 다음과 같이 설명했습니다.

“하위 BSP 계층에 미들웨어를 적용하는 것은 골치 아픈 일입니다. 예를 들어 조종석 칩은 Qualcomm의 8155 또는 8295를 사용합니다. 그리고 자동 구동 칩은 TI의 TDA4를 사용하므로 각 칩에서 제공하는 BSP가 다르기 때문에 통합 중에 미들웨어의 맞춤형 적응이 필요합니다. "

칩 플랫폼의 차이로 인해 미들웨어를 재사용할 수 없게 됩니다. 더욱이, 동일한 칩 플랫폼을 기반으로 하는 두 개의 도메인 컨트롤러가 서로 다른 하드웨어 아키텍처를 갖는 경우(일부 도메인 컨트롤러에는 2개 또는 심지어 3개의 SoC가 있음) 미들웨어에 대한 요구 사항도 다릅니다.

02 소프트웨어와 하드웨어 분리에 직면한 기술적 딜레마

미들웨어는 소프트웨어와 하드웨어 분리를 달성하는 데 필요한 가장 중요한 도구이므로 소프트웨어와 하드웨어 분리의 문제는 미들웨어에 집중될 것입니다.

현재 미들웨어는 실제로 기능, 하드웨어 플랫폼, 운영 체제에 따라 맞춤화가 필요합니다. 가장 고도로 표준화된 미들웨어라도 이를 적용하려면 알고리즘 회사나 OEM이 모든 것을 포괄할 수 있다고 말하기는 어렵습니다. 모든 미들웨어에는 몇 가지 제한 사항이 있기 때문에 일부는 신속하게 통신 인터페이스를 정의할 수 없고 일부는 일부 크로스 플랫폼 지원에 특히 적합하지 않으며 일부는 다른 칩과 잘 일치하지 않습니다.

데이터 전송 자체부터 미들웨어에는 데이터 편향, 데이터 오류, 데이터 전송에 영향을 미치는 단일 모듈 오류 등의 문제가 있습니다. 예를 들어, 데이터 전송량이 많은 경우 SOME/IP가 데이터 수집을 수행할 때 많은 통신 신호를 수집할 수 없으며 패킷 손실이 발생하기 쉽습니다.

또한 데이터 반환 오류는 일련의 연쇄 반응을 쉽게 일으키고 궁극적으로 의사 결정 및 실행 수준에 영향을 미치고 부정적인 결과를 초래할 수 있습니다. 데이터 공유에는 장단점이 있다고 할 수 있습니다. 이론적으로는 효율성을 높일 수 있지만 소스가 잘못되면 일련의 오류가 발생하고 효과적인 진단 및 수정 메커니즘도 부족합니다.

또한 시간과 장소도 데이터 전송에 영향을 미칩니다. 예를 들어, 고속에서 Autosar AP는 데이터 전송 대역폭에 대한 요구 사항이 더 높습니다. 이때 대역폭 전송 프로토콜과 데이터 공동 회선 전송 간의 충돌은 특히 분명합니다. 휴일에는 대역폭 사용량이 집중되고 부하가 너무 높아 데이터 전송 요구를 충족하지 못할 수 있습니다.

위의 문제 외에도 현재 미들웨어에는 캐싱 메커니즘이 부족하고 기능 그룹이 중첩을 지원하지 않으며 상태 머신 협업이 좋지 않은 등의 문제가 있습니다. 이러한 문제는 알고리즘 엔지니어가 기존 미들웨어를 기반으로 작업해야 합니다. 이는 소프트웨어와 하드웨어를 분리하는 어려움을 크게 증가시킵니다.

03 소프트웨어와 하드웨어 분리가 직면한 상업적 어려움

위의 기술적인 어려움 외에도 소프트웨어와 하드웨어의 분리 역시 일련의 상업적 어려움에 직면해 있습니다.

전문 미들웨어 제조업체

Vector, RTI, EB 및 Yitech로 대표되는 미들웨어 제조업체는 각 회사의 소프트웨어 및 하드웨어에 적용할 수 있는 표준화된 미들웨어 세트를 생산하기를 희망합니다. 한 단계로 하드웨어 분리가 가능합니다.

하지만 현실은 상상만큼 아름답지 않습니다. 한편으로는 일부 선도적인 미들웨어 회사를 제외하고 대부분의 미들웨어 회사의 제품이 OEM의 진정한 신뢰를 얻기 어려운 반면, 대부분의 알고리즘 회사는 미들웨어 제조업체와 협력할 의지가 없습니다. , 왜냐하면 미들웨어 제조사들이 인터페이스와 구현 시스템을 통일하게 되면 자사 제품의 대체성이 강화되고 차별화가 줄어들게 되어 알고리즘 기업들의 경쟁압력이 급격히 높아진다는 것을 의미하기 때문에 그들은 매우 저항력이 있다.

또한, 스마트카의 기술 개발 경로가 아직 명확하지 않은 상황에서 OEM은 자사 자동차의 구성이 경쟁 제품과 달라서 경쟁 장벽을 확보할 수 있기를 바랍니다(애플리케이션 계층에서의 차별화에도 미들웨어가 필요함). 지원), 표준화된 미들웨어는 이러한 요구에 어긋날 것입니다. 따라서 OEM은 미들웨어 회사가 개발한 표준화된 미들웨어를 사용하기보다는 자체 미들웨어를 개발하는 것을 선호합니다.

결국 이러한 미들웨어는 판매가 어려워지고, 표준화된 미들웨어만 만드는 것은 지속 불가능해집니다.

Jiuzhang Zhijia에 대해 알아본 결과 DDS와 같이 기술 장벽이 높은 모듈에 중점을 두고 장기적인 축적을 통해 특정 경쟁 우위를 확보한 Huayutongsoft와 같은 회사를 제외하고 원래 " '미들웨어 벤더'는 기본적으로 지난 1~2년 동안 변화(다른 영역으로 확장)를 시작했습니다.

Suppliers

알고리즘 회사, 일부 소프트웨어 및 하드웨어를 만드는 Tier 1 회사, 칩 제조업체는 모두 미들웨어를 만들기 시작했지만 실제로는 누구나 배우기 어려운 경험을 가지고 있습니다.

Algorithm Company

알고리즘 회사의 경우, 그들이 구매하는 표준화된 미들웨어가 너무 일반적이면 해결할 수 없는 적응 문제가 많겠지만, 그들이 얻는 것이 블랙박스에 담겨 전달된다면 일반- 알고리즘과 일치하지 않는 목적의 미들웨어는 알고리즘 엔지니어에게 큰 어려움을 초래할 것입니다. 그리고 맞춤형 미들웨어를 구매하게 되면 알고리즘 회사 역시 미들웨어 제조사와 커뮤니케이션하는 데 많은 시간을 소비해야 하고 비용도 매우 높을 것입니다.

알고리즘 회사의 엔지니어링 이사:

“문제가 있으면 일반적으로 회사에서 미들웨어 제조업체에 문제를 보고하지만 일부 제조업체는 덜 협조적이며 알고리즘 회사에 실제 증거를 제공하도록 요구합니다. 그렇지 않으면 더 많은 인력과 시간이 소모되고 개발 과정에 영향을 미칠 것입니다.

"특히 이제 막 미들웨어에 참여하기 시작한 알고리즘 회사는 특별히 그렇지 않습니다. 경험적 비교를 찾으십시오. 이는 번거롭고 시간이 더 많이 걸리며, 이 과정에서 여러 당사자가 협력할 경우 OEM은 문제 해결 과정을 더욱 확장할 수 있습니다. ”

그래서 알고리즘 회사들은 자체 알고리즘에 더 잘 맞도록 자체 개발한 미들웨어 개발을 선택하는 것뿐입니다.

그리고 해외 미들웨어 제조업체에서 만든 미들웨어는 가격이 비싼 반면, 국내 스타트업에서 만든 미들웨어는 가격이 비쌉니다. 미들웨어 제조사 자체 알고리즘을 바탕으로 자체 개발한 미들웨어보다 소프트웨어가 적합하지 않을 수도 있는데, 이는 알고리즘 기업들이 자체 미들웨어를 개발하는 이유 중 하나이기도 합니다

“내가 직접 개발하면 내 프로젝트의 요구 사항을 더 잘 이해하는 것이 미들웨어 공급업체에 개발하도록 맡기는 것보다 낫습니까? "라고 한 알고리즘 회사의 시스템 아키텍처 엔지니어가 말했습니다.

위 내용 외에도 알고리즘 회사들이 자체 개발한 미들웨어를 개발하는 또 다른 이유가 있습니다. 여러 알고리즘 회사의 알고리즘은 조금씩 차이가 있으며, 자체 개발한 미들웨어는

알고리즘 회사의 한 선임 이사는 다음과 같이 말했습니다.

"현재는 각 알고리즘의 차이점을 반영하기가 어렵습니다. 모두 C 및 C++로 프로그래밍되어 있습니다. 차이점을 말하자면, 미들웨어의 성능이 향상되어야 하며, 이를 위해서는 기능적 경험에서 몇 가지 이점을 강화하기 위해 신뢰성을 향상시켜야 합니다. ”

하지만 알고리즘 회사도 자체 개발 미들웨어를 개발할 때 많은 어려움에 직면합니다. 우선 OEM이 자체 개발한 미들웨어가 공급업체에 대한 표준을 설정할 수 있지만, 알고리즘 회사가 자체 개발한 미들웨어를 개발하면 문제가 됩니다. OEM 및 기타 공급업체가 자체 표준에 적응하도록 설득하기

L4 회사의 소프트웨어 이사가 말했듯이:

"예를 들어 Weilai와 Xiaopeng은 완전한 차량이기 때문에 자체 미들웨어를 만듭니다. A 공장은 공급업체를 제한하기 위해 일련의 표준을 설정할 수 있지만, 자율주행 알고리즘 회사가 지원 미들웨어를 만드는 경우, 귀하의 제품 세트가 다른 도메인에 적용될 수 있다는 점을 OEM에게 설득하는 것은 어렵습니다. 자체 표준에 따라 통합을 구현합니다. ”

또한 알고리즘 회사가 자체적으로 미들웨어를 개발할 때 문제가 발생하더라도 비난할 수 없습니다. 따라서 알고리즘 회사에서는 미들웨어를 더 잘해야 합니다.

메인프레임 제조업체입니다. Intelligent Network의 수석 엔지니어는 다음과 같이 말했습니다.

"우리는 공급업체와 보증 서비스 계약을 체결할 것입니다. 즉, 심각한 품질 사고가 발생하면 자동차 제조업체가 첫 번째 책임자이지만 당연히 우리가 첫 번째가 될 것입니다. 이러한 공급업체에 책임을 물을 시간입니다. 알고리즘 회사가 미들웨어를 개발한다면 책임에 있어서는 책임을 회피하기 힘들고, 우리는 그들이 책임을 회피하는 것을 허용하지 않을 것입니다

칩 제조업체

칩 제조업체가 미들웨어를 만드는 목적은 칩 성능을 보여줍니다.

기술적인 관점에서 볼 때, 칩 제조업체는 알고리즘 회사보다 미들웨어를 만드는 것이 덜 어렵습니다. 알고리즘 회사는 다양한 칩에 적응해야 하기 때문에 칩 제조업체가 미들웨어를 만드는 것보다 작업량이 훨씬 더 복잡하고, 칩 제조업체가 만든 미들웨어는 자체 칩에만 적응하면 됩니다.

그럼에도 불구하고 실제로 칩 제조업체가 개발한 미들웨어를 사용하는 사람은 거의 없습니다.

현재 미들웨어를 만드는 주요 주체에는 미들웨어 제조업체, 알고리즘 회사, 칩 제조업체 및 OEM이 포함되는 것으로 알려져 있습니다. 미들웨어의 시장 점유율은 매우 양분되어 있으며 경쟁이 치열합니다. 이때 완전한 미들웨어를 개발하고 싶다면 개발된 미들웨어를 누구에게 판매해야 할까요? 미들웨어를 통해 정말 돈을 벌 수 있을까? 모두 미들웨어를 개발하기 전에 고려해야 할 문제가 되었습니다.

알고리즘 회사의 한 전문가는 이렇게 말했습니다.

“우리는 일반적으로 칩 회사의 미들웨어를 사용하지 않습니다. 왜냐하면 환경적인 이유로 미들웨어를 더 많이 만들기 때문입니다. 그들의 미들웨어는 더 많은 기능을 가질 수 있지만, 즉, 미들웨어가 수행하는 기능이 반드시 최적인 것은 아닙니다. AI 추상화, 데이터 기록 재생, 포인트 클라우드 처리 등을 모두 수행할 수 있지만 이 경우 문제가 발생합니다. 알고리즘은 무엇을 해야 하는데 미들웨어가 모든 작업을 수행하여 성능이 저하됩니다. .완전히 보장되며 여러 알고리즘 회사의 요구를 고려해야 하며 유연성은 더욱 나빠질 것입니다. "

일부 칩 제조업체는 미들웨어를 만들 수 있지만 시장의 압력을 고려하면 알 수 있습니다. 규모가 커서 연구개발에 많은 인력과 물적 자원을 투자해야 하기 때문에 대부분의 유능한 칩 제조업체는 미들웨어 제작에 너무 많은 투자를 할 동기가 없으며 칩 자체를 좋게 만드는 데 집중하는 것을 선호합니다.

따라서 대부분의 칩 제조업체가 자체 개발한 미들웨어는 매우 가볍고 기본적으로 칩에서 실행되어 칩의 성능을 고객에게 보여줄 수 있는 데모 미들웨어입니다. 이러한 데모 미들웨어는 확실히 소프트웨어와 하드웨어를 분리하는 데 실질적인 도움이 되지 않습니다.

Original OEM

OEM의 경우 미들웨어 맞춤화에 대한 필요성은 항상 존재해 왔습니다.

특정 OEM의 지능형 주행 시스템 담당자가 예를 들었습니다.

"예를 들어 신호등 인식 알고리즘이나 양안 비전 알고리즘을 작성할 때 기존의 것과 다른 것을 원한다면 알고리즘 또는 경쟁사 알고리즘을 사용하려면 데이터 구독, 공유, 녹음, 재생, 전송, 저장, 진단 및 기타 미들웨어 기능을 포함하는 맞춤형 미들웨어 세트가 필요합니다. 그러나 이러한 기능은 미들웨어 하에서 완벽하게 실행된다는 보장이 없습니다. OEM이 요구하는 시스템이나 기능 메커니즘에 충돌이 발생할 수 있으며, 이때 문제를 해결하려면 미들웨어 공급업체가 필요합니다.”

그러나 일부 강력한 OEM은 타사 미들웨어 회사의 미들웨어를 사용하는 것을 선호합니다. 자체 개발한 미들웨어 회사입니다.

먼저 RTI의 DDS와 같은 비공개 소스 미들웨어를 구매한다는 것은 미들웨어를 맞춤화하는 것을 의미하는 경우가 많으며, 이는 더 비싼 비용이 필요할 뿐만 아니라 이에 비해 프로젝트 도킹 주기도 매우 길어지게 됩니다. 사용자 정의 방향을 완전히 제어하고, 자체 데이터를 얻고, 제품을 제한 없이 만들 수 있습니다. 이렇게 하면 제품 개발 프로세스와 이후 변환을 더 잘 제어하고, 특정 미들웨어 공급업체가 실패할 수 있는 문제를 해결할 수 있습니다. 양산 납품이 지연되는 문제.

둘째, 자체 개발한 미들웨어는 OEM에게 특정 기술 장벽을 형성할 수도 있습니다. 일부 강력한 OEM의 경우 일부 상위 계층 애플리케이션 계층은 상위 계층 애플리케이션의 요구 사항에 따라 자체 미들웨어를 만들 수 있으며 일부 미들웨어는 일부 기능을 더 잘 사용자 정의할 수도 있습니다. .

사실 미들웨어 기술이 아직 성숙하지 않고 미래 트렌드가 아직 명확하지 않은 상황에서 업계의 업스트림 및 다운스트림 플레이어가 미들웨어를 만드는 이유는 자신의 능력의 경계를 테스트하고 경계를 탐색하기 위해서입니다. 전체 산업의 .

그러나 많은 OEM 자율주행 엔지니어들은 “알고리즘 회사에 비해 OEM이 자체 개발한 미들웨어는 장점이 거의 없다”고 생각합니다.

우선 대부분의 OEM은 알고리즘 역량이 많이 축적되어 있지 않습니다. 미들웨어를 만들기 위해 특별히 팀을 구성하는 데 드는 비용은 엄청나지만, 이를 전문으로 하는 공급업체의 결과는 그리 좋지 않을 수 있습니다. . 마치 자신의 약한 프로젝트로 인한 고통이 강력한 프로젝트의 새로운 도전보다 더 고통스러운 것과 같습니다.

둘째, OEM이 자체 개발한 미들웨어는 충분한 샘플 피드백을 얻기 어렵기 때문에 제품 반복에 도움이 되지 않습니다. 공급업체의 알고리즘과 미들웨어는 모든 사람이 더 많이 사용하고 고객 기반이 증가함에 따라 버그에 대한 고객 피드백 비율이 높아집니다. 이는 OEM이 자체 제품을 개발하고 해당 제품만 공급하는 경우 제품 반복 진행에 더 도움이 됩니다. 샘플 데이터가 부족하여 반복이 느려집니다.

또한 OEM이 자체 미들웨어를 개발하려는 경우 다른 회사의 기술 인재를 빼앗을 수밖에 없습니다. 하지만 대기업 부서에 근무하는 인재들에게는 그렇게 강한 사명감이 없을 수도 있다. 결국 '하늘이 무너지는데, 하늘 위에는 아직 그것을 붙잡아줄 사람이 있다'는 느낌이 항상 있을 것이다. up'으로 최종적으로 모집된 인재의 능력을 80%까지 활용할 수 있다면 이상적이라고 판단된다. 하지만 같은 기술을 가진 사람이 혼자 나가서 연구를 개인의 관심사와 연관시킨다면, 그런 환경에서 더 많은 재능을 발휘할 수 있다는 압박감과 의욕이 분명 더 커질 것입니다.

마지막으로 OEM의 경우 자체 개발한 미들웨어는 연구팀을 구성하기 위해 많은 인재가 필요합니다. 이 길이 계속될 수 없다는 것이 밝혀지면 그렇게 많은 직원이 해고될 위험에 직면하게 됩니다. 대규모 직원 해고로 인해 현직 직원들 사이에서는 '회사가 불안정하다'는 정서가 더욱 커질 것이다.

이러한 관점에서 OEM의 "자체 개발 미들웨어"는 단순한 마케팅 슬로건에 불과할 수 있지만 이것이 모든 OEM의 자체 개발 미들웨어가 충분히 강력하다면 성공할 수 없다는 의미는 아닙니다. 즉, 자체 개발 알고리즘 개발에 성공한 OEM은 자체 개발 미들웨어에서 높은 성공 확률을 가질 수 있습니다. 그러나 상대적으로 말하면 대부분의 알고리즘을 자체적으로 개발할 수 없는 OEM의 경우 소프트웨어와 하드웨어 분리에 대한 요구 사항은 여전히 ​​공급업체에서 충족해야 합니다.

04 미들웨어는 "본래의 의도에서 벗어났다"

미들웨어의 탄생은 원래 소프트웨어와 하드웨어를 별도로 개발할 수 없다는 문제를 해결하기 위해 탄생했습니다. 따라서 사람들은 처음에는 미들웨어가 차단 효과가 될 수 있기를 바랐습니다. 소프트웨어는 프로세스를 간소화하고 모든 소프트웨어 및 하드웨어에 적응할 수 있으므로 상위 수준의 소프트웨어 응용 프로그램 엔지니어가 하드웨어 적응 문제를 고려할 필요 없이 알고리즘을 잘 수행할 수 있습니다.

그러나 현실은 본래의 바램과는 정반대입니다.

미들웨어는 높은 커스터마이징 강도를 보여줍니다.

알고리즘 회사의 소프트웨어 아키텍트는 다음과 같이 소개했습니다.

"자동차 모델이나 칩 플랫폼마다 미들웨어에 대한 적응성이 다릅니다. 제공되는 기본 소프트웨어는 미들웨어에 적응합니다. 기능도 다릅니다. 일부 차량에서 사용하는 경우 QNX 운영 체제와 일부는 Linux 운영 체제를 사용하므로 이 두 운영 체제에는 미들웨어에 대한 일부 맞춤형 콘텐츠가 있습니다

"기본 운영 체제 외에도 소프트웨어 애플리케이션도 있습니다. 계층에는 미들웨어에 대한 몇 가지 차별화된 요구 사항도 있습니다. 예를 들어, 특정 플랫폼을 기반으로 일부 특별한 통신 방법을 활성화해야 합니다. 일부는 기존 이더넷과 같은 공통 링크를 통하지 않고 데이터를 전송해야 하지만, PCIe 또는 메모리와 같은 특수 링크를 사용하려면 미들웨어를 사용자 정의해야 합니다. 다양한 링크의 통신 요구 사항을 지원할 수 있습니다.

"자율주행 소프트웨어 제조업체나 OEM에 따라 자체 로깅 방법이 있는 경우도 있고 그렇지 않은 경우도 있습니다. 로깅 기능을 제공하려면 미들웨어가 필요하므로 다양한 사용자의 역량에 따라 미들웨어가 해당 사용자 정의를 생성합니다.”

맞춤화란 표준화가 아닌 필요에 따라 미들웨어 제조업체가 인력을 배정하도록 하는 것인지, 알고리즘 회사/호스트 공장에서 전담 도킹 알고리즘 엔지니어를 파견하여 미들웨어를 수행하도록 하는 것인지를 의미합니다. 개인별 적응 및 조정에는 추가적인 인력과 재료가 필요합니다. 자원.

맞춤형 미들웨어는 알고리즘의 데이터 분석에 새로운 어려움을 야기합니다.

한 OEM 엔지니어는 퉁명스럽게 이렇게 말했습니다.

"V2X를 양산차에 탑재하는데, 모델별로 브랜드별로 미들웨어가 다르면 QoS(서비스 전략)도 달라집니다. .데이터 분석에 문제가 있어 차량 간 통신이 어려울 수 있습니다.”

한편, “미들웨어가 고도로 맞춤화되어 있어 AUTOSAR 표준을 우회하는 플레이어가 점점 많아지고 있습니다. "라고 OEM의 시스템 전문가는 말했습니다. 요즘에는 모든 회사가 자체 미들웨어를 개발하고 있으며 대부분의 미들웨어는 자체 알고리즘, 인터페이스 등에 적응할 뿐이며 불일치 현상이 더욱 심해지고 있습니다.

OEM이든 알고리즘 회사이든 미들웨어가 사용하기 쉬운지, 소프트웨어와 하드웨어가 분리되어 있는지를 고려하기보다는 프로젝트 협력 시 실제로 고려해야 할 것은 실제로 직면한 문제를 해결할 수 있는지 여부입니다. 구매한 미들웨어가 문제를 해결하지 못하고 원하는 효과를 얻지 못하는 경우 양측은 원래 미들웨어를 기반으로 다양한 콘텐츠를 수정하고 추가해야 하며 이는 지속적인 "결합" 상황으로 이어집니다. 피할 수 없는 현상이 되었습니다.

그래서 프로세스를 단순화하고 작업 부하를 줄이기 위한 미들웨어의 원래 의도를 되돌아보면 한숨이 나오지 않을 수 없습니다.

05 소프트웨어와 하드웨어의 분리를 어떻게 달성할 수 있나요?

그렇다면 소프트웨어와 하드웨어의 분리를 달성하려면 어떤 각도에서 시작할 수 있나요?

한편으로는 하드웨어 가상화를 운영 체제 수준에서 먼저 수행하고 인터페이스, 통신 프로토콜 등을 표준화할 수 있으므로 상위 계층 응용 프로그램은 기본 시스템의 다른 문제를 고려할 필요가 없습니다. 하지만 이를 위해서는 칩 제조사와 운영체제 제조사가 공동으로 심도 있는 협력을 이뤄야 하거나, 칩 제조사가 자체 OS를 개발해야 하기 때문에 여전히 어려움이 많다.

미들웨어의 미래 형태는 아직 불투명하지만, 한 가지는 확실합니다. 소프트웨어와 하드웨어의 분리는 여전히 미들웨어 형태로 해결되어야 하지만 미들웨어는 여러 가지 방식으로 차별화될 수 있습니다.

1. 미들웨어 벤더들은 Autosar 자체를 기반으로 Autosar를 단순화하는 툴형 미들웨어를 개발합니다. Autosar 자체는 매우 복잡하기 때문에 엔지니어가 배우기가 쉽지 않습니다. 개발 도구의 단순화된 버전을 제공할 수 있다면 자체 개발이 필요한 업스트림 및 다운스트림 제조업체에 이 도구를 제공하는 것이 좋을 것입니다. 미들웨어를 선택하고 자체 개발한 미들웨어 프로세스를 최적화합니다.

2. 미들웨어 공장, 메인 엔진 제조사 및 공급업체가 미들웨어 동맹을 형성하고, 칩 공장 또는 메인 엔진 공장이 주도하여 규칙을 통일합니다. 시장의 경계를 테스트할 때 매우 강력한 OEM 또는 칩 공장이 업계 표준을 형성하기 위해 표준을 통합하고 OS, 인터페이스 등을 통합하기 위한 업계 동맹을 형성하는 데 앞장설 것입니다.

3. 칩 회사가 만든 독점 OS를 갖춘 완전한 오픈 소스로, 업스트림 및 다운스트림 회사가 이를 기반으로 개발할 수 있습니다. 칩 제조업체는 자체 OS 및 미들웨어를 개발할 뿐만 아니라 완전한 오픈 소스인 NVIDIA의 CUDA와 같은 오픈 소스 툴킷을 만들어 업스트림 및 다운스트림 고객이 더 나은 적응 개발을 위해 도구를 함께 사용하고 좋은 생태계를 구축할 수 있도록 돕습니다.

4. 서비스로서 공급업체에 맞춤형 미들웨어 서비스 및 유지보수 업무를 제공합니다. 시장 천장이 낮고 미들웨어 통합이 어렵기 때문에 미들웨어는 독립된 제품이 아닌 맞춤형 서비스가 될 수 있습니다. 미들웨어 제조업체는 더 나은 미들웨어 연구 경험을 보유하고 있기 때문에 이러한 맞춤형 서비스를 제공할 수 있는 더 나은 위치에 있습니다.

과거 다양한 휴대폰 브랜드가 전성기를 누렸던 2005년부터 2010년까지 '브릭폰'과 스마트폰이 나란히 떠돌던 시절에는 최대 200개 이상의 휴대폰 인터페이스가 유통됐다. 시장. 휴대폰 브랜드마다 충전 인터페이스, 헤드폰 인터페이스, 모양이 같고 크기가 다른 크고 작은 인터페이스가 다르며, 같은 브랜드의 휴대폰이라도 충전 인터페이스가 다릅니다.

당시 디지털 전문가는 출장을 갈 때 충전기 5~6종과 케이블 5~6개를 챙겨가는 경우가 많았다. 나중에 범용 충전기가 있어도 태블릿폰의 배터리만 꺼내서 충전할 수 있습니다. 스마트폰의 충전 포트와 다양한 크기의 헤드폰 잭이 통합되지 않는 문제는 여전히 해결되지 않습니다.

이렇듯 혼란스럽고 무질서한 시기는 현재 스마트카의 발전과 마찬가지로 휴대폰 기술의 발전이 휴대폰 이후 가장 눈부시게 활발하게 발전하는 시기이기도 합니다. 오늘날 우리는 휴대폰 인터페이스가 기본적으로 통합되었음을 알 수 있습니다. 수백 개의 휴대폰 제조업체는 자체 연구 과정에서 점차적으로 그 수를 줄이고 마침내 시장의 최종 결정에 따라 표준을 형성했습니다.

스마트카 산업은 가전제품 시장, 특히 휴대폰 시장의 영향을 많이 받고 있습니다. 지난 2년 동안 업계 관계자 모두가 빨리 최종 단계로 나아가기를 바라는 마음이 매우 컸습니다. 매우 짧은 시간 내에 마스터를 선택합니다. 그러나 자동차 제조 산업은 실제로 자동차 생산부터 대량 생산, 그리고 소비자 시장까지 성장이 더딘 산업입니다. 수천만 명의 사용자로부터 피드백을 수집해야만 지속적으로 최적화하고 표준을 형성할 수 있습니다. 그리고 아마도 이때에만 미들웨어가 진정으로 통합되어 표준을 형성할 수 있을 것입니다.

향후 기술이 성숙해지면 미들웨어가 ASIC 칩에 굳어진 기본 소프트웨어로 활용될 수도 있으며, 더 이상 미들웨어 단독의 형태로 등장하지 않을지는 미지수입니다.

06 마지막으로 몇 마디

그런데 모든 당사자가 어려움을 겪고 있는 현재, 미들웨어에 적합한 사람은 누구입니까?

일반적으로 소프트웨어와 하드웨어의 분리를 완벽하게 구현하기 위해 표준 미들웨어를 사용하는 것을 목표로 한다면 실제로 가장 적합한 미들웨어는 칩 제조업체입니다.

두 가지 이유: 첫째, 알고리즘 적응은 궁극적으로 칩 플랫폼을 기반으로 하며 칩이 초석입니다. 둘째, 알고리즘 회사에 비해 칩 회사 수가 적고, 이들을 통합하는 것이 상대적으로 덜 어렵다.

하지만 현재는 모두가 맞춤화를 기대한다는 전제하에 맞춤형 미들웨어에는 알고리즘 회사가 가장 적합합니다.

"칩 회사는 검증 메커니즘 추가 여부, BSP 일정 및 가속화 방법 등 칩 자체의 적용에 더 많은 관심을 기울입니다. 칩 회사는 이러한 요구 사항을 구현할 수 있지만 칩 회사는 더 나은 솔루션을 제안할 수 없습니다. 응용 소프트웨어 및 미들웨어 사용자는 성숙한 솔루션만 사용하는 것이 좋지만 이 솔루션은 소프트웨어의 모든 요구 사항을 충족하지 못할 수 있습니다. 알고리즘 회사는 비즈니스 실무에서 가장 많은 사용자 정의 요청을 받고 있음을 알 수 있습니다. 대부분의 미들웨어 적응 역할은 자신의 알고리즘에 맞는 맞춤형 미들웨어를 직접 만드는 것이 가장 편리합니다.

특정 OEM의 수석 엔지니어도 같은 견해를 갖고 있습니다.

"현재로서는 상위 기능 서비스에 상대적으로 중점을 두고 있습니다. 자율주행 솔루션 공급업체는 기능적 응용에 대해 깊은 이해를 갖고 있으며, 애플리케이션 계층은 기본 주류 칩 하드웨어 솔루션 제공업체와 더 잘 일치할 수 있으며 전체 솔루션이 더 합리적입니다.”

위 내용은 자율주행 소프트웨어와 하드웨어 디커플링 기술 및 동향 연구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!