在你开发子网网关功能时发现没买对应插件，你在开发什么

myhomer

目录

1. 子网网关需求分析

2. 野路子实现网关方法

3. S32G LLCE简介

4.小结

---

不止一次碰到过上述情况。之前做VCU需要路由某些关键信号，做座舱需要路由报文给下挂子节点时，本以为使用达芬奇点点点就可以搞定，结果打开Gateway功能，发现采购没购买Add-Ons。抓瞎了，重新提预算的话，不仅成本上去了，开发节点也守不住。怎么办？那就从两头抓，一方面继续追加采购，另一方面考虑根据需求手写。1. 子网网关需求分析

这里暂不考虑整车网关，主要讨论域控新增了子网，该控制器如何进行报文路由。常见的有如下几种报文路由类型：

接收的报文直接透传给下挂子节点，例如诊断里的物理寻址；接收的报文既要被当前ECU处理，还要路由整帧报文给下挂节点，如功能寻址；

接收的报文既要被当前ECU处理，还要路由部分信号重新组包给下挂节点；

除了报文的完整性要求，通常还有网关路由的性能要求，例如转发时间延迟500us等等。本来我们通过PduR和Com这两个模块可以实现上述所有功能，如下图：

但是问题是：第一插件不是还在路上吗，第二500us的要求会不会太严格了。硬件层面的我们暂且不管，就从AUTOSAR这个层级架构来看，报文Gateway的时延主要由以下几部分组成（以CAN为例）：

CAN Driver -> CanIf为T1，CanIf->(CanTp)->PduR为T2，PduR-> Com为T3；那么基于信号的路由延迟总时长就为2*(T1+T2+T3) ，经测试，这个时间难以满足系统的要求。那么有什么办法来解决这个问题呢？我们可以从AUTOSAR整体架构来分析。2. 野路子实现网关方法

从Gateway效率最高的方向考虑，那必然是从Driver这一层级处理，如下图：

这就要求我们通过某种手段写个小函数嵌入到AUTOSAR 通信栈里。我们首先想到的就是通过某些回调函数来进行处理。在《Specification of CAN Driver》7.8节提到，

The Can module offers only an event triggered notification interface to the CanIfmodule. Each notification is represented by a callback function.

很明显，这个接口就是我们最熟悉的CanIf_RxIndication。值得注意的是，该函数通常供应商已经做了具体静态代码，所以如果我们想从这里去修改，技术上可行，但是有商务风险。那再往上层走，有没有这样的接口呢？通过阅读Microsar的TRM，我发现了这样一个接口：

CanIf_RxIndicationSubDataChecksumRxVerify，对接口的描述是：The appending of checksum is application specific and must be implemented within the API。

既然是应用指定的，那我在里面搞gateway功能应该也是可行的。在这里我们就找到了切入点，那么要如何实现gateway功能呢？从通信矩阵入手，做一个类似PduR的示例让系统进行填写，生成类似的路由表CanDriver_RouteTable和对应DBC，先导入到工具里骗骗达芬奇生成pdu handle；然后在该函数里调用CanIf_Trasnmit转发报文，根据是否透传属性决定是否通知PduR。这个方式只能针对特定项目，相对固化，但是至少在Add-on回来之前是有解决方案了。3. S32G LLCE简介

在设计上述方案时，无意中翻到了S32G的LLCE，一张图打消了我的疑虑：

可以看到，大家的思路其实都很类似，在接收到报文那一瞬间就可以考虑路由、Gateway等功能。在软件开发阶段，将PduR生成的Routing Table移植到S32G的LLCE固件中，实现在低层级路由以减小时间、主核资源消耗。但是我为什么要提出来，要知道这是芯片厂在硬件设计时就考虑到了，软件定义汽车、或者说是软件定义芯片的时代难道真的到来了？暂时不废话了，我们来看看具体细节。LLCE全称Low Latency Communication Engine ，它是由多个Core(4个M0+)、Memory(2*160KB)、硬件加速IP、固件组成，用于实现加速标准汽车通信。如下图所示：

该引擎旨在减少主核的中断负载、通信负载，与ATUSOAR通信栈集成，可以实现CAN2CAN内部路由、CAN2ETH、ETH2CAN、CAN\LIN loopback等模式。以CAN2CAN为例，Host侧将路由规则给到LLCE固件，该固件就根据根据进行路由：

这与HSM有些类似，用一个小核来减轻主核的负载，提高处理效率。 最初我以为LLCE就是一个硬件加速引擎，但是深入研究后，要想使用好LLCE，还需要LLCE Firmware配合：

在配置上是直接在Driver层级考虑，如下：

所以，我始终认为，AUTOSAR是个伪命题，虽然定义出了标准，但是从芯片厂、再到供应商、再到OEM，都是有自己的理解和实现方式，一旦换平台，适配工作还是让人头痛，梦想中的即插即用还是有一定距离。4.小结

随着E\E架构的演进，MCU更加趋向于往SOC的方向发展，并且在芯片设计初就会收集各OEM、Tier 1的需求，从硬件层面来考虑软件不好处理或者处理起来代价很高的功能。当我开发子网网关功能时发现没买对应插件，我在思考如上内容，分享给大家。

往期回顾：

1.汽车标定精选
汽车标定技术--标定概念详解
汽车标定技术--Bypass的前世今生
万字长文：汽车标定技术--XCP概述

2.AUTOSAR精选
AUTOSAR CryptoStack--CSM Job夹带了哪些私货
AUTOSAR 诊断栈分析(一)
AUTOSAR OS概述（一）

3.汽车网络安全精选
汽车信息安全--MCU启动常用密码算法
汽车网络安全方案需求分析
汽车信息安全--常见车规MCU安全启动方案
车载信息安全场景概述

4.汽车功能安全精选

5.汽车虚拟化精选

    汽车ECU虚拟化技术初探(一)

    汽车ECU虚拟化技术(二)--U2A虚拟化功能

6.杂七杂八

    Flash模拟EEPROM原理浅析

    征途漫漫:汽车MCU的国产替代往事

    车规MCU应用场景及国产替代进展