分享

异构SoC软硬件介绍及功能分配

 新用户82165308 2022-08-14 发布于广东

前  言

搞SOA、搞 AP & CP AUTOSAR、搞异构SoC、搞车载以太网、搞车载OS等就找搞一下汽车电子。

所有分享内容(点击进入)
开通会员可查看年度所有内容(点击开通)

主机厂面临的挑战


挑战1


某主机厂想在现有车型上增加一个汽车香氛功能,发现需要修改8个以上ECU结点,涉及到5个以上的供应商的PCE,多条CAN总线信号改变,包括很长周期的测试验证及功能联调。

挑战2


某主机厂在规划下一代车型的电子电器架构,新的EE架构里增加了高阶ADAS域控制器,10多个扬声器,10个以上的摄像头,激光雷达,点云毫米波雷达。

导致ECU数量,ECU体积,ECU重量都有显著提升,线束线径直线上升,线束太粗,无法走线。
 

挑战3


来自某新势力主机厂的挑战。

某新势力主机厂在SOP之后以惊人的速度通过软件OTA来给车型增加新功能,在将近3-4年内,不停的通过OTA给汽车赋能,给汽车增加新的功能,使消费者持续获得新鲜感,有一种说法:某新势力的OTA功能打开了潘多拉的魔盒。

当前其他主机厂也在思考, 在SOP之后,汽车的生命周期是否还可以再延续几年。然后通过OTA的方式来再次获利。

下表为2019某新势力主机厂主要升级的内容汇总:

哨兵模式
宠物模式
可根据未知自动合拢/展开外后视镜
峰值功率提升
动态制动灯
升级提示屏
更多TeslAtari电子游戏
New Application Launcher
停车灯警告
更好的驾车可视化体验
NoA的无需确认的变道功能
恶劣天气NoA禁用功能
车道偏离避让功能
紧急车道偏离避让功能
有条件限速功能

挑战4


某些主机厂在分析某新势力主机厂的EEA之后的设计思路。

包括中央大脑的出现,ADAS的ECU、娱乐系统的ECU。如下图所示

图片

上述EEA中,通过将车身的功能按区域划分,进而优化走线。将原先按照功能域划分的功能拆分到不同的区域里面。

很多主机厂都是跟风的,但是有些主机厂是有自己的想法的,所以他们也在往中央计算 区域化的电子电气架构的方向发展,以这样的模式去开发他们的下一代的电子电气架构。

总结


当前主机厂碰到的问题:

  • 随着车内功能越来越多,代码量已达到将近2亿行

  • 控制器数量已多达100多个,整个管控非常困难

  • 1000个以上的功能跨ECU,这些功能要做修改和迭代是非常困难的


所以目前来说这些主机厂都为这些问题。正在头痛,所以说大家都在寻求改变。

接下来给大家看一段视频:


上述视频是特斯拉在年终一个更新里面增加了一个灯光秀的一个功能,这其实包含了SOA的概念。如果我们在原来的EEA上面要实现这样的一个功能,其实是比较难的。

中央 区域的电子电器架构



那么中央区 区域的EEA是一个什么样的一个概念呢?

中央 区域 EEA的概念


在1999年的时候,整车可能只有19个ECU,经过多年以后,最新一代汽车上,ECU的数量已经增加了108个,FlexRay的总线上的信号数量已经多达4万个。

以FlexRay为例,当我们在增加功能的时候就会发现,没有人知道这4万多个信号到底是干什么的,也没有人敢去动它,然后大家只管往里面再去增加更多的信号,那么会导致后续我们去开发新的功能的时候就非常的困难,所以需要做出改变!

下图是他们这家主机厂现在在努力的一个方向,原先的电子电器架构主要是以功能域来划分的, 慢慢的转到中央式的电子电器架构,他们会把很多功能域集成到计算平台的ECU中, 把一些配电和一些对传感器执行器的集成会放在VIU 单元当中去, 用高速或慢速的CAN或以太网,跟中央的大脑之间进行一个连接。

图片


集中计算的概念就是要有一个高性能的异构计算平台,设计软件要有一个SOA的概念,具备OS与中间件, APP 要与硬件解耦;

然后分布式连接就是首先要搭一个中央 区域的电子电器架构,同时利用高速总线(以太网或 PCIe)来实现功能域之间的连接和通信,还有一些线束的革新,以及要做到IO解耦。

SoC厂家愿景规划


一些SoC厂家推出了一些SoC概念,在他们眼中,传统网络是一个网关把各个功能域连接在一起。

在目前21/22年这一代可能量产的一些车型,或者量产的大部分车型中他们以功能域来划分。在下图可以看到ECU的数量大大减少了,把很多计算的东西放到了功能域上面,把一些功能集成到一个更大的ECU里面。

在24/25年的时候,基本上会把这些功能域的控制器再做进一步的集成,会形成一个两个或三个这种大脑即我们认为叫GCP或者叫CCU这样一种形式,然后再以区域化的方式去接入。 

新进来的一个SoC厂商更加激进,他们认为可能一直到2026年可以把整车所有的计算全都放在单个的SoC里面,里面包括娱乐系统、Cluster、ADAS、车内感知、车身控制、底盘等所有的功能。

这目前是一个愿景,还在PPT阶段,我们也拭目以待!

图片


计算平台概念



目前来说比较适合中国的主机厂的一个多快好省的计算平台GCP,它应该怎么去搭呢?

首先它是要有一个异构的SoC,它里面是有MPU, 主要用来去做高性能计算,那上面我们会有VDL的这一层把外面接的执行传感器或者是其他的一些ECU进行一个抽象和代理。

然后还有一个MCU这个单元,MCU就相当于一个实时核,它里面主要会跑 CP AUTOSAR,会通过信号与服务的转换把一些信号暴露出来给MPU,让MPU这边去做一个SOA的一些应用。

MCU主要是看它的个数,包括它的算力,能够支撑我们外面的一些ECU往里面去收集,我们就相当于可以去把类似于纯计算的一些ECU集成到我们这个MCU里面去。

然后MPU这边的话可能会有一些SOA的服务,整车的OTA的Master,网络安全,整车诊断的功能,大数据收集的功能等都会放在MPU上,利用它的一个高性能的 OS、 Linux或者eMCOS,数据库的这种方式可以在这上面实现。

计算平台的特点


上述计算平台的特点如下:

  • 中央网关既是网关又是计算平台,也是软硬分离的核心部件

  • 中央网关连接的不再是功能域网段,而是按实时性及带宽要求分解出更多的网段;

  • 客户体验相关应用尽量上移到GCP,硬件相关软件的基础功能软件放在其他节点。

  • 尽量暴露其他节点的信号;

  • 尽量暴露其他节点的能力并尽量原子化;

  • GCP算力高低可配;

  • SoC尽量pin to pin 可扩展;

  • VDL可厚可薄取决需求。


通用计算平台搭建


GCP如何搭建呢?它首先里面包括MPU、MCU两个计算单元,我们这里是在一个异构的SoC架构里面。

图片


它是一个实时性的核和高性能的核的组合, 它要能够实现不同的功能域的融合的话,必须要支持不同的安全级别,有一些安全隔离,内存、功能等之间是互相要隔离开,同时供电也是要互相隔离。

MPU特点:高算力、大运算量、服务类通信、低安全级别、低实时性、功能多样化

MCU特点:中低算力、多控制功能、高安全级别、高实时性、快速启动

功能分配



整合考虑因素


  • 功能是否对实时性要求很高

  • 功能是否需要有很多的模拟量输入和输出

  • I/O和计算分离后业务逻辑的变化(计算时的输入参数需要通过总线传递)

  • OEM或供应商是否有把某个功能做I/O,计算分离的技术能力

  • 是否对优化成本有优势

  • 评估每个功能对硬件能力的需求,并评估整合后在新的硬件平台上是否同样满足需求

  • 整合后的ECU开发难度


功能分配


下图是某个主机厂的一个基于Ti芯片的计算平台,集成网关功能,车身控制功能,同时因为它外面有外挂IQ的芯片,把上层的ADAS融合算法和车辆控制也放到了这个芯片里面。

图片


高性能核有一些MCU的功能,在一个MPU中会有SOA相关的信号服务转换功能、基本功能、上层服务。

还有诊断功能DoIP、时钟同步功能,数据和日志大数据收集功能(可能有的主机厂把大数据放在娱乐系统那边的话,其实没有办法拿到整个车身上所有的信号,所以把它放在网关这样一个节点或者放在中央计算平台这样一个节点是非常合理的)、网络安全功能、OTA/刷写功能。

这些芯片除了以上描述的一些功能,还可以做一些视觉处理,泊车功能等。
当然这个芯片目前做了一些评估,虽然说这个泊车功能放在上面理论上是有可能性,但是可能这个芯片算力上稍微差点,所以目前来说这只是一个规划,如果后续出了一个更高的一个版本的话,那有可能把这个芯片的所有功能都用上,做成比较大的一个融合的平台。

IO与计算分离


IO与计算分离概念


一个很典型的例子是在一个Door模块里面集成了一个反光镜的控制功能。比如有三组用户的一个配置参数存在这个ECU的flash,受限于ECU的算力和FLASH、RAM大小,能够存三组用户数据,我们可以看到,大多数一些车辆的门左侧或者右侧都会有一个用户参数保存的实体按钮,然后memory加上一个m键,这个功能基本上是定死,没办法再扩展。

我们要去对这个I/O和计算进行一个解耦,那么怎么样去做呢?

我们要把它的最基本的功能,比如左右上下的一个调整功能,挡位、车锁芯联动的这些功能保留在信号的一个层面,然后把用户相关的参数保存这些东西会放到更上层去做。

GCP一般是在一个承上启下的位置,ECU变成一个执行器,逻辑就会简化,信号通信也变的简单。
整个的业务逻辑上提到GCP里面,比如在R核里面部署一个类似于反光镜这样一个SWC,那么在A核这边,我们就可以部署一个反光镜控制的这样一个基础服务,可以由很多其他的服务来调用,比如User Setting,这样用户的个性化功能就可以通过服务调用跟我们的反光镜可以联动起来。

以上就是一个面向服务的I/O与计算分离的一个示例。

适用于计算平台SoC



下面,我们分享一下适用于计算平台的SoC。

TI 821


TI 821的主要特点是有两个A72的核,相对来说已经是比较强的一个算力。还有4颗R5F,单颗可以在1GHz运行下,提供2k的DMIPS算力,4颗R5F最多可以提供8K的算力。

下图可以看到安全岛的概念,绿色的地方,如果用两颗R5F的话可以达到ASIL D的一个级别,它的内部MCU也是可以锁步的,分开来用可以达到ASL B的级别。这也印证了一点,它可以有不同的安全级别功能同时跑在不同的核上面。

图片

下图是一个假想的设计框架,MCU0系统里面可以做一个网关的功能,把整个CP AUTOSAR的协议部署到上面。可选性比较多的,就看客户的一个需求。

图片

NXP S32G

下图是恩智浦的S32G芯片架构图

图片

上图中,CPU Platform 中有两个Cluster 0和1,每个Cluster 的里面是两颗A53,这个A53可以支持锁步,也可以支持分开来用。相当于Cluster 0 和Cluster 1至少可以有两个独立的工作区来跑高性能的运算.

M7的核有三个可以支持锁步的M7,可以达到ASIL-D,上面又可以去部署一些高实时性或CP AUTOSAR的一些功能。

S32G的外部接口的话跟TI 的芯片其实差不太多,比较有特色的就是它有一个网络加速功能,对传统的CAN有一个LLCE的引擎专门对报文路由进行硬件加速,跟PDR模块进行一个紧密结合.

另外还有一个以太网加速模块,也是一个对以太网报文路由进行一个加速硬件模块。这是两个比较有特色的点。

下图是S32G开发板的参考设计框架,图中外扩了一个Switch,最下面是以太网的连接;上面可以支持LINE、FlexRay(主要是沃尔沃和吉利在用)、CAN传统的车内总线连接。

图片


SoC通用特性


  • MultipleCAN, FlexRay(opt), LIN, ADC, DIO,SPI,UART etc

  • MultipleEthernet

  • MPU:Cortex-A core (Performance Computing)

  • MCU:Cortex-M core Cortex-R core (Realtime Computing)

  • IPC(Inter Processor/Platform Communication)

  • HighSpeed & Bandwidth Interconnect between Computer Domains

  • SafetyEngine for HSM

  • SafetyIsland Concept (Separate Power Supplier, MCU only mode)

  • DDR-RAM& SRAM

  • NOR-FLASH(MCU firmware, NVM, Bootloader)

  • EMMC,UFS (MPU kernel, rootfs,user data)

  • SecureBoot

计算平台SoC关键技术点



IPC工作流程


IPC工作流程如下图所示:

图片

Core1
  • application调用rpmsg_send接口,把数据copy到本地queue
  • virtio-ring把data从localqueu搬运到共享内存中的vring中
  • 同时写mailbox寄存器进行kick操作

Core2
  • 触发IPC中断
  • 中断处理函数中把数据从vring中搬运到localqueue
  • 中断处理函数callback,receivecount
  • 上层APP调用rpmsg_recv,把数据copy到应用中去

IPCF 跨平台通信框架


Inter-Platform Communication Framework (IPCF)   是一个子系统,它使应用程序能够运行在多个同质或异质处理核心上,位于同一芯片或不同芯片上,运行在不同的芯片上。操作系统(AUTOSAR、Linux、FreeRTOS、Zephyr 等),通过各种传输接口进行通信(共享内存等)。

下图为恩智浦提出的一个方案,提供给用户的API相对友好,利用了Zero-copy的技术,从用户空间或用户application copy到共享内存中效率较高。

图片

流程

下面解释一下IPCF的流程。

UNMANAGED 两个API就可以实现一个动作,Channel是固定的,先取到一个buffer,做一个内存写的动作,中断出来后,有个中断处理函数,中断处理完成后会进行callback直接会把memory地址给到APP读出来,如下图所示。

总体来说,Unmanaged的效率还是比较高的。

图片

MANAGED这边有些小区别,需要告诉对方chan_id、buffer、size,然后触发中断,对方收到后会有另外一个callback接口,会把buffer、size等告诉app,app用完之后会还掉buffer。这就是一个简单的Managed的过程。

图片

实例


基于IPC技术,我们举一个例子,如下图所示。

在左边的R5核中部署了一些SWC,利用CDD模块来实现IPC。SWC可以实现一些逻辑,它会把信号通过IPC路由到A核的SST(信号服务转换)模块,SST会把信号包装成服务,通过服务接口,在控制车窗模块提供基础服务。

图片

上述中会有一个比较关键的技术:信号到服务的转换。

其他关键技术点


  • QoS (不同的核访问外设资源时候的优先级分配)

  • Firewall(核与核之间访问内存的硬隔离)

  • DeviceManagement (灵活分配外设资源到不同的物理核)

  • InterruptRoutine Management (配合DeviceManagement, 中断路由管理)

  • TimeSync (不同核之间的时间同步)


异构SoC的BSP非常大,也是项目开发难度比较大的点。下图可以看到A核通常是一个Linux的一个BSP,R核通常会是一个MCU的一个BSP,通常它还会有很多的tool chain,包括编译的工具,调试的工具,辅助的SDK。

图片

这边举了一个TI 821的例子(J7是一个内部代号),可以看到,它的R核上会有SBL,A核上会有SPL,可以从A核先启动,也可以从R核先启动。

当然也支持CP AUTOSAR,需要我们做一定的适配。工作量也非常大。

也支持LWIP,一个轻量化的IP协议栈,一般使用AUTOSAR的时候,会用AUTOSAR的协议栈。

还有PDK Driver,里面包含了外设驱动等。

下面两个链接是SDK的介绍文档,大家如果有兴趣的话可以自己去看一下。

https://software-dl./jacinto7/esd/processor-sdk-rtos-j7200/08_01_00_11/exports/docs/psdk_rtos/docs/user_guide/index.html

https://software-dl./jacinto7/esd/processor-sdk-linux-j7200/08_01_00_01/exports/docs/j7200/devices/J7200/linux/index.html

本期分享就到这里,下期见。

联系我们

AP & CP工具链、咨询、培训、外包;SOA方案;车载OS;工具链及设备租赁等,也可以随时跟我们联系哦。


联系我们

support@shactiontech.com


结  束

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多