外部授時的應用背景

智能網聯汽車需要與車外系統進行信息交互。

車外系統的交互包括諸如車端向TSP的事件上報、信號上報；遠控事件，車端與云端、手機端之間的信息交互；安全證書的有效期認證；藍牙鑰匙的使用期間授權；V2V之間交互；V2I之間交互等等。

廣義上，車內HMI大屏顯示的時間也算是車端與外部乘員系統的信息交互。

在進行信息交互時，車端的時鐘系統與需要與車外的時鐘系統對齊基準時間，也即遵循相同的時鐘體系，以便在時間維度定位事件。

外部授時的場景

在某些初始場景，如整車斷KL30電后上電，或整車深休眠->喚醒，車內的基準時鐘會紊亂，維護為一個錯誤的起始時間。比如常見的1970/1/1 000。

這個時候就需要由外界的時間源給車端的時鐘進行授時。

外部時鐘源

車端通常使用的外界授時時鐘源包括：GNSS原子時、NTP時間、TSP時間、NITZ時間。

GPS原子時是通過GPS衛星播發的原子時，通常視為最高精度時間源，具有最高的授時優先級；車端需要具備GPS接收機，通過GPS接收機接收到GPS信號以解算出該原子時。

NTP時間是由NTP服務端提供的網絡時間；精度次于GPS原子時間，且其時鐘穩定性依賴于所使用的NTP服務器的穩定性。車端需要能夠通過蜂窩網絡訪問NTP服務器以獲取到NTP時間；

NITZ為基站所提供的時間；精度次于NTP時間。車端需要具備蜂窩通信模組與基站進行空口交互以獲取該時間；

TSP時間為車企自行維護平臺的時間，其時間源多為NTP時間，所以本質是NTP時間。

除外部授時源外，車端自身通常使用RTC芯片在淺休眠->喚醒時用于恢復時間。

舉個例子說明外部授時

車端的外部授時，可以類比這樣的場景。

一個人喝斷片了，然后被關在小黑屋里睡覺。小黑屋里沒有鐘表。

這個人睡醒后，不知道今夕是何年何月何日 幾時幾分幾秒。

他怎么才能知道現在的真實時間呢？

他可以選擇拿起座機電話（是的屋子里有個座機電話，視為接受外部授時的通道）給一個他信得過的人打電話，實時獲知當下的時間。

于是就完成了來自外部的授時。

時間維持

這個人得知了真實時間，他可以選擇一直不掛斷電話，一直問詢電話對端當下的真實時間，以便于維持小黑屋里的時鐘系統。

他還有另外一種選擇，就是自己維持時間的遞增。

比如，這個人找到了個有電的秒表（是的屋子里有個秒表，作為維持時相對時間的工具），于是他記下當下的時間后，然后開始啟動該秒表。

這個時候他就可以掛斷電話了，因為如果想知道當下的時間，只要用 他記錄的那個時間 + 秒表顯示已經走的秒數，即可計算得到當下的時刻。

車內域間時間同步

車內系統與車外系統需要對齊時間。車內各域控之間也需要對齊時間。

車內各域控制器獨立分布，域控之間通過以太網、CANFD等實體總線進行聯結和通信。各域控都有自己的一個時鐘，且在上電運行時，都有精準維持自己時鐘的能力，用于域內交互時對信號事件等標注上相應的時間戳。

可以想象下各個域控系統都有自己的一塊手表，每塊表都是相對比較精確地逐秒累加時間；但在同一時刻，各個系統的手表報的是不同的時間值。

在對每個信號事件標注時間戳的時候，同一時刻的時間戳是凌亂的，這樣跨域間對時間敏感的業務無法正常運行，無法通過多域各自打印的日志分析排查問題。

所以車內每個域控都需要對齊時鐘，也即統一時間基準。

由于獲取外部時間需要諸如蜂窩通訊、GPS信號接收能力等，所以不是每個域控都會與外界授時源交互獲取授時。

車端通常會選取一個主時鐘，用于與外界時鐘系統進行時間的對齊，也即外部授時。再由被外部可靠時鐘源授時后的主時鐘對域內各控制器進行車內的時間同步。

舉個例子，說明車內域間時間同步

還是被關小黑屋的那個人A。

他發現屋里還有另一部電話。拿起來撥打后對方接了起來。原來是他另一個一起喝斷片的朋友B，現在被關在了另一個小黑屋里。

這個B的小黑屋里沒有外線電話，只有3部內線電話，一部是通朋友A，另外2部分別通另外兩個一起吃飯喝斷片的朋友C和D。

C和D分別只有一部內線電話，拿起來只能和B通話。結構如下這種：

注：一起喝斷片的ABCD

“

外面的世界，即外部UTC時間系統

小黑屋們，即失去了正確時間基準的車內時間系統

外線電話，即可獲得外部授時的能力通道

內線電話，即車內域間時間同步的能力通道

A房間，有外線+內線電話，即車內的主時鐘

B房間，可以與多個房間進行通話，不同房間之間無法直接通話，即B房間為域內的網關域控

C房間和D房間，分別對應 車內的非主時鐘、非網關的域控

”

A通過和B的內線電話告訴了B當前的時刻，B知道后，拿起和C、D兩人小黑屋連線的內線電話，告知C、D當前的時間。

經過這番操作，ABCD四人完成了粗糙的時間同步。（之所以粗糙是因為未消除傳輸延時）。

車內域間時間同步故障來源

由上圖可知，末端域控節點獲取同步時間的鏈路存在多個環節。某時間同步系統的下游節點出現錯誤時間（域控時間與UTC時間存在偏差），可能的原因很多，并非完全是主時鐘時間源錯誤所致。

比如可能的原因有：

主時鐘時間源錯誤

系統功能設計失效

硬件異常故障

軟件基礎庫異常故障

授時時間源時間異常

車輛出現過異常工況 （如斷kl30） && 無蜂窩網絡無法獲得ntp時間 && 封閉空間無法獲得GNSS授時（此看似極端場景在研發階段經常出現）

報文播發異常

網關轉發異常

主時鐘節點-網關節點物理鏈路/協議鏈路異常

網關轉發報文異常

網關處理時間報文邏輯異常

下游節點接收異常

網關節點-下游節點物理鏈路/協議鏈路異常

下游節點接收報文異常

下游節點處理時間報文邏輯異常

下游節點應用層獲取時間報文鏈路異常

下游節點應用層展示時間處理邏輯異常

作為主時鐘的功能owner，比較頭疼的是但凡下游節點出現時間顯示異常的現象，就被按頭分析。有些時候是主時鐘問題，有些是下游邏輯或鏈路問題，有些時候是使用場景問題。

斷電斷網在地庫，喊破喉嚨也沒有人來授時。

這也是我寫這篇文章的初衷，希望更多的汽車工程師了解時間同步的大致邏輯，以便更好地識別問題。

車內時間同步的環節

在智能網聯汽車上，時間同步這個業務包括如下環節：

1. 整體

a. 外部不同時間源授時：授時能力、優先級仲裁

b. 域間時間同步：同步通道CAN、gPtp等

c. 不同業務對不同時間源的選取及使用邏輯

2. 主時鐘

a. 接受多源授時能力

b. 多源使用邏輯

c. 多板板間的時間同步

d. 板上的時間維持

e. 特殊電源模式下時間恢復機制

f. CAN、gPtp報文播發

下面選取一些主要環節進行說明。

整車層面，不同業務對不同時間源的選用邏輯

通常的設計方案，整車各域控使用相同的時間源。也即，各域控上的各個業務使用相同的時間基準，共源。

該共源時間源的最高優先級通常指定的是 最高精度的GPS原子時間。只要滿足GPS時間獲取的條件，就更新時間源為GPS時間。

也有部分OEM根據實際業務需要，選擇TSP的時間作為時鐘源。

選用TSP的時間是由于車端大部分與外部系統進行交互的時間敏感業務多需車端與TSP的時間對齊，如遠控、車輛使用授權等。

TSP使用的時間源為NTP時間，精度不如GPS原子時間，但足以支撐業務。對于NTP服務器極小概率偶發崩潰等情況的應對，踐行的是“要錯一起錯”的準則。

選用不同時間源的根本目的，是為了實現不同業務 向不同對端時間系統的對齊。

有的業務更傾向于對齊TSP時間，有的業務更傾向對齊GPS時間。所以可以考慮多源授時，多源同步的方案。

不同時間源切換所帶來的時間跳變

不同時間源進行切換可能會帶來毫秒級乃至秒級的跳變。對于從特殊工況中完成首次被授時的時間恢復，可能出現非常大幅度的跳變。

跳變可能向已經發生過的時間跳變，也可能向尚未發生的時間跳變。

回跳是個比較令人頭疼的場景。會導致產生數據順序上報、記錄類的業務出現相同時間戳的不同日志；對于一些有嚴格時序要求的業務，會造成功能失效的情況。

所以在設計功能邏輯時，對于時序有嚴格要求的業務需要使用單調時鐘（系統滴答）以保證時間不會會跳，避免使用墻上時鐘以免出現回跳導致的失效。

gPTP機制

下面大致介紹下基于gPTP（IEEE802.1AS）總線的同步機制。

gPTP是一種基于以太網總線的標準的時間同步機制。運行在MAC層，距離物理層近可以減少運行在上層所引起的延時及不確定性，減少傳輸時延。gptp可以實現各域節點之間ns級別的時間同步。

在gPTP域內，需要指定一個gptp節點作為主時鐘（Master），其他gptp節點作為從時鐘（Slave）。主時鐘通過播發gptp報文的方式實現對其他從時鐘節點的時間同步。

提到gPTP就少不了提到PTP。gPTP是基于PTP協議的衍生強化版，兩種協議適用不同的硬件環境及用途。

PTP與gptp協議的區別。

面向工程人員的區別主要體現在報文發送內容、報文發送順序存在區別，gptp比ptp多了delay_resp_follow_up的報文，抓包需要參考不同協議進行分析理解。

原理上的區別是gPTP增加測量了主從端口的時鐘頻率的偏差，即增加了時鐘頻率換算系數的計算，而PTP的報文交互未見此環節。

PTP與gPTP的區別詳見：https://blog.csdn.net/weixin_43408952/article/details/125082433。

gPTP協議的報文流程交互相比于PTP更為復雜，報文的交互邏輯，具體可查看張大俠專欄：https://zhuanlan.zhihu.com/p/101003490。寫的很清楚。

PTP 的鐘差以及時延測量邏輯

此處以PTP協議報文的發送內容來理解主從之間clockoffset和pathdelay的測量方法。

PTP時間同步有兩個前提。一是主從分別有自己維護的時鐘系統，且可準確實現相同時間步長的時鐘自增；二是從時鐘聰明地知道傳輸過程有時延，且默認雙向時延相同。

報文發送流程圖示意如下：

具體的交互邏輯及意圖描述如下：

1.起始，主從時鐘各自維護自己的時間基準；

2. t1時刻主時鐘向從時鐘播發sync報文，通知進行同步；從時鐘在t2時刻接收到該sync報文指令；

3. 主時鐘隨后播發follow_up報文，報文payload中攜帶上一條sync播發對應的主時鐘時刻；

4. 基于前述步驟，從時鐘可知，在自己接收到sync報文的時刻所對應的主時鐘的時刻；僅通過這兩個時刻無法獲知主從時鐘之間的時鐘差（clockoffset），因為該時間差包含了主->從的傳輸延遲（pathdelay）。

因此下一步即從時鐘需要探測pathdelay是多少。

5. 在一定時長后（這里舉例5 min，實際為ms級），在t3時刻，從時鐘向主時鐘發送探測pathdelay的delay_req請求；

6. 主時鐘在 t4 時刻接收到從時鐘發送的delay_req請求，然后發送響應報文delay_resp。該報文的payload攜帶了t4這個時刻；

7. 通過上述兩步驟，t3 和 t4 這兩個時間差包含了 主從之間的時鐘差及從->主的傳輸延遲 pathdelay；

8. 此處默認 主->從 和 從->主 的鏈路傳輸延遲是相同的。

9. 從時鐘基于上述的t1-4數據，可計算得到與主時鐘之間的clockoffset 以及 主從之間的傳輸延遲pathdelay。

clockoffset用于從時鐘的系統時鐘校準，pathdelay用于以太網switch轉發數據包時的時間差補足。

PTP機制的擬人化理解

接下來介紹下作為主時鐘域控實現域內板間時間同步。

板間同步的必要性

主時鐘需要具備多種對外播發時間同步數據的通道。介質多為CAN 和以太網，報文分別為CAN報文和GPTP報文。

CAN總線時間同步采用 Autosar的TimeSync協議機制。以太網總線時間同步采用GPTP協議機制。

CAN總線和以太網總線兩條時間同步通道并行，一是互為災備冗余，二是面向不同總線節點。

但不論通過哪條總線對外播發時間同步的消息，主時鐘播發的CAN報文和gptp報文上的payload時間數據體都應該是相同的。

CAN報文播發和gptp報文播發功能通常分別由MCU和MPU承接。MCU和MPU之間需要實現有效的時間同步，以保證通過不同通道播發的時間數據是一致的。

板間同步的困難點

在異常場景時間恢復時，由于MCU的快速啟動及低功耗等特性，多使用MCU上掛接的RTC用于MCU系統的時間恢復。

MPU側多用于承接外部授時源的授時。但在初始場景，MPU側通常是需要從MCU側快速獲取時間，并基于當前場景形成判斷邏輯確認進入哪一種授時源的授時，以避免多次低優先級的授時源授時而引起多次跳變。

MPU完成外部授時后，需要對MCU側再進行時間校準以消除MCU RTC恢復MCU系統時間所引起的與MPU系統時間之間的誤差。

MCU與MPU之間的時間同步存在系統延遲誤差。該誤差可能固定可測量出具體數值用于標定補償，也可能隨機不可測不可標定。

實車的使用工況還包含KL30斷電冷啟MCU RTC時間丟失、地庫內無GNSS信號無法獲取GPS時間、無蜂窩網絡無法獲取NTP授時等各種場景，還需要考慮讀取RTC失敗等偶發電器故障等。

所以主時鐘域內的板上及板間 時間恢復、時間同步與反向同步、時間有效性判斷、時間維持、外部授時源缺失、休眠期間時間維持、休眠時間寫入等，都是需要考慮和設計。

一句話總結即是 MCU和MPU之間的時間同步邏輯非常復雜。是我迄今經手過的燒腦排行前幾的系統功能方案。

編輯：黃飛