当我们谈论智能汽车的通信时，我们在谈论什么？热门的SOA技术是不是智能汽车交互机制的“终局”？让我们用一篇文章来深挖、讲透这些概念。
通信的基本概念
通信技术是非常多样的，每种技术在传输速率、成本、成熟度、时延、稳定性、安全性等上的特性也不同，但其结构是类似的。
讨论通信技术，一般都会从开放式系统互联通信参考模型（OpenSystemInterconnectionReferenceModel，OSI）开始。
应用层：面向用户的一些服务接口
表示层：对数据进行翻译、加密和压缩
会话层：建立、管理和终止会话
传输层：提供端到端的通信连接方式，包括分包、重组、流控等（段Segment）
网络层：负责数据包端到端地传递和互联过程，类似邮寄的起终点（包PackeT）
数据链路层：负责实际的传输管路，将数据可靠地传输到相邻节点，类似物流中转站（帧Frame）
物理层：负责物理媒介上的传递，类似货车（比特Bit）
通信技术的选择是根据业务要求以及技术本身的特点来决定的。比如以太网（TCP/IP）协议的层次设计更加复杂，因此可以支撑互联网业务的多样需求。而车端的CAN协议则简化了各层的设计，以满足车辆可靠性和低时延的要求。
整车常用通信技术
进一步地，我们罗列了目前主流智能汽车所采用的一些通信手段，如下表所示：
LIN网络是一种低成本的串行通信网络，主要起到辅助CAN的功能。在很多对带宽和功能要求不高的通信场景，使用LIN总线能够节省成本。LIN采用单主控制器/多从设备的模式，一般会和CAN配合使用，处于整个电气架构的末梢位置，连接一些实时性要求不高的终端设备（门、座椅等）。
FlexRay网络是一种高速可确定性的、具备故障容错的总线系统，一般为双线连接。用户可以配置静态传输，发送安全性较高的周期信息，使用时分多路（TimeDivisionMultipleAccess，TDMA）方法，对每个通信节点进行计划性的时间分配；也可以配置动态传输，发送频率不稳定的非安全消息，使用柔性时分多路(FlexibleTimeDivisionMultipleAccess，FT-DMA)方法，轮询每个通信节点，确认是否有信息发送。相比CAN通讯，FlexRay的成本更高但实时性更好，一般用在高安全要求的控制器通信上。
低电压差分信号（Low-VoltageDifferentialSignaling，LVDS）是一种低功耗、低误码率、低串扰和低辐射的差分信号技术，具有功耗小、抗噪声能力强、电子干扰小等优势，一般用于高速I/O（比如相机视频流）的传输任务。
除了上述通信技术外，行业内目前最热门的的，目前来看仍然是CAN/CAN-FD网络以及基于以太网的SOA(SOC)通信，我们重点展开。
CAN/CAN-FD通信
CAN/CAN-FD网络是目前智能汽车通信的绝对主力，拥有较好的性能、极高的可靠性和低廉的价格。不同于以太网通信，CAN/CAN-FD网络更多地是为了适应分布式构架下的多个控制器之间的互联而存在。
CAN的原理有很多文章都已经介绍过了，本文不再作为重点去重复讨论。
CAN-FD协议可以理解成CAN协议的升级版，物理层未改变，但协议层的传输速率、数据长度、帧格式等均有改变。比如，将CAN的每帧8字节数据提高到64字节，波特率从最高的1Mbps提高到5Mpbs，这大大提升了车辆的通信效率。
CAN-FD提高了数据包组织的灵活性，可以支持AutoSAR框架下的PDU概念。PDU分为ContainerPDU和SignalPDU两类，前者是后者的容器，而后者用于存放具体信号。相比传统固定长度的CAN信息，CAN-FD可以根据需求在发送时动态配置内嵌SignalPDU的位置和个数，由此可以更灵活地适配负载和业务要求。
这种灵活性往往需要测试人员具有更高的专业素质，因为，配置灵活性增强的同时会加大信号解析和检查的难度。
无论是CAN还是CAN-FD，其本质上仍然是一种基于信号的通信，无论PDU增加了多少灵活性，CAN/CAN-FD依然带着浓厚的“通信”烙印，在本质上，发送方、接收方的组织仍然是固定的，调整也是缓慢的。而我们接下来要说的基于以太网的SOA，相对来说就更为灵活。SOA虽然常被用于和CAN进行对比，但其实已经不是一种通信手段
以太网通信
智能汽车以太网通信的协议栈相比CAN更为复杂，当然其覆盖的业务面也更宽，灵活性也更高，是目前域控制器之间通信的主流方案。如下图所示：
当前，智能汽车的以太网通信有两条发展路线。
一条路线就是时间敏感网络（TimeSensitiveNetworking，TSN），这是从链路层往上的一次全面改进，是未来具有较大潜力的一种以太网通信协议，但目前的应用仍在探索当中。当前被采用更多的是另一条技术路线，即对常规以太网技术的改进，主要调整底层和应用层的设计，但保留了绝大部分网络层及传输层的设计，可以和传统互联网无缝衔接。
以太网之上的SOA
了解完以太网通信的基本构成，紧接着我们就可以来讨论SOA，即面向服务的架构（Service-OrientedArchitecture）。SOA实际上并不是一种具体的技术，而是一种架构策略层面上的指导思想或者范式，是为了更好地组织和利用处于不同所有权范围控制下信息的一种分布式设计。
SOA不是一种单纯的通信机制，虽然看上去与CAN这类基于信号的通信类似。但仔细比对，会发现两者有着本质上的区别。如下图所示：
面向服务的通信定义了“服务方”和“消费方”，“服务方”是传统意义上的发送者，而“消费方”是一种接受者。
在整车应用当中，我们可以通过AutoSARAP或者自主研发的生成工具，完成类似CAN的通信矩阵生成，满足各个域控制器之间的通信需求。与CAN相比，较为明显的区别除了通信载体不同外，SOA还具有以太网SOME/IP所支持的服务发现功能，可以动态建立域控制器之间的传输链路，从而实现动态拓扑的构建，由此提升软件更新过程中的灵活性。
不同于固定的信息传输，消费方可以利用“服务发现”，订阅某几个服务方准备好的信息输出服务。应用程序之间是一种松耦合的连接，消费方的需求发生变化，服务方往往不需要作出变化。但这往往只达到了面向服务通信（Service-OrientedCommunication，SOC）的程度，还没有上升到SOA，依然还是一种从“通信”角度出发的思考。
由于SOA更多地被拿来和CAN进行类比，因此很多负责通信网络配置的从业者也往往习惯从“通信”角度对其展开思考，这让SOA的作用大打折扣。在接触SOA的初期，人们对SOA的很多定义和设计也非常不理解，这很大程度上也是因为受制于“通信”这个固有思维模式。
其实理解SOA非常简单，如果从“计算”这个视角出发，很多问题就会迎刃而解。
如下图所示，如果我们从软件开发人员的视角来看，SOA其实更多地是一种函数交互。一个函数的调用看上去就是一种“计算”过程，当然其背后也隐藏了“通信”的概念。一般情况下，通过内存指针的牵引，我们才能在调用某个函数时，找到对应的方法和数据，而SOA在很大程度上更像是将函数调用的“指针和内存”变成了“ID和网络”。
用面向对象编程的思想理解SOA
从“函数”这个角度继续分析。如下图所示，我们看SOME/IP所提供的服务类型，其所描述的服务（Service），更多是一种“类”的概念。例（Instance）是对“类”的方法做调整，而接口（Interface）以及事件组（EventGroup）的标记是对“类”的数据结构做调整。而Interface之下的Event、Method和Field更像是对某个数据结构读写权限的约束以及输出方法的设计。类的交互往往是“双向”的，SOA其实也是双向的。然而，由于受到“通信”概念的约束，SOA常常被强制设计为一个“单向”过程。
SOME/IP的服务类型
本文认为，SOA设计之初，实际上是希望实现在多个域控制器上的开发，可以做到像在一个域控制器上开发一样方便。如果从软件设计模式的角度出发看SOA设计，确实可以更为容易地达成这个目标。但在实践中，同时做过软件开发的网络配置工程师非常少，且不同域控的配置工程师也大都不了解彼此的业务领域，可以统筹多个域控制器的软件架构工程师更是凤毛麟角，SOA的实现往往就卡在这个点上。
SOA是智能汽车的终局吗？
那么，SOA是不是就是智能汽车的终局？
其实并不是。如下图所示，我们将交通出行业务的演进和通信架构的演进做了对比。
在交通系统中，私家车代表了人和车的固定映射关系，在不约束需求的情况下，交通系统的整体负载以及负载的均衡都是很难实现的，交通拥堵以及停车资源不匹配等问题，必然频现。共享车逻辑出现后，打破了人和车的固定关系，情况有所改善，交通系统的利用率提升了。但毕竟开车的还是司机，虽有奖励系统的调节，但其仍然受到个人生活作息以及营运偏好的影响。共享出行的下一步是基于无人驾驶的智能出行，因为解绑了人和车的关系，并且从能源补充到行驶路线都是系统全局规划的最优结果，所以，极有可能成为交通系统发展的终局。
通信的发展其实也是一个道理，基于信号的CAN通信，反映的是一种固定的信号交互过程，无法有效满足业务的变化。
SOA改变了这个过程，其建立了信号交互的可变关系，像超市购物一样，不管你选择超市里的哪种货品（服务），这个通信过程都是成立的。但其也存在不少的约束：第一，通信的带宽负载和计算消耗伴随链路的调整仍然会产生运算的不稳定，因此还需要工程师参与进行一些适配性的设计；第二，无论服务设计如何灵活，但其接口仍然依赖人工设计，所能提供的服务也仍然需要人去设计，不可能超越开发人员的认知范围。
未来是否有一种交互过程更加细腻，且变更后仍能保证运算稳定性的通信机制存在呢？答案是肯定的，那就是深度学习。
举个典型的例子。想象有一天，你愁容满面地坐进车里，汽车主动给你放了一首你悲伤时常听的歌曲。你在诧异其表现时，似乎还有点感动。但机器可能并没有这么感性，它只不过一直在分析你和车内所有接口的交互数据，发现了表情识别结果和这首歌的播放之间存在明显的相关性。我们可以通过深度学习模型来捕捉这种相关性，这种级别的网络模型训练甚至可以在车上完成。当系统发现你的行为模式存在规律性时，便可以在下次满足触发条件时，主动完成后续的操作。
在这个案例里，我们能看到深度学习相对SOA又有了新的优势。每个人不只是订阅既有的服务，更拥有了私人定制的、粒度更细的服务。并且这种变更，可能不需要通过OTA升级来获得，而是由用户在本地自行培养。
基于上面的分析，本文总结得出了智能驾驶服务的三个阶段。第一阶段是构建固定且稳定的关系，第二阶段是构建可变但不一定稳定的关系，第三阶段是构建可变且稳定的关系。我们当前处在第一阶段向第二阶段的过渡中，而要进入第三阶段，核心就是要尽可能的去除人对服务执行的干预。
智能汽车从“通信”到“沟通”
人们对通信的一般理解，一直停留在无损地将一个信息从一处传输到另一处的整个过程。但这并不是通信的全部。
如果我们对一个基本的通信过程建模，就会发现其存在两个基本条件。第一、编码器和解码器之间共享一个密码本，用于保证信息一致；第二、接受者和发送者存在一种共同的理解，促使行动一致。但整个过程中噪声一直存在，编解码过程的噪声更多地是一种传递上的损失，而发送与接收者之间的偏差则往往是一种理解上的差异。
将这个模型引入人和人的沟通以及机器与机器之间的沟通，情况也是类似的。人和人之间的理解存在偏差，机器和机器之间也同样如此。信息传输虽然是单向的，但信息的理解和转换往往是反复双向磨合的过程。
真实的交互过程是通信和计算共同作用的结果。如下图所示：
有一个网络诈骗的例子，也许能让我们更深地体会，信息传递一致和行动一致之间的差异和关系。曾经有个男性诈骗人员将自己包装成女性和另一男性交往，骗取了大量钱财，其中有一段聊天记录曝光，女方（假扮）说：“你自己都没钱了，不要借给我了，我不喜欢男生身上没钱。”这句话非常有意思。诈骗人员要确保自己的想法和对方的行动保持一致，即让受害人交出钱财，但其实际传递的信息却和自己的想法完全相反。可耐人寻味的是，由于这句话刺激了受害人作为男性的自尊心，使其更愿意将钱借出去，从而在行动上让诈骗人员达成了自己的目的。
对当下的智能汽车来说也是一样的，除了保证，底层通信的“无损”，还要去挖掘沟通过程的体验。从CAN到SOA再到深度学习，智能汽车的演进过程中，通信和计算的概念会进一步模糊化，机器更多地需要从”信息传递“，向”沟通交流“转移。