CAN總線時間同步協議測試的研究與分析

李志濤，耿偉峰

（長城汽車股份有限公司技術中心，河北 保定 071000）

CAN（Controller Area Network）總線作為一種可靠的汽車計算機網絡總線，已經在汽車上應用多年[1]。CAN總線因其實時性好、抗干擾能力強、可靠性高等優點成為當今最成功的車載總線之一，被廣泛應用在車載通信中。隨著汽車電子技術與車輛智能化的發展，對汽車上電器控制單元（ECU）的通信實時性要求日趨嚴格，特別是在某些高速或安全駕駛場景下，微小時間的偏差可能導致災難性的后果。各個控制單元間要有一個一致的時鐘來提供相對準確、精度足夠的絕對時間值，并且將此時間同步到各個ECU，實現高精度和高可靠的時鐘同步，來滿足車輛功能實時性需求。因此，一種基于CAN總線的時間同步技術應運而生。

1 CAN總線時間同步概述

時間同步是分布式系統的核心技術之一，其目的是維護一個全局一致的物理或邏輯時鐘，以使系統中的節點基于一個全局一致的時間進行信息交互。時間同步技術在以太網、CAN、Flexray總線上都有相應的實現，用于各節點精確獲取采樣時間。CAN系統時間同步可分為兩類，物理層時鐘同步和應用層時鐘同步。物理層時鐘同步包含硬同步和重同步兩種同步方式，節點根據總線上檢測到的信號沿與自身位定時相比較，通過硬同步或重同步適當調整位定時，保證數據幀的正確收發；應用層時鐘同步通過軟件、硬件或者軟硬件相結合調整各個節點時鐘，使得各節點擁有一個全局一致的邏輯時鐘，實現CAN網絡各節點協同工作以及節點間消息的實時調度。只有物理層硬同步和重同步準確無誤，應用層時鐘同步才能被正確執行。

AUTOSAR標準[2]規定了CAN總線時鐘同步機制與相關需求。在CAN總線網絡中，ECU分為時間網關節點（TG）、主時鐘節點（TM）與從時鐘節點（TS），映射到網絡中的真實ECU時，網絡中的一個ECU可以是主時鐘節點，甚至是全局主時鐘節點，而對于網絡中的其它ECU需為從時鐘節點，網絡中的相關ECU在總線網絡中或子網中，組建成時間域和相應的時間子域，見圖1。

圖1 時間域示例

主時鐘節點是一個實體，它是某一時間基的參考源，并將該時間基傳播到網絡中的從時鐘節點，作為從時鐘節點的時間基源。如果主時鐘節點也是全局時間基的所有者，網絡中其它節點的時間基都從該節點派生，那么該主時鐘節點為全局時間主時鐘節點。通常車載網關節點作為全局時基的所有者，由一個時間主端口組成，該端口連接到一個或多個時鐘從端口，從而構建成一個或多個時間子域。

CAN總線時間同步，采用主時鐘節點發送特定的同步報文，從時鐘節點作為同步報文接收節點，對本地時鐘進行調節，以獲得更加精準的時間信息，從而實現與主時鐘節點的同步，以解決因各ECU節點的硬件時鐘信號偏差、CAN總線傳輸延時（如協議仲裁）以及各ECU節點內的軟件處理等原因導致的時間延遲。

2 CAN時間同步機制

基于CAN總線的時間同步機制，主時鐘節點（TM）以廣播的形式將時間信息傳輸到各從時鐘節點（TS），還可通過時間網關（TW）將時間同步到其它子網，同步通信機制主要分為兩步。第1步，主時鐘節點（TM）發送SYNC報文；第2步，主時鐘節點（TM）發送FUP報文。CAN時間同步機制，見圖2。

圖2 CAN時間同步機制

TM節點在t0r時刻開始發送SYNC報文，t1r時刻發出SYNC報文，SYNC報文中攜帶的時間為SYNC開始發送的時刻t0r，并且為秒時間s（t0r）；TS節點接收SYNC報文，并通過接收確認機制獲取完成SYNC報文接收的時間戳（t2r）；TM節點在發送完SYNC報文后，再次發送FUP報文，該報文中攜帶時間信息t4r，t4r為上一個SYNC報文開始發送與實際確認發送完成之間的時間。TS節點在接收到FUP報文后，根據接收SYNC報文后獲取的t2r時間信息，計算t3r時刻的本地的時間同步值，即本地的相對時間為t3r-t2r+s（t0r）+t4r=t3rt2r+t1r。主時鐘節點分配同步時基，從時鐘節點接收同步時基，實現網絡從時鐘節點與主時鐘節點之間的時間同步。

在AUTOSAR軟件協議棧中[3]，實現CAN時間同步，需配置的模塊主要涉及3個，分別為StbM、CanIf、CanTSyn。其中StbM用于同步各軟件模塊，獲取和設置當前時間值，提供絕對時間值，涉及到Timebase、時鐘源等配置信息；對于CanTSyn模塊而言，需配置Time Domain與參考時鐘源；在CanIf模塊中，用于接收和發送報文，需要將報文設置為時間同步報文等。

2.1 主時鐘節點時間同步步驟

1）SYNC報文發送。通過StbM_GetCurrentTime（）獲取同步基準時間t0，并將t0秒時間部分寫入SYNC報文中的SyncTimeSec；通過StbM_GetCurrentTimeRaw（）獲取傳輸延遲時間測量的原始時間t0r。

2）SYNC報文TX確認。計算FUP報文中的t4為t4r=[t1r-s（t0r）]，其中t0r ns為t0的納秒部分。

3）FUP報文的發送。將t4（t4＞=1s）的時間的秒部分寫入OVS；將t4的納秒部分寫入SyncTimeNSec。

經過以上這些步驟，計算出TM節點的同步時基為（s（t0r）+t4r）。

2.2 從時鐘節點時間同步步驟

1）通過SYNC報文接收確認機制，SYNC報文傳遞同步時基的t0部分，并通過StbM_GetCurrentTimeRaw（）獲取本地時間戳，定義為t2r。

2）通過FUP報文接收，FUP報文傳遞同步時基的t4部分（t4=OVS+SyncTimeNSec），并通過StbM_GetCurrentTimeDiff（）獲取函數調用期間內部時間戳t3r和之前接收到t2r的時間戳之間的時間差，即t3diff=（t3r-t2r）。

經過以上步驟，TS節點計算全局時基來更新本地時基為：GlobalTimeBase=（t3r-t2r）+s（t0r）+t4r=t3r-t2r+t1r

通過以上TM與TS節點的時間同步步驟，各個TS節點基于一個一致的主時鐘節點（TM節點），來提供絕對時間值，并且將此時間同步到時間域內的各個網絡節點。

3 時間同步幀解析

CAN時間同步所應用的同步幀，包含SYNC報文幀和FUP報文幀。SYNC報文和FUP報文共用一個CAN ID，分時發送，先發送SYNC報文，再發送FUP報文。同步報文幀中的CRC校驗是可配置的，可配置使用TM節點發送的Time Base值，無需應用CRC校驗，同步報文幀格式見圖3。

圖3 SYNC/FUP報文幀

3.1 SYNC報文幀

SYNC報文幀的Byte0表示是否應用CRC校驗，其中Byte0=0x10表示未應用，Byte0=0x20表示應用；若Byte0=0x20，Byte1用于存儲CRC的值，Byte0=0x10時，Byte1的默認值為0；Byte2的高四位表示時間同步域，低四位為Sequence Counter，該序列計數器用于檢測錯誤的協議序列和數據；Byte3為用戶自定義數據，默認值為0；Byte4-Byte7為同步時間，長度為32bits，單位為秒。

3.2 FUP報文幀

FUP報文幀的Byte0表示是否應用CRC校驗，其中Byte0=0x18表示未應用，Byte0=0x28表示應用；若Byte0=0x28，Byte1用于存儲CRC的值，Byte0=0x18時，Byte1的默認值為0；同樣Byte2的高四位表示時間同步域，低四位為Sequence Counter，該序列計數器用于檢測錯誤的協議序列和數據；Byte3的高5位為保留位，默認值為0，Byte3字節的bit2位為SGW位，用于表示時間同步狀態，其中數值0表示為Sync－ToGTM，數值1表示為SyncToSubDomain，Byte3字節的bit1與bit0位為OVS（Overflow of seconds）位，表示時間同步溢出時間；Byte4-Byte7字節中的高2位為數值0，低30位表示同步時間，單位為納秒。

4 時間同步協議測試

在汽車電子電氣領域，典型的V模型在OEM電子電器產品開發中廣泛應用，該模型從左到右，描述了電子電器產品基本的開發過程和測試行為[4]。參照V模型，總線時間同步協議測試可分為ECU級測試、集成級測試。ECU級測試，用于ECU協議一致性測試，集成級測試包含系統臺架與實車環境下的測試，用于總線系統時間同步協議正確性及應用穩定性的驗證。

4.1 測試內容

基于Vector測試工具鏈，通過CANoe軟、硬件開發測試系統，集成相應的硬件工具，完成測試環境的搭建。依據被測系統的總線拓撲及時間同步域，測試工具連接至相應的時間域鏈路中，分別監測TG節點與TM節點，TM節點與各TS節點之間的通信數據，實現整個時間域與子時間域數據的采集、測試等。測試環境連接示意圖，見圖4。

總線集成測試，對時間同步系統基本需求實現的正確性、準確性、合理性進行測試，并結合不同的車輛運行場景，對系統在不同場景下的運行狀態進行檢測，結合用戶典型應用場景，進行誤用和濫用方面的測試，同時考慮主機廠自定義及一些特殊需求，開展相應測試。主要涉及的測試內容為時間同步序列的測試、同步報文格式的測試、時間同步算法測試、魯棒性測試、故障注入、車輛電源模式切換、發動機啟動、用戶功能應用觸發場景下的測試等。

時間同步協議測試，不僅需開展ECU級協議一致性的測試、系統層級協議需求實現的正確性測試，更需基于整個時間域網絡、功能應用、車輛場景等維度，評估系統的性能指標的符合性、驗證時間域系統通信的穩定性和可靠性。

4.2 測試示例

本示例為同步報文發送序列及數據正確性的測試，驗證CAN總線時間同步系統中TM節點所發送的SYNC/FUP報文的序列、周期、間隔、數據字段等是否滿足設計需求。測試前，參照圖4搭建測試環境，連接測試設備。

圖4 測試環境連接示意圖

運行CANoe工具，開始進行數據采集。系統上電，CAN總線系統被激活。系統中的TM節點開始發送同步報文，分別為SYNC報文與FUP報文，見圖5。

圖5 總線同步報文

查看并分析所采集的數據，SYNC報文和FUP報文共用一個CAN ID，分時發送，先發送SYNC報文，間隔50ms再發送FUP報文，然后再進行下一次同步過程。SYNC報文中的Payload Type=0x10、Payload SGW=0、Payload SC=6、Payload CRC=0；FUP報文中的Payload Type=0x18、Payload SGW=0、Payload SC=6、Payload CRC=0。經分析同步報文發送序列、周期、時間間隔、Payload字段數值符合設計需求。同樣按以上測試步驟及要求，進行各子時間域同步報文發送序列、周期、數據字段格式正確性的驗證。

5 結束語

隨著汽車智能化發展、汽車功能的增加，汽車上的電子控制單元也越來越多[5]，ECU數量的爆發式增長，對車載通信的速率、實時性、可靠性等方面提出了更高的要求，尤其是對于自動駕駛的感知和決策輸入而言，通常需要攝像頭、毫米波雷達、超聲波雷達、激光雷達等傳感器具備精確的數據采集能力，防止車輛決策規劃出錯誤的動作。因此，總線時間同步技術應用的必要性至關重要，本文對CAN總線時間同步機制與測試進行了研究分析，為進一步深入開展相關測試工作奠定了基礎。