传统汽车工程技术人员面对新架构的难点

传统汽车工程技术人员，在面对汽车新架构开发的过程中，经常会表现得有点不知所措，最根本原因，是原有知识背景和对工程体系的认知框架，在面对大量的计算机、IT和通信行业的跨界技术的时候不匹配。

如果说将传统汽车架构向智能汽车架构的演进，类比为传统手机向智能手机的迭代，个人认为不是很贴切，但是这里面在一个关键点上是共通的：传统手机和智能手机承载的社会价值是完全不对等的，传统手机主要提供的是移动电话、短消息、资讯服务这些功能；而智能手机出现后，带来了整个O2O商业模式对衣食住行各个方面的全面颠覆。所以说，未来可预见的智能汽车，对人的出行方式带来一定的颠覆，甚至全面的颠覆，是完全有可能的。因此，智能汽车承载了传统汽车工程技术人员不具备的智能出行体系维度的系统需求，传统汽车人很难驾驭智能汽车的新架构和新场景也就说得通了。

要说清楚传统汽车工程体系和IT工程之间的知识壁垒，是个巨大的话题，这不是这篇推文所能涵盖的。这里仅从汽车以太网和软件工程角度出发，简单罗列一些给传统汽车工程师造成困惑的案例，欢迎行业专家一起参与讨论。

一：对汽车以太网交换芯片认知的困惑

汽车以太网和传统CAN网络的各种技术对比，随着这几年来汽车以太网的普及，已经是比较明确的概念了，这里不用多说。而汽车以太网是传统以太网的跨界应用，这种应用过程里多了对一样新实体的应用，在传统CAN网络里没有，就是以太网交换芯片。

以太网交换芯片在通信行业是一个高度垄断的IC市场，目前量产汽车的以太网交换芯片虽然不是那个市场里最核心最高端的技术，但已经是个非常复杂的科技含量非常高的定制化片上系统（SoC），包含很多独特的芯片工艺（如TCAM，三态存储器，Packet Buffer流量缓冲区存储器，等等）。

这里不展开描述交换芯片架构和制成工艺的技术细节，引用一张IEEE核心技术专家在技术论坛上的图，这是这位专家对他认为的Ethernet DNA的描述。回顾以太网技术的产业化，归根结底落实在芯片技术上，所以Ethernet DNA我认为即代表了Ethernet IC的DNA，即以太网芯片的发展和产业化；以太网芯片在通信行业的发展过程中，到底强化了什么，弱化了什么，又摒弃了什么，牺牲了什么？那些弱化、摈弃、牺牲的部分，单单靠一个汽车行业，是很难形成强大的市场价值需求去推动和补足的。

引用自IEEE SA Ethernet &amp; IP @ Automotive Technology Day

汽车工程师对汽车以太网交换芯片认知的困惑，我认为主要体现在对芯片产业价值链的不熟悉，对一些高度垄断的关键技术没有充分的了解。参考上述Ethernet DNA，以太网交换芯片针对汽车行业的定制性过程与CAN网络芯片相比，可以说是从负数开始的，是一个改造DNA的过程，需要经历一个相当漫长的行业博弈。而对这个“负数”评估，会困惑汽车工程师很长时间，因为一旦应用了交换芯片，就已经默认移植了大量应用在别的行业的“DNA”到车上，而这些DNA是和汽车工程的需求不匹配的，对这些DNA背后的芯片行业产业链的认知，对传统汽车工程师来说也是相当痛苦的过程。

二：对大带宽多事件触发的分布式计算网络认知困惑

计算机分布式网络的架构设计和评估指标，与传统汽车CAN/LIN网络是有很大区别的。最显著的不同点在于，由于网络总带宽很低，负载很小，传统汽车CAN/LIN网络（概念等同于Classic Platform）规划的ECU单节点发送的数据包，几乎不可能对ECU节点的芯片本身产生太多系统开销和负担。而且因为ECU内的软件是一次性规划好的，不存在业务的迭代和升级，一旦发现ECU节点系统资源的瓶颈，就可以在下一代扩充ECU内的MCU资源。

但是计算机分布式网络（概念等同于Adaptive Platform），软件的迭代和业务的开放性，导致单节点设备的数据包发送，在没有对网络造成过载之前，可能首先因为软件的加载，先对自身系统造成了设计规划之外的严重负载。也就是说，实际整个系统网络带宽的利用，很可能不是由网络传输芯片和网络交换芯片决定的，是由软件和系统设计以及单设备节点系统资源调度合理性决定的。通俗来说就是，不是网络带宽不够导致数据包丢失，而是数据包发不出去被节点设备的Buffer丢了；不是网络数据包转发延迟了，而是节点的CPU任务调度的拥塞导致数据包压根还没被处理；还有可能，不是CPU慢，而是挂载在CPU总线上某外设的I/O吞吐率在拖整个系统的后腿。

对于传统汽车工程师，由于知识背景的关系，缺乏对计算机系统和网络协议栈的认知，所以在定义和评估汽车以太网性能和设计指标的时候，往往很难界定导致网络性能瓶颈的系统设计需求到底是在网络层还是在业务层。因为在IT行业，设备是可插拔、可替换、可扩展的，没有汽车工程里面这种在设计之初就要严格论证考虑全生命周期的情况。

这里还是借用两张同行的概念图来说明情况，第一张图来自Continental，我认为表达了以太网ECU里面的网络层和业务层是一个系统整体，不能区分来看；另一张图来自RTI，讲得非常明确，分布式计算系统的网络延迟最多来自于多个节点数据包收发和业务处理过程中的Memory Copy，规划和管理整个分布式系统各种数据业务处理过程中的Memory Copy的次数，是解决网络系统瓶颈的首要问题。

引用自Continental 2017， Dr.-Ing Heige Zinner

引用自RTI 2019， A Game-Changing Leap in Autonomous Vehicle Software Architecture，Bob Leigh

三：对多核计算平台的操作系统认知的困惑

我们首先还是引用计算机行业对操作系统的定义：

An operating system (OS) is software that, after being loaded into the computer by an initial boot program, manages a computer’s resources, controlling the flow of information into and from a main processor. OSs perform complex tasks, such as memory management, control of displays and other input/output peripheral devices, networking and file management, and other resource allocation functions between software and system components. The OS provides the foundation on which applications, middleware and other infrastructure components function. An OS usually provides user interfaces, such as command-line shell and GUI, for interaction between user and computer.

——source https://www.gartner.com/

我们再换一套通俗的表达方式来理解操作系统：

计算机是由若干硬件组成：显示器、CPU、内存、主板（提供总线）、键盘、鼠标、硬盘等。计算机的发明是帮助人类完成一些计算与逻辑任务。但是人们不能直接的使用计算机硬件，需要在计算机硬件上包上一层软件，我们使用这些软件来完成一些特定的任务，比如进行数学计算、文字排版、聊天、邮件等。

操作系统就是计算机硬件与应用软件之间的一层基础软件或中间件（或者说是接口），有两个作用：1、方便我们使用计算机硬件；2、更高效地使用计算机硬件。

操作系统的硬件管理包括：CPU管理、内存管理、终端管理、磁盘管理、文件管理；网络管理、面向服务的接口管理、共享存储区管理、多核管理，等等，这些属于高级操作系统的实现。

部署在端设备的操作系统，可以简单抽象为上图的形式，但是也只是概念图而已，并不严谨。如果是云操作系统，或者AI操作系统，就完全是另一种定义方式了，这里就不展开了。

对于传统汽车行业工程师来说，同样是因为知识背景的关系，对于车内传统的操作系统（OSEK OS）和计算机行业的操作系统以及对应的软件生态的理解和定义都是有严重偏差的。

操作系统在现实世界里有一个概念的外延，即操作系统软件生态，是一系列支持微机芯片和嵌入式硬件系统的基础软件组件的一种集合形式，而组件的具体定义和实际形态是软件生态演化而来的。不同的行业嵌入式场景需求会演化出不同的软件生态，参与定义操作系统共性需求的利益团体包括芯片公司、硬件生产商、通信科技公司、软件服务公司、广大程序员等。

操作系统软件生态的最基本的三个作用：

支持芯片和硬件资源的抽象的高效的使用；
支持程序员和用户的各种共性需求；
通过互联网开源工作项目的方式形成架构和接口实现形式的广泛统一（非开源OS产品也可以有开发者社区）。

如上所述操作系统的一般需求共性，不体现在具体的某个汽车域控制器的系统设计和项目交付上；不体现在软件的解耦；也不体现在平台的兼容性；更不体现在对汽车系统的软件优化；这些都是汽车行业去额外赋予的“细分共性需求”，而不是可以廉价获取的“已经落实的共性需求”。

四：对车云一体的边缘计算形态认知的困惑

智能汽车这一代新架构是车云一体的架构形式，简单说，座舱系统在新架构即不是大手机，T-BOX在新架构里也已经不是简单的通信转发模块；整个系统是云端系统，加上边缘计算单元，加上车内子系统合而为一的多级计算的体系。这与传统的计算机分布式网络又有所不同，可以简单用下图表示：

汽车工程师对IoT世界的边缘计算概念的认知模糊，造成了对于多级计算理解的误差和架构定义的困难。我们可以把负责车内边缘计算的单元，简单定义为“数据处理和协议转发”，但是部署到这类具体的嵌入式硬件系统上，并不是那么容易的事情，从底层协议和上层应用接口，到再上层逻辑接口，由于涉及不同的业务逻辑、软件封装以及传输协议，层次并不是那么清晰，互相的边界和依赖关系也很模糊。更有效的方式，是通过一个车云边缘计算的参考平台项目来边实践边理解。

五：对开源软件生态下的软件系统模块化认知的困惑

这个章节里的内容在之前操作系统章节稍有涉及，由于篇幅的原因就不展开了，汽车工程是一个标准的MBSE工程（Model Based System Engineering），只有把MBSE做扎实了，才能给OEM和相关研发测试团队带来实际的利益，行业标准化的红利才会真正落到实处。面向新架构的汽车软件MBSE怎么做，部分基于开源生态的MBSE又怎么做？这个话题就不是这篇小小推文所能涵盖的了，我认为是个全行业需要面对的问题。

一个小建议：说了这些，都是在谈问题，具体有什么改进的建议呢？可以考虑通过系统性的学习一些计算机和IT基础知识，来构建对跨界技术的认知框架。汽车IT化，广大传统汽车工程师的思维也需要IT化，IT世界相对开放，但是也没有开放到看几篇软文或者搜索几篇没头没尾的技术贴就可以熟练理解的程度。通过一些经典教材来建立IT、计算机和分布式网络通信的概念是有必要的。

深入理解计算机操作系统（原书第三版）

需求分析与系统设计（原书第三版）

计算机网络（原书第七版）

软件建模与设计需求工程实践者之路（原书第四版）

TCP/IP详解（原书第二版）

深入理解LINUX内核（第三版）

LINUX设备驱动程序（第三版）