传统多芯片架构

欢迎关注我的微信公众号：阿宝1990，每天给你汽车干货，我们始于车，但不止于车。

原来的座舱里面的控制器基本上是分开的，导航主机是一家，液晶仪表是一家，同时还有一个AVM全景一家，还有TBOX等，这里线束连接就非常复杂，而且不同供应商直接的协调调试也非常复杂。

上图是IMX6 的多芯片方案，液晶仪表、中控导航、后排娱乐都使用了IMX6最小系统，这样上图黄色框里面的内容就资源重复了，但是如果只用一颗IMX6又不能带动三个显示屏，所以利用率不高。

单SOC智能座舱系统框架

上图是RCAR-H3的单SOC智能座舱的方案，可以看到这部分最小核心系统的器件只需要一份，就可以驱动中控导航、液晶仪表、后排娱乐显示屏、还有副驾驶娱乐屏，多个显示屏的不同内容。

单SOC 的方案的优点非常多                                                                            

车身:设备单一，布线方便，成本低，可靠性好。

系统硬件资源：

Hypervisor 技术系统硬件资源最大化利用， DDR/EMMC/PMIC/MCU/CAN单套系统配置即可满足产品需求

产品开发：

独家设备供应商，独立设备开发，独立样件制作，无须定制复杂协议，多个设备无须联调，开发进度容易把控，开发成本可控。

信息安全：

独家供应商，设备间通讯在芯片内部完成，信息安全得到有效保护。

整套成本：

硬件资源利用率高，独家供应商，生产，包装，运输可控整套成本可控。

体验：

设备单一，整套设备方案受限因素小，多屏娱乐互动性好，体验佳

域控制器设计方案-RCAR-H3

1、方案概述

新推出的R-Car H3具备比前一代R-Car H2更强大的汽车计算性能，可充分满足系统制造商对汽车处理平台的要求。为了提供准确、实时的信息处理能力，R-Car H3基于ARM® Cortex®-A57/A53核构建，采用ARM的最新64位CPU核架构，实现了40000 DMIPS（Dhrystone百万指令/每秒（注1））的处理性能。

此外，R-Car H3采用PowerVR™ GX6650作为3D图形引擎，可为驾驶员提供及时可靠的信息显示。基于ImaginaTIon Technologies提供的最新架构，R-Car H3的着色计算（注2）性能约是R-Car H2的三倍。

除了CPU和GPU以外，片上并行可编程引擎IMP-X5也提供了先进的图像识别技术。IMP-X5是瑞萨电子独有的识别引擎，专门为与CPU配合处理而进行了优化。它的识别性能是第二代R-Car系列内置的IMP-X4的四倍。

欢迎关注我的微信公众号：阿宝1990，每天给你汽车干货，我们始于车，但不止于车。

R-Car H3是业界首款采用16纳米工艺的汽车SoC，具有卓越的处理能力，符合ISO26262 （ASIL-B）汽车功能安全标准，是先进安全驾驶辅助系统和车载信息娱乐系统等应用的优秀汽车计算平台。

R-Car H3 R8A77951（SoC）关键参数：

CPU core：Cortex-A57 Quad@1.5Ghz+Cortex-A53 Quad@1.2Ghz +Cortex-R7@800Mhz

DDR：LPDDR4/DDR3/DDR3L SDRAM Up to 1600 MHz,32bits x4ch  Up to  8GB

GPU：IMG PowerVR Series6XT GX6650 Max 600Mhz

Video input：MIPI-CSI2 3ch(4lane x 2channels, 2lane x 1channel)+ ITU-R BT.601/656 /RGB888 24 bit 2ch

Video output：4 display controllable(HDMI 2ch+LVDS 1ch+RGB888 1ch

Video Codec：H.262/H.263/H.264/H.265/Real Video8/9/10/VP8/VC-1SP/MP/AP/MPEG-4ASP

Storage ：USB 3.0 Host 1ports /USB 2.0 Host/OTG 4ports/SD x2ch/SATA 1ch/

OthersI2Cx7ch/PWMx7ch/Audio-DMACx32ch/QSPIx2ch/SCIF 1ch/Ethernet /DRIFx4ch/INTC/CPG

芯片制程    16nm

R-CAR H3系统框图

基于1颗SOC，搭载QNX Hypervisor 2.0 运行QNX SDP 7.0+RTOS +Android P Automotive 

CPU及外部硬件资源通过QNX Hypervisor虚拟化共享。

欢迎关注我的微信公众号：阿宝1990，每天给你汽车干货，我们始于车，但不止于车。

Android P实现IVI+HMI+RSE三屏，QNX SDP 7.0+Kanzi 实现仪表。

RCAR-H3 QNX 共享CPU

半虚拟化是通过事先经过修改的用户操作系统内核共享底层物理硬件来实现的。

优点：是半虚拟化的虚拟机操作系统内核能够直接管理底层物理硬件，实时性好，性能比全虚拟化技术更强。

缺点：是用户操作系统内核需要事先进行修改，部署的便利性和灵活性不够好。

全虚拟化是通过用户操作系统和物理层的虚拟化逻辑层hypervisor来完全模拟底层物理硬件细节。

优点：是用户的操作系统内核不需要做特殊配置，部署便利，灵活，兼容性好。

缺点：是用户操作系统的内核不能够直接管理底层物理硬件，内核通过hypervisor系统管理模块管理底层物理硬件需要有转换，性能比半虚拟化弱。实时性不好。

RCAR-H3是使用全虚拟化的设计，共享内存，零拷贝，速度非常快。

域控制器设计方案-高通SA8155P

方案概述

系统框图概要：

系统主要器件List：

系统主SOC选型说明：

系统软件架构：

座舱系统包含三部分，具体如下：

MCU运行AUTOSAR系统，用于CAN/LIN唤醒/通讯/电源管理等

SoC运行QNX Hypervisor，包含两个操作系统，其中QNX运行对实时性和安全性要求高的功能，比如仪表/HUD

Android系统运行娱乐域相关的功能，比如导航/音乐等应用

QNX 虚拟化方案支持：

运行Guest OS系统，可以在虚拟机上运行Android系统

QNX系统达到ASIL-D等级，同时具备高实时性，可以运行仪表/HUD等功能

GPU以及CPU的资源可以共享，可以通过配置优先级确保QNX系统的资源

支持Qualcomm平台/Renesas平台/Intel以及其他座舱域控硬件平台

QNX和Android之间的进程间通讯包含两部分

系统间的控制命令/数据通讯（不包含音频视频）可以通过SomeIP协议来实现

系统间的大数据量数据通讯（比如图像/音频）可以通过共享内存的方式实现数据通讯

安卓端框架介绍

应用层：运行自研应用及第三方应用

Framework层：支持上层android应用运行的框架，比如音频/媒体类/连接类等框架

安卓服务层：支持应用运行的功能，以android服务的形式运行

硬件抽象层：对上提供统一的接口，屏蔽底层驱动的不同，对下适配底层驱动

QNX软件主要分为如下几层：

应用层：主要运行仪表速度/转速/报警灯/快速RVC/动画等上层应用

架构层：主要运行图形处理/音频处理/网络管理/进程间通讯框架

服务层：主要运行进程间通讯，虚拟IO口的访问/音频服务/屏幕管理的逻辑

驱动层：负责屏幕串行解串/USB/摄像头等驱动调试

软件升级相关

支持A/B分区升级，在升级主机过程中不影响用户使用

支持集成车厂的FOTA方案，目前FOTA方案的集成一般包含两部分

升级客户端：与升级服务器交互，下载升级包，与后台的升级服务器同步主机版本信息。

升级代理：负责升级主机和MCU软件；可以通过DOIP协议发起刷新其他模块

支持对屏幕的升级

升级模块支持车厂的PKI策略集成，可以支持证书的生成和校验

视频输入相关

Camera 框架使用AIS框架，图像数据的采集在QNX端完成

Android端可以通过AIS框架获取到Camera图像数据，界面的处理需要靠图层叠加来完成

Camera的接口是CSI接口，每个CSI接口可以支持4个摄像头接入。不同高通平台的CSI接口数目不同

视频输出相关

屏幕的输出使用WFD框架

屏幕的输出接口控制在QNX端。Android端使用代理与QNX端通讯

屏幕的输出接口有DP和DSI两种，具体的接口数目不同的项目不一样

域控制器设计方案-NXP iMX8QM

NXP座舱芯片的roadmap

在新一代的iMX8QM和iMX8QXPBSP中，它实现了硬件分区以划分资源和内存区域。默认的Android Auto BSP给出了M4和A内核之间共享内存的示例，这被用于RPMSG。

2.在L4.14.78 GA1.0.0 BSP中，MU_5用于M4的FreeRTOS和A35 Linux之间的RPMSG，SC_R_MU_5B是M4端，而SC_R_MU_5A是A35端。用于A35与M4之间的相互唤醒。

QNX基于A35运行；

QNX本身自有的图形监视子系统用于保证正常图形绘制的安全性以及可靠性；

借助QNX的微内核系统和分布式系统，可以动态加载和升级指定的驱动、应用、协议栈等，当有一个CPU失效时，剩余的CPU可以同时承担冗余工作和平衡负载的能力；

欢迎关注我的微信公众号：阿宝1990，每天给你汽车干货，我们始于车，但不止于车。

同时界面工具QT（或者KANZI）有完整的安全渲染机制（Qt Safe Renderer version 1.1.），通过工具所提供的安全渲染引擎（Safe Renderer Engin），能够对安全要求最高图层进行渲染（警告图标等等）；

上述A35核本身借助符合ISO26262-ASIL-B的QNX+QT的工具集来保证系统和功能的安全性和稳定性

借助QNX的POSIX –API接口，与M4核进行通讯（SCU+PRC）

M核基于RTOS，M核端运行Watch dog；

实现由M核对A核的服务与消息机制的监管；

当A核出现彻底的失效或者需要软件重启的时候，提示相关的Warning等相关信息； 

建议：

QNX符合ASIL-B的显示子系统安全机制；

HMI图形工具QT的安全渲染机制，保证失效机制下的最高等级图层显示（FB0）。M4核是冗余设计出来的。

The QNX CAR platform boots in several stages, as illustrated in the following diagram:

QNX的安全启动流程参考如下：引用QNX Boot_Optimization_Guide

NXP的imx8芯片是基于硬件虚拟化设计实现，具有以下功能：

双系统独立启动，双系统为LINUX+ANDROID

崩溃检测

硬件资源划分

共享内存

使用NXP硬隔离方案，在两个Domain之间通过MU和Share Memory的方式进行信息通讯和数据共享