当我们在说车载以太网的时候，我们在说什么

做了一段时间汽车以太网的开发，粗略地记录一些肤浅的想法。

带宽，性能

以太网最明显的一个变化，就是带宽。

都知道推动以太网上车的最主要驱动力就是infotaiment系统和ADAS系统对带宽无止境的追求。但是除了以太网外，还有很多别的技术提供了很大的带宽，比如LVDS等等。但是BroadR-Reach是仅有的能在这么简陋的线束上提供相对这么高的带宽的技术

在当前（2018年），ADAS领域汽车以太网技术对flexray还是有劣势，AVB还不能取得比Flexray更好的实时性能，所以也没有在ADAS的执行层使用以太网技术的方案。然而对于自主品牌来说，选择以太网基本上就意味着不去投资flexray，而对跨国品牌来说，一般都会同时掌握flexray和以太网技术，所以这几年自主品牌还很难在L3的量产上有太多文章。只有等熬到TSN成熟，提供超过flexray的性能，我们的自主品牌们才能实质性地在ADAS上有好的成果，所以大家还需努力

ICT化

以太网带来的另一个变化除了带宽其实很重要的一个就是汽车技术的IT化。因为TCPIP的引入，很多ICT技术都可以被轻易地用到车上，比如用TLS来保护通信，比如在车内部署一个SQL或者No-SQL数据库和相应的中间件。这样的话汽车运行数据的采集保存技术就可以使用成熟的数据库技术。

这方面其实也带来了对工程师的能力的需求的改变，在面对ICT技术引入车内的时候，年轻的网络工程师和老的网络工程师其实起点都一样，年轻的网络工程师可能包袱更少反而更灵活。

以太网通信方式对架构设计方式的改变

和CAN时代相比，设计车载以太网通信系统有时候和设计CAN的通信系统区别比较大。CAN通信系统的设计，一部分是交付各个规范，比如物理层规范，网络管理规范等等，另一个就是DBC数据库的开发。

和CAN通信系统设计相比，以太网通信系统设计除了交付各个规范和数据库之外，还很大程度上和功能设计耦合起来了。

比如我们设计CAN通信系统，我们可以定义我需要xxx帧按xx周期发送，包含xx信号，而不管ECU具体的功能。具体的功能由ECU的部门和架构的部门去管。

但是设计以太网通信系统，做设计的时候不可能单纯说我在IPxxPortxx要传输一个RTP视频流，而不去管上层有没有一个功能去提供这个视频流。

尤其是SOME/IP通信，作为SOA架构的具体实现方式，SOME/IP的定义本身就和上层的软件模块紧密相连。

从这个角度讲，我觉得以太网时代，汽车网络系统设计和架构设计的界限会变得模糊。从另一个角度来说，传统主机厂组织架构里的EEA部门和网络部门会渐渐出现重叠。

一个例子，接触过一个客户，两个部分，EEA和网络组，在SOA设计里，EEA部门希望做好功能架构设计，然后交给网络部门进行通信层的服务的设计。现场的时候我觉得没什么，但是回过头来一想，功能架构设计好后，通信层服务的设计真的就只是体力活了，甚至大部分工作可以自动化完成，最后手工进行一些ID的调整等工作就行了，这种情况下，网络部门就一定程度上被弱化了。

以太网和autosar

做以太网还有个绕不开的地方是autosar

按理说其实做以太网通信并没有天然地需要autosar的支持，但是如果抛开autosar，抛开SOME/IP，你甚至都找不到另外一种被产业链支持的通信协议以及相应的描述通信系统的数据库，所以很多客户问我们能不能不用SOME/IP，直接UDP广播，或者自己另外设计一个协议？我说可以，只要你付我们钱单独去开发一个数据库格式和全套的工具链就行。

不过话说回来，其实不用SOME/IP，也可以用arxml去描述UDP广播的信号。还真不是问题。

但是无论如何，arxml这种数据库格式在以太网时代是躲不过去了，所以即使车企不上autosar软件的ECU，只要上以太网，就绕不开aotusar的概念了。

目前aotusar的arxml用于描述以太网的通信数据库，不过SOME/IP还是AVB，都还有些问题，TSN的支持更是没有，不知道autosar什么时候会有对TSN的支持。

如果到TSN商用的时候autosar还没有支持，我都不知道我们到时候是不是可以考虑自己开发一种TSN网络通信数据库格式了。