소프트웨어 정의 자동차 구현을 위한 5가지 핵심 요소를 논의한 기사

1 아키텍처 업그레이드

1.1 소프트웨어 아키텍처: 계층적 분리, 서비스화, API 인터페이스 표준화

기업이 소프트웨어 정의 자동차 개발 방식으로 전환함에 따라 소프트웨어 아키텍처도 동시에 업그레이드해야 합니다. -SOA(지향 아키텍처) 방법론. 자동차 SOA는 차량 인텔리전스의 기본 기능을 구성합니다. 자동차의 하드웨어 성능과 다양한 기능이 서비스로 구현됩니다. 이러한 서비스는 SOA 표준 기반 인터페이스로 설계되고 SOA 표준 프로토콜을 기반으로 통신합니다. 이렇게 각 서비스 구성요소가 서로 접근할 수 있게 되어 서비스 결합 형태가 확장된다.

그림 1 SOA 서비스 지향 아키텍처의 개략도

SOA의 도입으로 인해 자동차의 기존 폐쇄적이고 견고한 소프트웨어 시스템이 점차 개방적이고 재사용 가능한 소프트웨어 생태계로 변모했습니다. 계층화된 분리된 SOA 서비스 지향 아키텍처를 기반으로 하는 새로운 소프트웨어 아키텍처 업그레이드에서는 장치 추상화 및 원자 서비스를 사용하여 하드웨어 기능의 전체 서비스화를 실현합니다. 특정 개체에는 컨트롤러 주변의 센서, 액추에이터 및 기존 버스 통신이 포함됩니다. , 컨트롤러의 자체 진단 및 저장 장치도 포함됩니다. 동시에 "논리적 의미 변환"이라는 설계 아이디어를 기반으로 인터페이스 표준화를 완료하고 다양한 플랫폼과 모델에 대한 인터페이스 재사용성 목표를 달성합니다.

그림 2 SOA 아키텍처 하의 기본 서비스 예시

인프라와 개발 방식의 변화로 '소프트웨어 정의 자동차'는 자동차 개발 프로세스 전체를 뒤흔들 것이며, 이를 기반으로 한 소프트웨어 아키텍처 솔루션은 SOA 스마트 자동차 시스템에 대한 중요한 서비스 추상화를 제공합니다. 엄격한 캡슐화 및 계층 구조는 민첩한 개발 방법 및 인터페이스 테스트의 사용을 지원하고 시스템의 복잡성을 줄여 차량 업데이트 시 소프트웨어 구성 요소의 재사용을 크게 단순화합니다.

그림 3 소프트웨어 계층 아키텍처의 개략도

아키텍처 표준화:

계층 아키텍처는 원래 차량 아키텍처에 원자 서비스 계층과 장치 추상화 계층을 도입합니다.

• 장치 추상화 계층은 기본 하드웨어 차이점을 캡슐화하고 원자 서비스 계층이 호출할 서비스 형태로 하드웨어 계층의 특성과 인터페이스를 제공하는 역할을 합니다. 시스템 소프트웨어가 제공하는 인터페이스. 애플리케이션 로직은 기본 하드웨어 플랫폼의 제약에서 벗어나 중간 계층 역할을 하며 플랫폼에서 분리되어 상위 측에서 애플리케이션 서비스를 호출합니다. 차량 모델의 ​​차이와 구성 적응을 반영하는 하위 측의 장치 추상화로 차량 모델 전반에 걸쳐 상위 계층 애플리케이션을 재사용할 수 있습니다.
• 애플리케이션/구성 계층 서비스는 주로 사용자 요구 로직의 실현을 담당합니다. , Atomic Service Layer에서 제공하는 인터페이스를 호출하여 끊임없이 변화하는 시나리오 기반 애플리케이션을 결합합니다.
• 인터페이스 표준화:

모델 및 부품 공급업체 전반에서 재사용을 극대화하고 소프트웨어 정의 자동차 소프트웨어 및 하드웨어 개발의 복잡성을 줄입니다.

건축표준화를 바탕으로 자동차 회사 전반에 걸쳐 소프트웨어를 어떻게 사용할 수 있나요? 서로 다른 OEM, Tier1 및 플랫폼 공급업체가 동일한 서비스 인터페이스 세트를 정의하므로 서로 다른 OEM과 Tier1 간의 소프트웨어가 서로 호출할 수 있으므로 소프트웨어 수가 크게 늘어납니다. 재사용성은 차량을 단축시킵니다. 개발주기.

인터페이스 표준화 촉진 측면에서 중국 자동차 제조업체 협회는 700개 이상의 API를 포함하는 "소프트웨어 정의 자동차 원자 서비스 API 인터페이스 및 장치 추상화 API 인터페이스 참조 사양"의 제3판을 출시했습니다. 차체 제어, 열 관리, 에너지 관리, 모션 제어, 지능형 주행 도메인, 파워 도메인, 섀시 도메인 등 다양한 기능 도메인이 있습니다. 인터페이스 표준화 정의에 참여하는 회원사에는 OEM, 부품, 기본 회사 등 100개 이상의 회사가 포함됩니다. 플랫폼 공급업체 및 소프트웨어 공급업체입니다.

1.2 통신 아키텍처: 차량 내 이더넷 기반 기술 적용

차량 기능이 지속적으로 증가하고, 특히 자율주행과 스마트 콕핏이 지속적으로 발전하면서 전송해야 할 신호가 폭발적으로 늘어나고, 차량 기능 지속적인 업그레이드와 업데이트로 인해 사용자는 OTA 업그레이드 경험에 대한 더 높은 요구 사항을 제시했습니다. 기존의 CAN 버스 통신 방식은 더 이상 차량 기능의 성장 속도를 충족할 수 없습니다. 이더넷 서비스를 기반으로 한 통신 방식을 사용하면 차량 기능을 유연하게 재구성할 수 있습니다. 신호 중심 통신 아키텍처에서 개별 신호의 추가, 삭제/변경은 기능적으로 관련된 모든 시스템의 변화로 이어집니다.

차량 이더넷과 이것이 지원하는 상위 계층 프로토콜 아키텍처는 아래 그림에 나와 있습니다. 차량 이더넷은 주로 OSI 레이어 1 및 2 기술을 포함하며 AVB, TCP/IP, DoIP, SOME/IP도 지원합니다. DDS 및 기타 다양한 프로토콜 또는 신청서.

그림 4 차량 이더넷 및 지원되는 상위 계층 프로토콜 아키텍처

SOME/IP는 다음을 의미합니다. IP 기반의 확장 가능한 서비스 지향 미들웨어인 IP 기반의 확장 가능한 서비스 지향 미들웨어 소프트웨어에는 2013년 AUTOSAR 4.1 사양에 통합되었습니다.

그림 5 서비스 지향 SOME/IP 미들웨어 지원

통신 아키텍처 업그레이드 이후에 발생한 변화:

• 더 유연한 통신 메커니즘: CAN 버스는 브로드캐스트 통신, 멀티 -마스터 모드는 각 노드가 보낸 정보가 모든 통신 매체를 차지하지만 수신 노드가 정보 수신 여부를 선택할 수 있도록 작동합니다. 이더넷은 일대일 또는 일대다의 두 가지 방식으로 통신합니다. 일대일 방식에서는 송신 노드의 메시지가 일대다 방식으로 자신의 주소를 다루고, 송신 노드의 메시지에는 자신과 수신 노드의 주소가 포함됩니다. 다른 노드의 통신에는 영향을 주지 않습니다.
• 더 높은 대역폭, 더 낮은 대기 시간: 차량 내 데이터 전송의 총량과 전송 속도에 대한 요구 사항이 계속 증가하고 있으며 산업 간 표준 프로토콜에 대한 수요로 인해 더 많은 애플리케이션 시나리오와 더 빠른 속도를 지원합니다. 이더넷이 CAN/LIN과 같은 전통적인 자동차 내부 통신 네트워크를 대체하는 것은 불가피해졌습니다.
• 더 많은 애플리케이션 시나리오, 쉬운 상호 연결 및 쉬운 확장: 차량 내 이더넷과 차량 외부 네트워크는 동일한 프로토콜을 기반으로 하며 차량 외부 네트워크와 통신할 때 인터페이스 전환이 더 원활합니다. 기존의 차량 내 통신 네트워크는 고유한 네트워크 프로토콜을 기반으로 하며 차량 외부 네트워크와 상호 작용할 때 인터페이스 표준화가 좋지 않아 다른 시스템의 프로토콜을 변환해야 합니다. 네트워킹 추세에 따라 자동차 이더넷의 프로토콜 변환 비용은 훨씬 더 적습니다.
• 더 빨라진 OTA 업그레이드 속도, 사용하기 쉬운 경험: OTA 업그레이드에 이더넷을 사용하면 기존 CAN 업그레이드보다 통신 속도가 10배 이상 높아 사용자의 대기 시간이 크게 줄어듭니다. 서비스 기반 통신 SOME/IP를 사용하면 기능의 유연한 재구성을 실현할 수 있으며, 기능적 요구 사항을 핵심으로 하는 기존 아키텍처에서 개별 기능의 증가 또는 감소/변경 문제를 효과적으로 해결하여 기능 변경이 필요하게 됩니다. 관련 시스템을 개선하고 시스템 OTA 업그레이드의 필요성을 줄입니다.

1.3 하드웨어 아키텍처: 지역 액세스 + 컴퓨팅 파워 중앙화

차량 전체 전자 및 전기 아키텍처는 현재 시장에 판매되는 대부분의 전통 자동차가 소프트웨어 정의 자동차를 구현하는 초석입니다. 전자 및 전기 아키텍처는 아래 그림에 나와 있습니다.

그림 6 전통적인 분산 전자 및 전기 아키텍처의 개략도

분산 전자 및 전기 아키텍처에서는 차량 기능이 먼저 전력 제어, 섀시 제어, 능동적 안전, 수동적 안전, 지능형 주행, 인포테인먼트 및 차체 등 그런 다음 각 모듈의 기능을 더욱 세분화합니다. 예를 들어 본체 기능은 조명 제어, 도어 제어, 좌석 제어 등의 기능으로 세분화됩니다. 다양한 전자 제어 기능은 독립적인 전자 제어 장치(ECU)를 사용하여 구현되며, 다양한 ECU는 CAN/CAN FD를 통해 통신합니다.

각 ECU는 서로 다른 공급업체에 의해 개발되고 내장 소프트웨어와 기본 코드가 다르기 때문에 분산된 전자 및 전기 아키텍처는 차량 수준에서 많은 중복성과 BOM 비용을 발생시킵니다. 또한, 차량 내 소프트웨어는 다양한 ECU에 배포되고, ECU는 각 공급업체가 독립적으로 완성하기 때문에 해당 소프트웨어와 하드웨어가 긴밀하게 결합되어 있으며 OEM은 ECU의 소프트웨어를 유지 관리하고 업데이트할 권한이 없습니다. .

OEM이 시장 점유율을 확보하려면 사용자 요구 사항을 빠르게 충족하는 것이 중요하며, 분산된 전자 및 전기 아키텍처는 OEM이 시장 수요에 대응할 수 있는 속도를 심각하게 제한합니다. 특정 자동차 모델의 디자인이 완료된 후 사용자가 운전자 위치 기억 기능을 추가할 것을 제안한다고 가정해 보겠습니다. 즉, 운전자가 차량의 좌석, 핸들, 외부 거울 및 기타 관련 시스템을 편안한 위치로 조정한 후 사용자는 이후의 빠른 조정에 편리하게 메모리 위치를 설정할 수 있습니다. 도어 컨트롤러, 시트 컨트롤러, 스티어링 휠 컨트롤러 및 게이트웨이와 같은 여러 구성 요소에 대한 소프트웨어 변경이 필요합니다. 각 구성 요소 공급업체가 변경을 완료하고 OEM이 통합 테스트 및 차량 테스트를 완료한 후에만 소프트웨어를 변경할 수 있습니다. 시장에 출시하게 되면 개발 및 변경 주기가 길어지고 비용이 많이 드는 등의 문제가 발생하게 됩니다.

이를 위해 다양한 자동차 제조업체는 소프트웨어 정의 자동차의 신속한 구현을 촉진하기 위해 이미 새로운 전자 및 전기 아키텍처 솔루션을 예약하기 시작했습니다. 새로운 전자 및 전기 아키텍처의 특징은 기능(소프트웨어)의 집중화와 하드웨어의 표준화입니다. 중앙 컴퓨팅 플랫폼/도메인 컨트롤러를 통한 제어 기능의 통합 관리는 하드웨어 중복성과 BOM 비용을 줄여 수많은 공급업체에 대한 OEM의 의존도를 줄입니다. 새로운 전자·전기 아키텍처는 기능 집중도에 따라 크게 세 가지 유형으로 구분된다.

첫 번째: 도메인 중앙 전자 및 전기 아키텍처

도메인 중앙 전자 및 전기 아키텍처에서는 차량 전자 및 전기 제어 기능을 N개의 기능 도메인으로 나누고 각각에 대해 하나의 도메인을 설계합니다. 기능 도메인 다른 컨트롤러는 도메인 내 컨트롤러이며, 각 도메인의 컨트롤러는 일반적으로 스마트 센서, 액추에이터 및 기존 컨트롤러입니다.

아래 그림은 도메인 중앙 집중식 전자 및 전기 아키텍처의 개략도를 보여줍니다. 이 예에서 차량의 전자 및 전기 제어 기능은 전력 도메인, 섀시 안전 도메인, 지능형 주행의 5가지 기능 도메인으로 구분됩니다. 도메인, 인포테인먼트 도메인 및 신체 편안함 도메인.

그림 7 도메인 중앙 집중식 전자 및 전기 아키텍처의 개략도

두 번째 유형: 교차 도메인 중앙 집중식 전자 및 전기 아키텍처

도메인 중앙 집중식 전자 및 전기 아키텍처, 도메인 제어 컨트롤러는 도메인 간 중앙 집중식 전자 및 전기 아키텍처에서 하나의 도메인 기능에 대한 중앙 집중식 제어만 담당하며 일부 도메인 컨트롤러는 두 개 이상의 도메인 기능에 대한 중앙 집중식 제어를 담당하여 기능 통합을 더욱 향상시킵니다. 시스템. 보다 일반적인 교차 도메인 중앙 집중식 전자 및 전기 아키텍처는 3개 도메인 아키텍처입니다. 교차 도메인 중앙 집중식 전자 및 전기 아키텍처의 개략도는 아래 그림에 나와 있습니다.

그림 8 교차 도메인 중앙 집중식 전자 및 전기 아키텍처의 개략도

3개 도메인 아키텍처는 각각 차량 제어 도메인, 지능형 운전 도메인 및 지능형 조종석 도메인을 결합합니다. 파워 도메인, 섀시 안전 도메인, 차체 안락 도메인은 차량 제어 도메인에 통합되며, 지능형 주행 도메인과 스마트 콕핏 도메인은 차량 지능과 연결성 구현에 중점을 둡니다.

3개 도메인 아키텍처에는 3개의 도메인 컨트롤러가 있습니다.

차량 도메인 컨트롤러는 차량 제어를 담당하며 실시간 및 안전에 대한 높은 요구 사항을 갖습니다.

지능형 운전 도메인 컨트롤러는 다음을 담당합니다. 자율주행 관련 인식, 계획, 의사결정 관련 기능 구현

지능형 조종석 도메인 컨트롤러는 HMI 상호작용 및 조종석 관련 기능 구현을 담당합니다.

세 번째 유형: 지역적 접근 + 중앙 집중식 전자 및 전기 아키텍처

중앙 집중식 전자 및 전기 아키텍처는 더 이상 기능에 따라 차량에 전자 및 전기 시스템을 배치하지 않고 차량의 모든 기능 영역의 제어 로직을 중앙 컴퓨팅 플랫폼에 집중하여 시스템 기능 통합을 더욱 향상시킵니다. 원래의 분산 및 도메인 중앙 집중식 아키텍처에서 ECU의 제어/컴퓨팅 기능은 중앙 컴퓨팅 플랫폼에 흡수되어 더 간단한 센서 또는 액추에이터로 변환됩니다.

와이어 하니스의 길이를 줄이고, 통신을 단순화하고, 인근 액세스 및 전원 공급을 제공하기 위해 중앙 집중식 아키텍처 하에서 영역을 물리적 위치에 따라 분할하고 지역 컨트롤러를 해당 영역 내에 배치하여 중앙 컴퓨팅 플랫폼 및 다중 지역 컨트롤러 아키텍처, 중앙 집중식 전자 및 전기 아키텍처의 개략도가 아래 그림에 표시됩니다.

그림 9 중앙 집중식 전자 및 전기 아키텍처의 개략도

하드웨어 아키텍처의 업그레이드는 도메인 간 기능, SOA 아키텍처 아래의 소프트웨어 기능 계층화 및 사후 서비스의 통합도 고려해야 합니다. 실시간 기능 안전 설계, 복잡한 하드웨어 설계 및 통합 등을 제어합니다.

2 보안 업그레이드: 다층 차량 심층 방어 시스템 구축

2.1 기능 안전

전자 및 전기 아키텍처 기술의 지속적인 업그레이드로 인해 점점 더 많은 시스템과 부품이 기능안전에도 영향을 미치기 때문에 기능안전 역시 일부 핵심 시스템의 개발에서 차량 전체의 모든 시스템을 포괄하는 개발로 확대됐다.

동시에 도메인 컨트롤러 및 중앙 컴퓨팅 플랫폼과 같은 새로운 아키텍처 기술의 출현으로 인해 기능 안전에 대한 새로운 기술적 과제가 제기되었습니다. 이러한 복잡한 시스템 및 소프트웨어에 대한 개발 및 평가 방법을 확립해야 합니다.

기능 안전 기술은 전통적인 오류 방지(Fail-Safe)에서 오류 작동(Fail-Operational)으로 진화하면서 전자 및 전기 아키텍처 기술의 발전에도 영향을 미치며 전자 및 전기 아키텍처 설계에 더 많은 중복성이 도입됩니다. 전기적 아키텍처(예: 통신 이중화, 이중화 컨트롤러 등) 및 보안 조치.

미래에는 지능형 자동차 생태계 형성을 통해 기능안전 기술을 자전거를 넘어 전체 링크로 확장해 전체 지능형 생태계의 종합적 안전성을 달성하게 될 것입니다.

2.2 예상되는 기능 안전

전자 및 전기 아키텍처와 관련하여 예상되는 기능 안전은 기능 부족이나 합리적으로 예측 가능한 인간의 오용으로 인해 발생하는 인체 위험을 방지하는 것을 의미합니다. 기능 안전 기술은 자동차 기술의 일부가 될 것으로 예상되며 해당 표준은 ISO 21448입니다. 자율주행 기능과 그 동작 설계 영역을 기반으로 기대되는 기능안전 요구사항을 충족하는 시스템 구성 방식을 분석하고, 시스템 구성 방식을 기반으로 적절한 전자, 전기 아키텍처 방식을 결정 또는 선택합니다. 기대되는 기능적 안전성의 핵심 기술 포인트:

(1) 자율주행 안전기준 공식화 기술: 알려진 시나리오와 알려지지 않은 시나리오에서 자율주행의 안전 성능에 대한 객관적인 정량적 기준을 개발하여 자율주행의 안전 수준을 과학적으로 결정합니다.

(2) 안전 분석 기술: STPA와 같은 안전 분석 방법을 사용하여 자율 주행 안전 관련 기능의 부족한 성능 제한 및 위험 유발 조건을 식별하고 목표 대책을 수립하며 기능 업데이트를 수행합니다.

(3) 다중 기둥 접근 테스트 기술: 시뮬레이션 테스트, 설정 시나리오 테스트 및 실제 도로 테스트로 구성된 자율 주행 기대 기능 안전 테스트 시스템

(4) 안전 실증 기술: 안전 개발, 분석, 테스트, 등, 예상되는 기능 안전 파일 개발 전략, GSN 및 기타 시연 방법을 통해 자율 주행의 안전 위험을 평가하고 예상되는 기능 안전 릴리스를 완료합니다.

(5) 안전 모니터링 기술: 작동 중 안전 성능을 모니터링합니다. 자율주행의 안전운행을 보장하기 위해 온보드 및 원격 수단을 통해 안전 위험을 식별하고 필요한 위험 관리 조치를 수행합니다.

2.3 네트워크 보안

스마트 자동차 단말기, 통신 파이프라인, 클라우드 플랫폼, 모바일 애플리케이션 모두 일련의 정보 보안 위협에 직면해 있습니다. 자동차 사이버 공간 차원에서 시작하여 다양한 기술 협력, 다양한 수단 보완, 외부에서 내부까지의 다단계 보안 방어선 구축을 통해 차량 정보 보안 보호의 깊이, 균형 및 무결성에 대한 요구 사항을 충족합니다. 네트워크 보안, 인트라넷 보안, ECU 보안 관점에서 차세대 차량 전자 및 전기 아키텍처를 기반으로 해당 보호 조치를 구현하고 배포하는 것이 필요합니다.

그림 10 스마트 자동차를 위한 포괄적인 네트워크 보안 방어

네트워크 보안

네트워크 액세스 계층은 주로 DOS, PING 유형 및 이더넷을 대상으로 하는 잘못된 메시지, 스캔 블래스팅, 속임수, 트로이 목마 및 기타 네트워크 공격. 자동차-클라우드 연계 메커니즘의 능동적인 보안 보호 기능이 필요하며, 클라우드 시스템을 통해 실시간으로 보호 전략을 구성할 수 있으며, 여기에는 주로 액세스 인증 메커니즘, 통신 보호 메커니즘, 이더넷 방화벽 메커니즘 및 침입 탐지가 포함됩니다. 및 예방(IDPS) 메커니즘.

차량 내 네트워크 보안

차량 내 네트워크 보안은 주로 패킷 모니터링, 오류 주입, 패킷 재생 및 기타 공격을 포함하여 차량 CAN/CAN FD 및 차량 이더넷에 대한 공격에 저항합니다. 보호 전략에는 버스 침입 탐지 메커니즘, 인트라넷 방화벽 메커니즘, 기능적 도메인 격리 메커니즘, 버스 통신 보호 메커니즘 및 진단 보안 보호 메커니즘이 포함됩니다.

주요 ECU 보안

차량 시스템이나 주요 데이터가 파괴되지 않도록 차량의 주요 ECU 수준에는 안전한 시동, 주요 데이터의 안전한 저장, 안전한 시스템 운영 및 애플리케이션 실행에 사용될 수 있으며 권한 관리 기능을 제공합니다.

서비스 보안

SOA 보안 프레임워크는 정보 암호화, 디지털 서명, 비밀번호 인증 및 액세스 제어 목록 설계를 통해 기밀성, 무결성, 신뢰성, 권한 부여 및 가용성의 5가지 기본 원칙을 따라야 합니다. 다양한 솔루션 및 ACL 및 DOS 공격 모니터링과 같은 제품은 네트워크 정보를 검색, 액세스, 전달 및 모니터링하는 동시에 네트워크 보안을 실현합니다.

그림 11 차량 SOA 서비스 네트워크 보안 원칙

• 서비스 검색에서 서비스 브로드캐스트 메시지가 필요한 서비스 사용자에게만 전송되도록 정보 보안 그룹 격리 메커니즘을 설정합니다. 서비스 액세스 측면에서 서비스 제공자를 위한 정보 보안 액세스 제어 메커니즘을 설정하고 서비스 사용자가 시작한 서비스 요청을 인증 및 승인합니다.
• 서비스 통신 측면에서 SOA 서비스의 실제 비즈니스 적용 시나리오를 기반으로 SOA를 결정합니다. 메시지에 사용해야 하는 정보 보안 전송 메커니즘
• 서비스 모니터링 측면에서 SOA 서비스와 관련된 이상 이벤트를 발견하기 위한 서비스 보안 모니터링 메커니즘과 보안 응답 처리 메커니즘을 설정합니다.
3 프로세스 변경: Agile Development, Iterative Release

자동차의 기능은 날이 갈수록 변하고 있으며, 소프트웨어 코드의 양은 날로 증가하고 있습니다. 전통적인 V 모델 하에서의 폭포식 개발. 고객에게 신속하게 제공하기 위해서는 가장 긴급하게 필요한 기능이며, 소프트웨어 개발 프로세스의 전환이 중요합니다. 현재 점점 더 많은 자동차 부품 공급업체가 민첩한 개발로 전환하고 있습니다. 소프트웨어와 하드웨어의 분리를 실현하는 시스템 아키텍처와 시스템 소프트웨어, 미들웨어, 애플리케이션 소프트웨어의 계층적 아키텍처를 기반으로 소프트웨어 기능의 신속한 반복과 출시가 이루어지므로 OEM이 빠르게 시장을 점유할 수 있습니다.

애자일 개발 프로세스의 핵심은 R&D 인력의 협업의식, 책임의식, 품질의식, 학습의식, 혁신의식을 함양하여 전체 소프트웨어 R&D팀의 R&D 역량을 향상시키고 고품질 소프트웨어를 효율적으로 개발하는 것입니다. 제품. 기능 개발은 월별 개발 주기를 갖는 반복 개발 모델을 채택합니다. 이는 세부 설계 및 검토, 기능 개발 및 코드 판독, 코드 품질 검사 및 평가, 테스트 케이스 설계 및 작성, 기능 기능 공동 디버깅, 기능 통합 검토, 등 하위 프로세스. 각 하위 프로세스에는 특정 출력(설계 문서, 소스 코드, 검토 보고서, 테스트 사례, 테스트 보고서 등)과 정량적 평가 시스템(설계 문서 장의 완성도, 증분 코드 측정 보고서, 검토 의견 밀도, 테스트 사례 적용 범위)이 있습니다. ), 결함 밀도 등), 각 하위 프로세스가 소프트웨어 개발 품질 요구 사항에 따라 달성되었는지 확인하고 모든 문서를 보관하여 소프트웨어 품질 추적성을 지원합니다.

버전 릴리스는 매주 릴리스 주기를 갖는 소프트웨어 버전의 빠른 반복 모드를 채택합니다. 버전은 매주 안정적인 지점에서 릴리스되며 소프트웨어의 기본 기능과 새로운 기능이 완전히 검증되고 해결된 문제에 대한 회귀 테스트가 수행됩니다. 문제가 수행되고 모두 통과됩니다. 나중에 버전을 출시하세요. 민첩한 개발의 비즈니스 가치:

• 사용자 경험은 월 단위로 공개될 수 있습니다.
• 취약점과 패치는 매주 빠르게 출시됩니다.
• 소프트웨어 버전은 매시간 반복되며 구성 요소와 차량은 동기식으로 통합되고 자동으로 확인됩니다(7*24시간 무인).

4 툴체인 업그레이드: SOA 기반의 차량 서비스 개발

SOA의 전체적인 아이디어는 서비스 모델을 설계하고, 다양한 기본 서비스를 추출하고, 계층적 디커플링을 통해 적절한 API 인터페이스를 정의하고, Call을 적용하는 것입니다. 비즈니스 로직을 구현하기 위한 서비스 API 인터페이스입니다. API 인터페이스 정의는 서비스를 구현하는 하드웨어 플랫폼, 운영 체제 및 프로그래밍 언어와 독립적이므로 다양한 시스템에 구축된 서비스가 통합되고 보편적인 방식으로 상호 작용할 수 있습니다.

자동차 산업에서 SOA는 효과적인 프로세스, 방법 및 도구 체인 세트가 필요한 새로 도입된 기술입니다. 현재 업계에는 매우 성숙한 방법론과 도구 체인이 없습니다. OEM과 Tier1/Tier2는 탐색 단계에 있습니다. 아래 그림은 서비스 기반 기능 개발 프로세스 방법을 보여줍니다. 그림 12 서비스 아키텍처 설계, 서비스 설계 및 통신 설계를 포함한 서비스 기반 기능 개발 프로세스 방법

서비스 정의는 중국 자동차 제조업체 소프트웨어 정의 자동차 작업 협회에서 발표한 API 인터페이스 참조 사양을 기반으로 해야 합니다. 그룹.

5 산업분업 고도화 : 합리적인 분업, 열린 협업

미래 스마트카 시대를 맞이하여, 본래의 산업 가치사슬이 무너지기 시작하면서 전통 자동차 회사들도 속속 변화하고 있으며, 새로운 세력이 부상하기 위해 고군분투하고 있으며, 날마다 기술 진보가 변화하고 있으며, 모든 국경을 넘는 플레이어가 게임에 참여하고 있으며, 한편으로는 산업 경쟁의 요소와 형태가 조용히 변화하고 있습니다. 새로운 산업 패턴을 형성하는 동시에 새로운 산업 생태계의 출현을 낳고 있습니다. 스마트카 산업은 이전에 없었던 다양한 신기술 분야가 등장하면서 더욱 다양하고 복잡한 방향으로 발전하고 있습니다. 열린 협력만이 윈윈(win-win) 결과를 얻을 수 있고, 상호 보완적인 장점이 시너지를 낼 수 있습니다.

5.1 종합 추천

앞서 언급했듯이 자동차 산업은 전동화와 지능화로 진화하고 있으며, 기술, 사용자 경험 등이 자동차 산업의 급속한 성장을 견인하고 있습니다. 스마트카가 점진적으로 발전함에 따라 차량 소프트웨어와 하드웨어의 복잡성도 지속적으로 증가하고 있습니다. 소프트웨어 정의 자동차로의 전환은 업계의 합의가 되었습니다. 그러나 소프트웨어 정의 자동차는 아직 초기 단계입니다. 소프트웨어의 대규모 도입으로 인해 자동차 산업은 설계 및 개발, 통합, 테스트, 출시 및 유지 관리 등 일련의 과제를 안고 있습니다. 소프트웨어와 하드웨어 조합의 복잡성을 적절하게 관리해야만 소비자의 경험 요구를 지속적으로 충족하고 시장 경쟁력을 형성할 수 있습니다.

계층적 분리는 소프트웨어 재사용성을 향상시키고 소프트웨어 및 하드웨어 개발의 복잡성을 줄이는 핵심 수단이기도 합니다. 계층적 분리를 통해 소프트웨어와 하드웨어가 분리될 수 있고, 애플리케이션이 기본 플랫폼에서 분리될 수 있다. 그러나 이를 어떻게 구현하느냐가 핵심 과제가 되었고, 소프트웨어 정의 자동차의 전략적 목표와 가치에 직접적인 영향을 미칠 것이다. 기술적 관점에서 아키텍처를 계층화하는 방법과 재사용을 극대화하고 개발, 유지 관리 및 장기적인 발전을 단순화하기 위해 서비스를 분할하는 방법이 주요 과제입니다. 합리적이고 안정적이며 통일된 서비스 부문만이 소프트웨어 정의 자동차의 가치를 극대화할 수 있습니다. 산업 체인의 관점에서 볼 때, 모든 당사자가 모든 당사자의 최대 이익을 보장하기 위해 어떻게 배치하고, 노동을 분배하고, 협력하는지가 핵심적인 어려움입니다. 개방성, 협력 및 상생은 소프트웨어 정의의 신속한 구현을 위한 기반입니다. 자동차.

전체 권장 사항:

기술 사양 통일성 및 합리적인 산업 분업 측면에서 자동차 산업 체인의 업스트림 및 다운스트림 기업 간의 협력과 협력을 강화하고 스마트 자동차 소프트웨어 및 하드웨어 인터페이스의 표준화를 공동으로 촉진합니다. 애플리케이션, 기본 플랫폼 및 하드웨어의 계층화된 분리를 실현하고, SOA 서비스 아키텍처와 인터페이스 표준화 및 통합을 구축하여 모델 및 부품 공급업체 전반에서 재사용을 극대화하고, 맞춤화를 줄이고, 혁신을 가속화하며, 협업 효율성을 향상시킵니다. 스마트카 산업의 대표주자입니다. 동시에, 계층 구조를 기반으로 산업 체인의 모든 당사자의 요구와 이점이 결합되어 합리적인 노동 분업이 형성되어 완전한 협력을 달성합니다.

구체적인 제안:

• 장치 추상화 계층에서 장치와 포트의 분리를 실현하고 하드웨어 기능 차이와 제조업체 차이를 보호합니다. 이 계층은 업계에서 공동으로 정의하고 표준화합니다.
• 기본 플랫폼 계층은 기본 소프트웨어와 하드웨어의 분리를 실현하여 장치와 드라이버 간의 차이를 보호합니다.
• Atomic 서비스 계층에서는 서비스와 플랫폼의 분리를 실현하여 소프트웨어 재사용성을 향상하며 이 계층이 공동으로 정의됩니다.
• 애플리케이션/결합 서비스 계층에서는 애플리케이션과 서비스의 분리를 실현하고, 차량 모델 전반에 걸쳐 애플리케이션을 재사용하며, 이 계층을 OEM이 주도하는 것이 좋습니다.

그림 13 소프트웨어 정의 자동차 산업의 협력에 대한 전반적인 권장 사항

동시에 API 표준화가 업계 경쟁, 표준 개방성 및 제품 경쟁의 균질화를 의미하지는 않습니다. OEM 및 부품 공급업체는 핵심 기술의 핵심 경쟁력을 계층적으로 구축하고, 협업을 통해 관리 역량을 구축하여 효율성과 규모를 향상시키며, 비즈니스 모델에 보호 메커니즘을 구축하여 배타적/선점자 우위를 보장함으로써 궁극적으로 사용자에게 직면할 수 있습니다. 고부가가치 제품.

동시에 서로 다른 제조업체의 하드웨어, 소프트웨어, 플랫폼 등은 상호 운용 가능합니다. 즉, 서로 다른 모델과 서로 다른 구성 요소가 동일한 언어를 사용하여 도메인 간 통화를 완료하고 정보를 교환 및 공유할 수 있습니다. 산업 체인의 모든 사람과 기업 모두가 혜택을 받습니다.

OEM의 경우:

• 보다 간편한 관리: 객체 지향 소프트웨어 관리 모델로 전환한 소프트웨어 Onetrack을 사용하면 보다 복잡한 차량 소프트웨어 시스템 및 공급업체를 보다 쉽게 ​​관리할 수 있으며 통합 기능에 집중하여 경쟁력을 구축할 수 있습니다.
• 더 빠른 출시 시간: SOA 및 서비스 API를 기반으로 한 효율적인 소프트웨어 개발을 통해 모델 출시 속도를 가속화할 수 있습니다.

부품 공급업체의 경우:

• 맞춤화 감소: 부가가치가 없는 복잡한 작업을 줄이고 다양한 모델에 대한 개발 및 유지 관리 비용을 줄입니다.
• 혁신 가속화: 혁신과 구축에 집중할 인재를 배출합니다. 차별화된 기술과 제품.

소프트웨어 개발 회사/개발자의 경우:

• 더 쉬운 시작: 이해하기 쉬움, 개발 리소스 통합, 신속한 개발
• 더 많은 기회: 국경을 초월한 재능과 새로운 사고가 도입됩니다. 자동차 산업은 시장 후 가치를 지속적으로 채굴하여 실현할 여지를 더 많이 제공합니다.

5.2 OEM

OEM은 최종 사용자를 직접 대면하고, 사용자 요구 사항을 충족하는 자동차 제품을 제공하고, 소프트웨어와 하드웨어, 애플리케이션 기능 및 생태학적 서비스를 통합하여 완전한 차량 제조에서 장기 여행 서비스까지의 제공을 완료합니다.

자동차 제조사는 자동차 제조사일 뿐만 아니라 소비자에게 모바일 여행 관련 서비스를 제공하고, 소프트웨어 개발, 구성, 반복적인 업그레이드를 통해 사용자의 다양한 자동차 요구를 충족시킵니다. 사용자는 소프트웨어를 통해 자동차 제품의 다양한 기능을 설정할 수 있으며, 개인 취향에 따라 여행 장면을 편집하거나 특정 장면 기능을 다운로드할 수도 있습니다. 이를 위해 OEM은 다음 플랫폼의 구축 및 개발을 완료해야 합니다.

1) 하드웨어 플랫폼 통합

하드웨어 플랫폼은 소프트웨어 정의 자동차의 기반입니다. 각 OEM이 계획한 전기 아키텍처에는 중앙 집중식 기능 도메인, 도메인 간 통합, 중앙 컴퓨팅 도메인 + 지역 액세스의 세 가지 주요 유형이 있습니다. 지능형 자동차와 소프트웨어 정의 자동차의 요구를 충족하기 위해 중앙 컴퓨팅 도메인 + 지역 액세스가 미래의 주류 전자 및 전기 아키텍처가 될 것입니다. OEM은 각 도메인의 기능과 지역 액세스 하드웨어에 대한 인터페이스를 자체 조건에 따라 합리적으로 할당해야 합니다.

2) 소프트웨어 통합

자동차 제조업체는 소프트웨어 통합 역량을 갖추고, "소프트웨어 센터" 또는 "사용자 경험 센터"를 구축하고, 이에 상응하는 조직 구조를 구축하여 차량 소프트웨어 개발 역량을 향상시켜야 합니다.

첫 번째 단계: 차량 제어 애플리케이션 레이어 소프트웨어 및 사용자 경험과 밀접한 관련이 있는 소프트웨어에 중점을 두어 브랜드 특성을 형성하고 사용자 충성도를 향상시킵니다. 소프트웨어 개발 환경을 구축하고 AUTOSAR 사양 가져오기 등의 소프트웨어 개발 프로세스를 따라 개발 수준에서 애플리케이션 계층 소프트웨어와 공급업체 하드웨어의 분리를 달성합니다. 애플리케이션 계층을 위해 이를 열 필요 없이 통합 및 구성을 위한 공급업체를 지정할 수 있습니다. 동시에 우리는 생태학적 서비스 제공자와 협력하여 제3자 소프트웨어를 애플리케이션 계층에 내장할 수 있습니다. 애플리케이션 계층을 독립적으로 제어한 후에는 신속하게 이식할 수 있고, 개발 효율성을 향상시키며, 사용자에게 지속적인 기능 반복과 빈번한 업데이트를 위한 기반을 제공합니다. OTA는 핵심 채널이며 구현의 첫 번째 단계는 소프트웨어 정의 자동차를 향한 첫 번째 단계입니다.

두 번째 단계: 구성 도구를 구매하여 애플리케이션 계층과 하위 계층의 통합을 점차적으로 실현합니다. 하드웨어 공급업체는 OEM에서 통합 및 플래싱을 위한 "화이트 박스"를 제공합니다. 소프트웨어와 하드웨어의 진정한 분리를 실현하고 하드웨어 조달 범위를 확대하며 조달 비용을 절감합니다. 하지만 기본 구성 기능에는 OEM의 막대한 투자가 필요하며, OEM은 자체 역량을 바탕으로 게임 진출 여부를 고려할 예정이다.

세 번째 단계: 점차적으로 하드웨어 및 기본 레이어의 독립적인 개발에 들어갑니다. 하드웨어를 통해 차량 비용을 절감하고, 핵심 칩을 독립적으로 선택하며, 하드웨어 플랫폼의 한계를 뛰어넘고, 비용과 고객 경험을 바탕으로 차량 구성과 기능적 요구사항을 바탕으로 소프트웨어 모듈 이식을 진행합니다.

3) 개방형 플랫폼 구축

전통적인 자동차 개발은 전적으로 자동차 공장 엔지니어의 철학에 의존하며 고객보다 고객을 우선시하는 개발 모델입니다. 개방형 플랫폼은 상생, 공생, 공동 창조의 새로운 모델을 기반으로 새로운 상황에서 공급자, 차량 및 사용자 간의 관계를 해결할 수 있습니다.

개방형 플랫폼은 차량 개발 엔지니어, 제3자 및 사용자에게 완전한 차량 기능을 제공할 수 있습니다. 이러한 기능에는 일부 기본 하드웨어 기능, 소프트웨어 기능, 데이터 및 정보가 포함됩니다. 이러한 기능을 사용 시나리오와 결합하여 다양한 솔루션을 만들 수 있습니다. 소프트웨어는 사용자에게 맞춤화된 구독 기반 서비스를 제공하여 사용자와 OEM을 위한 가치를 창출하고 자체적인 이점도 얻습니다. 사용자가 차량 소프트웨어 개발에 참여하고 소프트웨어 정의 자동차를 실제로 실현할 수 있도록 지원합니다.

개방형 플랫폼을 통해 자동차에 장착된 수십만 개의 하드웨어 모듈을 사용할 수 있으며, 이는 휴대폰보다 더 강력한 인식 기능, 더 많은 적용 시나리오, 더 넓은 적용 범위 및 긴 수명 주기를 제공할 수 있으므로 자동차 생태계는 휴대폰 생태계보다 더 넓고, 휴대폰보다 더 개방적이며, 사용자에게 더 가깝습니다.

5.3 부품 공급업체

기존 부품 공급업체의 경우 소프트웨어 정의 자동차 개발 추세에 따라 OEM은 소프트웨어와 하드웨어 분리 및 SOA 아키텍처 구현을 통해 시스템 기능 개발에 대한 발언권을 점점 더 많이 갖게 됩니다. 전통적으로 하드웨어 기반이었던 일부 부품 공급업체인 Tier 1의 응용 기능 개발은 새로운 변화와 탈출구를 찾는 것이 시급합니다.

현재 소프트웨어와 하드웨어의 풀스택 기능을 구축하는 것이 차세대 시장 점유율을 장악하는 열쇠입니다. 매우 포괄적인 기능을 갖춘 많은 Tier1은 "하드웨어 + 기본 소프트웨어 + 미들웨어 + 애플리케이션 소프트웨어 알고리즘"을 구축하고 있습니다. + 시스템 통합" "풀스택 기술 역량은 고객에게 하드웨어와 소프트웨어뿐 아니라 통합 소프트웨어와 하드웨어 솔루션도 제공할 수 있습니다. 그러나 이러한 레이아웃을 위해서는 Tier1이 많은 인력과 자본을 투자해야 하는데, 모든 Tier1이 이를 감당할 수는 없습니다.

이와 관련하여 부품 공급업체는 하드웨어 포트를 더욱 개방하고 하드웨어 기능을 추상화해야 합니다. 다양한 OEM에 대한 맞춤화 비용을 줄이고 배송 효율성을 향상하려면 통일된 표준에 따라 인터페이스를 열어야 합니다. 일치 복잡성을 줄이고, 소프트웨어와 하드웨어 결합을 줄이고, 유연성과 재사용을 향상시킵니다. 또한 OEM, 소프트웨어 공급업체 및 기타 당사자와 협력하여 부품 생태계를 공동으로 구축하여 보다 다양하고 풍부한 수익 시나리오를 유치하고 창출하는 동시에 성능 차이로 인해 부품 공급업체가 경쟁하게 됩니다. , 또한 부품 공급업체의 혁신과 발전을 촉진할 것입니다. 부품 공급업체는 내부 핵심 알고리즘에 집중하고 내부 알고리즘 및 코드의 최적화 및 업그레이드를 통해 성능과 경험의 차별화와 지속적인 진화를 달성해야 합니다. 그리고 자동차 제조사, 인공지능, 소프트웨어 등 다양한 분야의 IT 기업들과 협력함으로써 최신 요구사항과 개발 방향을 파악하고, 자체 R&D 방향과 역량을 조정하며, 하드웨어를 기반으로 축적된 산업 노하우를 활용할 수 있습니다. - 차별화된 하드웨어 판매를 피드백하고 촉진하는 애플리케이션 기능 소프트웨어 역량 구축의 이점은 많은 부품 공급업체가 선택합니다.

5.4 기본 플랫폼 제공자

소프트웨어 정의 자동차 시대를 맞이하여 기본 플랫폼 제조업체의 목표는 자체 ICT 기술 축적과 장점을 활용하여 OEM이 자체 계획에 적합한 차별화된 솔루션을 만들 수 있도록 돕는 것입니다. 차세대 전자·전기 아키텍처는 스마트카 연구개발의 복잡성을 줄이고 효율성을 높이며 스마트카 개발을 가속화한다.

그러나 OEM부터 1차 공급업체, 2차 공급업체, 3차 공급업체에 이르는 현재의 공급망 모델은 점점 더 모호해지고 있으며, 자동차 회사는 점점 더 많은 기본 플랫폼 제공업체를 장악하려고 합니다. 보다 열린 자세로 경계를 허물고, 자사의 유리한 제품에 집중하며, 상위 및 하위 하드웨어와 응용 소프트웨어에 개방형 API 인터페이스를 제공하고, 기능적 소프트웨어에 대해 안전하고 신뢰할 수 있는 운영 환경과 사용하기 쉬운 서비스 개발 및 검증을 제공합니다. .

기본 플랫폼 제공업체는 스마트 자동차의 지속 가능한 발전을 위한 아키텍처를 OEM에 제공하는 것이 좋습니다. 디자인 컨셉은 사람 중심이어야 하며 사용자 경험과 OEM 비즈니스 성공을 중심으로 계속 혁신해야 합니다.

5.5 소프트웨어 공급업체/소프트웨어 개발자

OEM 자율성 및 소프트웨어 자체 연구 역량이 지속적으로 강화됨에 따라 OEM은 완성차 제조업체가 먼저 모색할 소프트웨어 공급업체와 같은 소프트웨어 공급업체와 직접적인 협력을 모색하기 시작했습니다. UI/UX 디자인 도구, 음성 인식 모듈, 음향 효과 모듈, 얼굴 인식 모듈과 같은 응용 소프트웨어는 조종석 HMI 대화형 시스템의 기능을 되찾아 소프트웨어 공급업체로부터 소프트웨어 라이선스를 직접 구매함으로써 기존 Tier 1을 우회하고 자율성을 달성합니다. . 개발.

소프트웨어 정의 자동차 혁명이 진행됨에 따라 자동차 하드웨어 시스템은 점차 표준화되고 있으며, 소프트웨어는 자동차의 일부를 가장 빠르게 반복하고 개인화하고 차별화하는 동시에 하드웨어도 구동합니다. 2. 둘은 서로를 보완합니다. 소프트웨어 공급업체의 경우 제공할 수 있는 소프트웨어 IP 제품 포트폴리오가 많을수록 더 높은 차량 가치를 얻을 가능성이 높아집니다.

동시에 소프트웨어 공급업체에서는 도메인 컨트롤러, T-BOX 등 기존 Tier1이 관리하는 하드웨어 설계 및 제조 링크에 진입하여 다양한 솔루션을 제공하려고 합니다. 스마트카 APP 애플리케이션 개발을 위해 원자 서비스 표준 API를 기반으로 애플리케이션 소프트웨어를 개발하면 매우 편리하고 사용하기 쉬워질 것입니다. 애플리케이션의 경우 Android 기반 개발 모델과 마찬가지로 기본 구현에 너무 많은 주의를 기울일 필요가 없으며 다양한 레벨과 모듈의 종속성을 줄일 수 있습니다. 다양한 그룹의 사람들, 다양한 자동차, 다양한 생활 시나리오에 대해 다양한 애플리케이션 개발자는 다양한 기능, 다양한 그래픽, 다양한 경험을 갖춘 애플리케이션을 만듭니다.

애플리케이션 개발의 문턱이 낮아지고, 더 많은 소프트웨어 공급업체/개발자가 자동차 애플리케이션 APP 개발에 참여할 수 있게 되면서 소프트웨어 개발 경쟁이 더욱 치열해졌습니다. 소프트웨어 공급업체는 일부 설문조사 데이터를 기반으로 다양한 그룹의 사람들의 선호도를 분석하고 다양한 자동차 모델에 대해 대중에게 적합한 차별화된 애플리케이션을 개발해야 합니다. 사용자는 실제 조건에 따라 일부 기능과 특징 애플리케이션을 선택적으로 설치할 수 있으며, 다양한 애플리케이션과 서비스를 통해 자신의 차량의 일부 특성을 정의하여 소프트웨어를 통해 기능 업그레이드 또는 개인화된 맞춤화를 달성할 수 있습니다.

경쟁 과정에서 매우 인기 있는 응용 소프트웨어가 등장할 뿐만 아니라 응용 소프트웨어 공급업체의 주도성과 정확성을 높여 서비스를 개선하고 제품 혁신 능력을 향상시켜 스마트카 응용 생태계를 번영시킬 것입니다. .

5.6 산업단체

정부는 자동차산업 전체가 규제, 정책, 기준 등의 측면에서 합리적이고 효율적인 경영시스템을 구축하고, 전체가 질서있고 원활하게 운영되도록 감독해야 한다. 산업 전반에 걸쳐 공정한 경쟁을 보장하고 지속적으로 더 크고 더 강하게 성장합니다.

기업이 정책적 관점에서 신기술을 개발하도록 장려합니다. 예를 들어 자동차 산업에 기여했거나 특정 기술에서 획기적인 성과를 낸 사업 단위에 포상하고, 혁신 성과를 공유 및 전시하고, 과학의 심층적 통합을 이룰 수 있습니다. 우리는 계속해서 정책을 개선하고, 피드백 시스템을 개선하며, 신기술 개발을 위한 정책의 원동력을 최대한 활용하고, 우수한 자동차 소프트웨어 생태계를 구축하며, 지능형 커넥티드 차량을 사용하여 건설 및 건설을 추진할 것입니다. 스마트 교통과 스마트 도시의 발전.

표준을 기반으로 공통 문제를 해결하기 위해 공통 인터페이스 및 기타 사양을 확립하고, 자동차 소프트웨어와 하드웨어 제품의 상호 연결을 실현하고, 공통 표준화된 인터페이스 수준에서 각 회사가 자체적으로 싸우는 것을 피하고 각 회사가 다음을 수행하도록 권장합니다. 통합된 인터페이스 하에서 자체 제품을 개발하는 데 성공했습니다. 혁신 및 R&D, 중복 및 단편적인 투자 방지, R&D 효율성 향상, 우리나라의 지능형 연결 차량 개발 촉진.

위 내용은 소프트웨어 정의 자동차 구현을 위한 5가지 핵심 요소를 논의한 기사의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!