中央计算及其软件架构

汽车架构变化趋势

在分享中央计算软件架构之前，我们先简单说明一下汽车架构变化趋势，总的来说，主要包含以下阶段：

分布式架构：ECU 数量超过 100 个以上，每个 ECU 承担相对独立的功能系统。持续维护数量日益增加的 ECU 变得越发复杂和费时费力。

(相关资料图)

功能域架构：域功能合并后，一方面可以减少 ECU 数量（缩减芯片和外壳的总体成本）。另一方面，软件应用集中化部署后有利于软件功能升级和管理。然而，要实现跨域功能的交互，系统设计依然繁琐且没有效率。

中央计算+区域控制架构：功能逻辑上移到中央计算，区域控制器控制数据和配电。实现硬件和软件的解耦，便于软件快速迭代。

图-汽车架构变化趋势

中央计算+区域控制架构的核心是分布式计算系统，通过远程过程调用（RPC）实现各个主机之间的资源和算力共享。区域控制器掌握的是该区域的控制器与传感器的硬件资源，以及一定的算力处理边缘计算。

而中央计算集群拥有高性能计算能力，图像资源采集，以及接入云端资源的能力。它们之间需要交互才能创造出新的用户体验和使用场景，为支持这种分布式计算系统，就需要一套强大的 RPC 机制：

互联网行业 RPC 框架

- 应用级的服务框架：

Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud

- 远程通信协议：

RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)

车内中央计算+区域控制RPC框架

- 应用级的服务框架：

具代表性的如大众 VW.OS，国内外整车厂都已经开始了应用级服务框架的定义和设计。

- 远程通信协议：

SOME/IP,DDS,REST,MQTT等轻量级通信协议

其中 SOME/IP 是专门为车载领域设计的基于服务的 RPC 通信协议，其他几种协议在其他行业已运用。

图 - RPC通信概览

上图出现的 Client, Server 是 RPC 通信的基本元素。一个完整的 RPC 框架，包含了服务发现、服务质量、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。

图 - 完整RPC框架

AUTOSAR 标准文档中包含了多个 SOME/IP 相关的文档。它们是：

SOME/IP Protocol

1.SOME/IP on wire-format (Serialization)：

-Structure of Header Format

-How the different data types are serialized as per SOME/IP

2.Protocol for Event and RPC-based communication

-Transport Protocol（同时支持UPD和TCP）

-Rules that govern the RPC for SOME/IP

SOME/IP Service Discovery（SD）

1. 定位服务实例：

2.检测服务实例是否在运行（即服务实例的状态）

3.发布/订阅行为的管理

SOME/IP Transport Protocal（TP）

- 对长数据的数据流控制：

SOME/IP Transformation

-填充 SOME/IP Header 和 Payload 的规则

下图中SOME/IP Demon管理服务的注册，服务的通信建立和转发。

图- SOME/IP RPC框架

中央计算架构代理的挑战

混合算力要求

在自动驾驶和网络互联需求下，对中央计算算力提出更高的要求，同时传统的车身，底盘，动力等功能上移，也需要中央计算单元具有实时安全计算的能力。

以下是推功能算力的估算

主动安全与自动驾驶

- NCAP & L2：大于20 TOPS

- Auto-Pilot: 大于40 TOPS

- RoboTaxi: 大于200 TOPS

车身控制，底盘，动力域总和：

- 大于10000 DMIPS

核间高速通信

以下场景使得对核间的数据通信需求增加，为核间高速通信，可靠通信提出了要求。

主动安全与自动驾驶：庞大的视觉及雷达数据

大数据收集，log & Trace 数据

信号与服务的转换

功能分配

功能组件分布部署在中央计算集群以及区域控制器上，对以下方面提出要求。

功能合理部署

提高组件复用性

优化组件的相互调用

中央计算单元发展路径

中央计算早期雏形

于2011 年，奥迪 A8就开始了定位于 L3 系统的研发，其核心模块 ZFAS虽然是自动驾驶控制器，但也可以认为它是中央计算的早期雏形。它是异构的系统架构，包含MobiEye EyeQ3，NVIDIA K1, Cycline, Aurix.

图- Audi ZFAS

在这样一个典型的异构系统中，处理器之间的通信是什么复杂的，其采用的主要技术有：

Deterministic 以太网 – Time Trigger Ethernet

平台软件中间件 – MotionWise Middleware(Communication, Safety, TimeSync, Platform service)

图- Audi ZFAS异构系统概况

异构系统的核间通信

异构系统的核间通信是个难题，通常情况下会包含 MCU, GPU, FPGA, MPU 系统，在它们之间需要保证高性能的实时消息通信，并且要支持面向服务，以及核间互不干扰。

对于每个异构系统内的操作系统，在它们之间应设计高速核间消息通信的机制，以及通信式样，典型的有Client-Server 通信式样。

图-异构系统的核间通信

异构系统操作系统

MCU 系统，常见的有多核 AutoSAR 软件架构，或者使用 MCU Hypervisor 方案。

GPU 系统，管道式的软件架构局多，采用 RTOS 之上运行 Runtime, Library，Appliation 的方案。

MPU 系统，使用虚拟化方案运行多个 High Level OS，每个 OS 之上运行各自的中间件以及上层应用软件。

图-异构系统的操作系统

异构系统的将来 - 单 SoC 系统

新硬件技术使得分离的芯片架构可以集成到单独芯片，实现“一颗芯片上的软件架构”。

单 SoC 系统优势:

在不同域和功能分区之间高效地共享高带宽数据。

更好地利用车内资源共享和设计功能回退机制

更有利于硬件抽象化设计

减少传统单体系统的规模（高集成度，高复杂性地模块）

硬件变种减少

减少暴露在外的通信总线，减少信息安全攻击的路径

缩小产品尺寸

图- 异构系统转向单SoC系统

混合关键系统

中央计算架构的变化使得多种安全等级的应用运行在同一个系统中，特别是单 SoC 系统后，"混合关键性"额外的重要。

“混合关键系统”应允许在同一高性能处理器上并行托管 1 个或多个安全关键性功能/系统，以及其他不受控制甚至是恶意的功能/系统，但绝不会对该安全关键性功能/系统产生任何负面影响 。

例如娱乐系统中通常会允许安装用户自定义应用程序，这些应用程序将成为风险的来源。通常的对策是让这些应用运行在容器定义的沙盒环境中，对这些应用程序仅开放受限制的访问权限。

图-混合关键系统

在功能安全软件需求的章节中有提到，不同 Safety Level SWC 组件Co-existence和 Freedom from interference 的问题。

下图举例说明了 Interference 的干扰源，及做到 Freedom from interfence 相对应的措施。

图-干扰源及应对措施

中央计算单元功能分配

对于单 SoC 方案的中央计算单元，它具备以下能力，这些能力可以指导布局应用功能。

将 ASIL-B 到 ASIL-D，具备 FuSa 要求的 SWC，以及 QM 的软件组件部署在同一个 SoC 系统之上。

核间通信 IPC

-信好与服务的转换

- 数据收集(Log & Trace)

- 其他各类数据交换(OTA, IDS...)

拥有视觉处理能力, 支持 OpenVX, 流水线处理, 图像并行处理

集成R核 MCU 后，拥有快速应用启动功能，支持集成车身，网关等功能

A 核可以部署和人机界面，多媒体，互联等相关的应用

图-中央计算单元的功能分配

应用示例

在中央计算+区域控制的架构中，有两种不同的设计风格体现，一个是基于服务的式样，另一就是基于信号的式样。

现阶段传统的执行器与传感器仍是基于 CAN/LIN 信号的设计的，而中央计算单元已可以依照基于服务的式样设计。这两种不同的设计风格由区域控制器完成基于信号的世界与基于服务的世界转换。

以下应用示例涵盖了中央计算单元，区域控制器，执行传感器的互动过程。

示例需求描述:

当启停开关按下后，车辆电源模式切换到 ON 档。

当车速大于 5km/h，则执行车辆上锁。

整个执行过程如下：

区域控制器直接采集启停开关，同时通过 CAN 通信收集车速信号

区域控制器完成信号至服务的转换，以服务的内容提供给中央计算单元，之间通过以太网通信。

中央计算之内的应用之间的接口也是以服务方式通信，采用操作系统系统的 Local IPC 机制，如 Local Unit Socket。

经由上次逻辑处理后，再调用某区域控制器提供的服务，如上锁操作。

最后区域控制器将上锁指令转换为 CAN 或者 LIN 的报文，由门模块执行上锁的操作。

图-中央计算与区域架构应用示例

关键词：