本篇文章给大家分享一下使用 AP AUTOSAR 的中央计算单元设计。
所有分享内容可在公众号《搞一下汽车电子》后台回复 “搞一下汽车电子”
汽车分布式架构的复杂性成为了智能网联汽车发展的障碍，汽车当前的基础架构需要做出改变。
在车载网络的快速发展和强大处理器的支持下，有效的数据传输可以得到保障，此时需要把重心转移到各个控制器单元之间的解耦上。
同时，随着处理器迭代速度的减缓以及用户功能需求的增加，当前需要以软件为中心进行发展，并且需要在软件和接口方面进行重新设计。
基于上述几个原因，以中央计算单元（CCU）为主的架构得以发展。
图中，“智能传感器”和“智能执行器”直接连接到总线系统，用于提供值或设置物理量。
当然，传感器也可以直接连接到集成节点（图中蓝色块）。在该网络中，以太网构成了通往中央计算机的主要总线系统。
笔者认为中央计算单元可以认为是用于处理大部分车辆功能的电子单元，尤其是处理现代应用程序，包括：
-
-
-
使用GPU处理与视觉相关的算法，如ADAS应用等。
在设计中央计算单元时，我们应该从哪些方面进行考虑呢？笔者认为至少应从以下几方面进行考虑：
-
-
-
-
标准接口 (Standards Interface)
-
应用程序框架 (Application Framework)
从处理器方面，笔者认为，中央计算需采用异构处理器（甚至是多芯片），该处理器应包含CPU内核、图形处理单元GPU、数字信号处理DSP等，目的是为了执行复杂的计算操作。
线束方面，应从LVDS、CAN、Ethernet、PCI-E等多方面进行考虑（后文会基于案例进行介绍）。
传感器方面，应包括多种传感器，如摄像头、毫米波雷达等，以满足不同功能的需求。
采用虚拟化技术，供应商的软件可以在虚拟化分区上运行，OEM也可单独购买软件方案（后面还会分析使用虚拟化技术的原因）。
异构是指，需要使用多种不同的OS，由于中央计算单元需采用高性能处理器，运行较为复杂的运算，因此不能再以传统的基于OSEK等高实时嵌入式操作系统为主来设计中央计算单元。
应以POSIX OS为主，目的是为了可以动态处理已执行的软件，提取并使用更强大的硬件资源。
多平台是指，中央计算单元应考虑多种应用程序运行时框架，也就是我们常说的中间件，该中间件至少应包含通信中间件功能。
由于中央计算单元需运行一些用户交互等现代应用程序，因此，中央计算单元中，还是会使用到Linux和AGL（汽车级Linux）等OS，但是Linux和AGL存在着不足之处：
1. 不符合汽车软件过程的改进和能力测定（ASPICE）
2. Linux和AGL等在设计没有考虑ISO26262
这个时候就需要使用一种在功能安全上达到ASIL-D的实时操作系统（如eMCOS）
但像eMCOS这种RTOS的功能有限，会存在以下问题：
1. 大多数需要OpenGL/OpenCL进行图形加速的算法无法在RTOS环境下运行。
2. 这些OS本身自有的一些框架缺乏合规性，且无法达到ASIL-D。
3. 这些RTOS无法通过用户交互来执行大多数现代连接的应用程序，如社交软件、地图、多媒体等。
因此，笔者认为，中央计算单元中使用的OS应是多种OS的组合，即应包含Linux这种GPOS、也应包含eMCOS这种RTOS。
当在同一个硬体上使用多种OS时，为保障两个或多个OS共享硬件资源，应使用Hypervisor技术虚拟化硬件。
如下图所示为中央计算单元软件架构的概览，我们可以使用RTOS + Linux或者RTOS + Android，甚至三者结合的方案来满足中央计算单元在OS上的需求。
-
-
汽车作为以软件为主导的系统，须满足一定的ASIL等级
-
-
这里，笔者以AP AUTOSAR这个中间件为例进行说明。
需要说明的是，不是说，中央计算只能用AP AUTOSAR，也不是说非AP AUTOSAR不行。而是，中央计算单元也会使用其他的成熟的中间件方案，但是针对的需求不同。为了满足ASIL等一些需求，笔者认为比较可取的方案是使用AP AUTOSAR，原因如下：
1. AP AUTOSAR 提供了应用程序动态执行的环境，当然正如之前分享过的，AP AUTOSAR是一种SOA实施。
2. 可以在AP AUTOSAR上运行一些Safety致关重要的，且不能再Linux环境中运行的应用程序。
3. AP AUTOSAR 对Linux进行了全面支持，因此，可以运行在搭载Linux的异构芯片上。
4. AP AUTOSAR 可以基于同一协议与非AUTOSAR APP进行交互。
笔者这里也分享一个，笔者知道的量产项目中正在使用的中央计算单元软件方案，如下图所示：
OS方面，上述方案中选择了 eMCOS作为Host OS。
Hypervisor方面，使用了eMCOS Hypervisor。
Hypervisor之上运行了多个VMM，VMM之上运行了多个Guest OS，包括Linux、Android、ROS/ROS2 以及eMCOS（在eMCOS之上运行的是AUBIST AP AUTOSAR）。
然后在OS之上会运行不同的中间件，如QT、AP AUTOSAR等。然后再之上运行各种不同的应用程序。
当然，该软件方案可扩展，可以运行CP AUTOSAR OS及CP AUTOSAR。
对上述方案感兴趣的朋友，也可随时与我们（搞一下汽车电子）交流。
接下来，笔者会基于之前与国外朋友交流的内容，分享一个中央计算单元的整体设计方案。
芯片部分分为主芯片（Master Chip）、辅助芯片（Work Chip）、Safety芯片和可扩展芯片(可选)，这几部分是通过确定性以太网总线(如时间敏感网络TSN)和PCI-E总线进行通信的。
之所以会使用PCI-E的原因是由于在系统内部同时处理多路以太网信息时，车载以太网总线有些不够用，所以可以PCI-E进行处理。
上述方案中，Work Chip的SoC可以通过LVDS直接访问摄像头。而Master Chip可以通过PCI-E缓冲区交换来访问其他SoC（Worker Chip等）连接的摄像头。当然，Master Chip也可以根据需求设计为直接访问摄像头。
总线方面：整个系统以以太网为主，所有的传统汽车总线仅连接到安全芯片。主芯片可以通过传统总线到确定性以太网的虚拟映射来访问传统总线。
由于篇幅原因，此方案并不对其他传感器进行分析，可根据功能需求进行设定。
可为所有数字驾驶舱应用提供服务，并且预留执行非关键算法的空间，如基于视觉的环绕视图和其他冗余ADAS。
主芯片也用于反馈视屏信息到HU、仪表、HUD及后座屏幕等。
可实例化服务，并用于AD和ADAS，具有运行实时算法和基于OpenGL等常规算法的能力。
与汽车中的大部分执行器进行交互，并执行对实时性及功能安全要求搞的传感器融合任务。
(FPGA)用于处理从其他组件(如PCI-E)获取的数据
软件架构方面，使用Hypervisor以运行多种OS。
主芯片域中，也会运行Android，Android通过SOME/IP库与基于RTOS的AP AUTOSAR应用程序进行交互。
AP AUTOSAR 应用程序需要使用确定性调度程序构建（基于AP AUTOSAR的EM模块），取代了OS调度。同时，可以拓展AP AUTOSAR应用程序以支持通过LVDS对摄像头的访问。
对于高性能SoC的话，可以使用R-Car、Xavier（或Orin）等芯片。
RTOS + QT的环境：目的是满足HUD及其他ASIL要求的图像处理应用程序的需求，为与AP AUTOSAR应用程序交互，该环境中需包含SOME/IP接口代理。
Linux + GENIVI的环境：目的是满足HU和其他QM的图形应用程序需求，该环境需包含SOME/IP接口代理。
Android：用于满足如地图、社交服务、Google服务等应用程序，需包含SOME/IP接口代理。
Linux + OpenGL + OpenCL：满足基于视频的算法及图形加速。
RTOS + AP AUTOSAR 就不说明了，之前也提到过了，为了满足一些ASIL的应用程序要求。
接下来，总结一下中央计算单元中与AP AUTOSAR相关的一些内容。
在中央计算单元中，使用AP AUTOSAR 架构可以满足一些模块化、动态化的需求。
使用UCM（升级通信管理）功能集群，可以满足一些OTA的功能要求。
可以使用AP AUTOSAR满足运行时建立动态通信路径的需求。
也可以使用PHM（平台健康管理）和Crypto（加密）满足一些Safety和Security的需求。
在L2时，我们可以使用专用ECU，并使用CP AUTOSAR进行处理。
在L5时，我们可以使用上文提到的中央计算单元，将车窗控制功能运行在 Worker Chip2上（从中央计算单元概览图中也可以看出，Worker Chip不止一个），软件采用AP或CP，具体采用AP还是CP，此时可以（主要）根据实时性要求进行区分。
同时也对这些功能在中央计算单元的哪个域芯片上运行，以及使用什么中间件及OS做了分析。
原文始发于微信公众号（搞一下汽车电子）：使用AP AUTOSAR的中央计算单元设计
