當我們談論智能汽車的通信時，我們在談論什么？熱門的SOA技術是不是智能汽車交互機制的“終局”？讓我們用一篇文章來深挖、講透這些概念。

通信的基本概念

通信技術是非常多樣的，每種技術在傳輸速率、成本、成熟度、時延、穩定性、安全性等上的特性也不同，但其結構是類似的。

討論通信技術，一般都會從開放式系統互聯通信參考模型（Open System Interconnection Reference Model，OSI）開始。

• 應用層：面向用戶的一些服務接口
• 表示層：對數據進行翻譯、加密和壓縮
• 會話層：建立、管理和終止會話
• 傳輸層：提供端到端的通信連接方式，包括分包、重組、流控等 （段Segment）
• 網絡層：負責數據包端到端地傳遞和互聯過程，類似郵寄的起終點（包PackeT）
• 數據鏈路層：負責實際的傳輸管路，將數據可靠地傳輸到相鄰節點，類似物流中轉站（幀Frame）
• 物理層：負責物理媒介上的傳遞，類似貨車（比特Bit）

通信技術的選擇是根據業務要求以及技術本身的特點來決定的。比如以太網（TCP/IP）協議的層次設計更加復雜，因此可以支撐互聯網業務的多樣需求。而車端的CAN協議則簡化了各層的設計，以滿足車輛可靠性和低時延的要求。

整車常用通信技術

進一步地，我們羅列了目前主流智能汽車所采用的一些通信手段，如下表所示：

LIN網絡是一種低成本的串行通信網絡，主要起到輔助CAN的功能。在很多對帶寬和功能要求不高的通信場景，使用LIN總線能夠節省成本。LIN采用單主控制器/多從設備的模式，一般會和CAN配合使用，處于整個電氣架構的末梢位置，連接一些實時性要求不高的終端設備（門、座椅等）。

FlexRay網絡是一種高速可確定性的、具備故障容錯的總線系統，一般為雙線連接。用戶可以配置靜態傳輸，發送安全性較高的周期信息，使用時分多路（Time Division Multiple Access，TDMA）方法，對每個通信節點進行計劃性的時間分配；也可以配置動態傳輸，發送頻率不穩定的非安全消息，使用柔性時分多路 (Flexible Time Division Multiple Access，FT-DMA)方法，輪詢每個通信節點，確認是否有信息發送。相比CAN通訊，FlexRay的成本更高但實時性更好，一般用在高安全要求的控制器通信上。

低電壓差分信號（Low-Voltage Differential Signaling，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分為Container PDU和Signal PDU兩類，前者是后者的容器，而后者用于存放具體信號。相比傳統固定長度的CAN信息，CAN-FD可以根據需求在發送時動態配置內嵌Signal PDU的位置和個數，由此可以更靈活地適配負載和業務要求。

這種靈活性往往需要測試人員具有更高的專業素質，因為，配置靈活性增強的同時會加大信號解析和檢查的難度。

無論是CAN還是CAN-FD，其本質上仍然是一種基于信號的通信，無論PDU增加了多少靈活性，CAN/CAN-FD依然帶著濃厚的“通信”烙印，在本質上，發送方、接收方的組織仍然是固定的，調整也是緩慢的。而我們接下來要說的基于以太網的SOA，相對來說就更為靈活。SOA雖然常被用于和CAN進行對比，但其實已經不是一種通信手段

以太網通信

智能汽車以太網通信的協議棧相比CAN更為復雜，當然其覆蓋的業務面也更寬，靈活性也更高，是目前域控制器之間通信的主流方案。如下圖所示：

當前，智能汽車的以太網通信有兩條發展路線。

一條路線就是時間敏感網絡（Time Sensitive Networking，TSN），這是從鏈路層往上的一次全面改進，是未來具有較大潛力的一種以太網通信協議，但目前的應用仍在探索當中。當前被采用更多的是另一條技術路線，即對常規以太網技術的改進，主要調整底層和應用層的設計，但保留了絕大部分網絡層及傳輸層的設計，可以和傳統互聯網無縫銜接。

以太網之上的SOA

了解完以太網通信的基本構成，緊接著我們就可以來討論SOA，即面向服務的架構（Service-Oriented Architecture）。SOA實際上并不是一種具體的技術，而是一種架構策略層面上的指導思想或者范式，是為了更好地組織和利用處于不同所有權范圍控制下信息的一種分布式設計。

SOA不是一種單純的通信機制，雖然看上去與CAN這類基于信號的通信類似。但仔細比對，會發現兩者有著本質上的區別。如下圖所示：

面向服務的通信定義了“服務方”和“消費方”，“服務方”是傳統意義上的發送者，而“消費方”是一種接受者。

在整車應用當中，我們可以通過AutoSAR AP或者自主研發的生成工具，完成類似CAN的通信矩陣生成，滿足各個域控制器之間的通信需求。與CAN相比，較為明顯的區別除了通信載體不同外，SOA還具有以太網SOME/IP所支持的服務發現功能，可以動態建立域控制器之間的傳輸鏈路，從而實現動態拓撲的構建，由此提升軟件更新過程中的靈活性。

不同于固定的信息傳輸，消費方可以利用“服務發現”，訂閱某幾個服務方準備好的信息輸出服務。應用程序之間是一種松耦合的連接，消費方的需求發生變化，服務方往往不需要作出變化。但這往往只達到了面向服務通信（Service-Oriented Communication，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再到深度學習，智能汽車的演進過程中，通信和計算的概念會進一步模糊化，機器更多地需要從”信息傳遞“，向”溝通交流“轉移。