這次我們的介紹主題是LIN休眠喚醒，一起看看標準和差異性，開發和測試的關系，實際的案例分享也來了。

01、LIN控制器休眠喚醒類型介紹

雖然新架構的發展促進著通信技術的升級換代，但作為車載通信技術的常青樹之一的LIN通信，由于其自身的特點，將會繼續發光發熱。其中LIN的休眠喚醒作為整車休眠喚醒的重要組成部分，需引起開發和測試工程師足夠的重視。本文將介紹此方面的內容，LIN總線是主從結構，下面將從LIN主/從節點分別展開。

主節點休眠喚醒

主節點的喚醒條件在LIN協議2.1規范中定義的是被喚醒信號喚醒，但是實際應用OEM多是依據自己的需求進行開發的。

常見的幾種喚醒方式如下：

1．硬線喚醒（硬線喚醒源實質就是定義喚醒線的電平變化，如傳統車的KL15上電）

2．網絡喚醒（網絡喚醒即是網絡管理報文喚醒，此處網絡管理報文指的是LIN的上層網絡總線（CAN/FlexRay），LIN本身不存在網絡管理報文，上層網絡喚醒伴隨LIN網絡喚醒）

3．特定信號喚醒（例：車輛使用模式信號為特定值時LIN網絡才能喚醒）

規范描述在主節點不發送幀頭時，從節點應發送喚醒信號來喚醒主節點。這種喚醒必須滿足兩個條件：

1．從節點必須支持發送喚醒信號

2．主節點能夠被喚醒信號喚醒

但是實際測試中發現，從節點一般不支持發送喚醒信號喚醒（實車測試遇到過網絡喚醒休眠異常情況，排查發現為從節點陽光雨量控制器不斷發送喚醒信號導致的，即取消了該控制器能發送喚醒信號的功能）。

隨著局部網絡喚醒的應用，主節點喚醒方式大多為網絡喚醒，LIN網絡做成與上層網絡同睡同醒的機制。 主節點休眠的最終表現形式都是發送睡眠指令，當然休眠與喚醒本就是強關聯，且主節點的喚醒休眠條件多是依據OEM自身需求而定，我們就不進行展開了。

從節點休眠喚醒

從節點的喚醒條件同樣為接收到喚醒信號，LIN協議2.1規范中描述從節點喚醒條件可能為接收到主節點發送同步間隔場，這是LIN通信機制的緣故，從節點進行通信必須接收到主節點發送的幀頭才能發送從節點響應部分，而幀頭可以充當喚醒信號，從節點在接收到喚醒信號完成初始化后即可正常通信。

規范描述從節點的兩種休眠條件如下：

1．接收到睡眠指令

2．總線空閑4-10S

正是由于從節點需求的通用性，我們才能總結出各零部件供應商的實現差異點，沉淀測試經驗來優化我們的測試。其中從節點最典型的測試就是休眠喚醒遍歷測試，下文將對此進行詳細展開。

02、休眠喚醒測試案例分享

案例1：連續仿真發送從節點響應的某幀幀頭時，樣件會不斷重復休眠喚醒的過程。

造成該現象的根本原因是該零部件供應商除了上述兩種休眠條件外還增加了另外一個休眠條件：檢測主節點丟失（即接收到主節點的發送報文）；我們測試休眠喚醒為了避免其它幀頭對測試造成影響，所以選擇該從節點響應的某一幀進行休眠喚醒測試，這就造成了主節點丟失的條件，從節點會進入休眠；休眠之后又會被周期仿真的幀頭喚醒，所以就出現重復休眠喚醒的現象。

檢測到主節點丟失休眠條件在各節點工作正常是不會產生任何影響，但可以在LIN總線短地的條件下使樣件進入休眠，防止由于LIN線短地造成樣件無法休眠導致整車饋電，此是在滿足標準基礎上的設計優化。當然，具體的問題要依據具體設計而定，有可能總線空閑的判斷邏輯覆蓋了低電平時情況，未檢測到電平變化就識別為總線空閑，這樣就無需增加休眠條件了。

案例2：樣件在接收到睡眠指令后偶發性不能進入休眠。

測試用例我們一般遍歷測試接收到睡眠指令后等待300-1100ms樣件是否都能正常進入休眠；

造成該問題的根本原因是樣件在接收到睡眠指令后有一個預休眠處理，時間為500ms（功能設計于數據保存），在預休眠期間樣件不會識別任何幀頭；所以只要是遍歷等待時間小于500ms，依據自動腳本等待時間代碼的時間疊加，就造成樣件偶發不能進入休眠的現象。

由于特殊樣件有特定的需求，這種情況我們就會優化我們的測試方法。同時在此基礎上可以延伸出等待總線空閑臨界點的休眠喚醒測試的新場景。

總而言之，測試設計以具體需求設計為基礎，用以高效發現問題，以及評估設計合理性，這是一個消化吸收、總結沉淀、擴展延伸的過程，需要對設計需求有深入的理解，需要關注和了解具體的實現方法，需要在測試過程中實踐和分析。

03、小結

通過上述的介紹，相信大家對LIN喚醒休眠有了一定的了解。由于LIN主節點多是OEM根據自己的需求進行開發，就沒有對主節點的喚醒休眠測試進行展開；如果大家想了解常見的喚醒方式（同睡同醒），可參照AUTOSAR網絡管理部分的分享內容。

審核編輯：郭婷