LIN 匯流排協定簡介

Local Interconnect Network (LIN) 匯流排與 Controller Area Network (CAN) 匯流排為汽車與工業系統常用的通訊協定。 雖然 LIN 與 CAN 的用途相似,但兩者之間的架構與功能卻有明顯差異。 

LIN (Local Interconnect Network) 匯流排是針對汽車網路所建立的標準,藉以達到低價位的初階多工通訊。雖然 CAN 可建構高頻寬的高階網路,但對電動車窗與座椅控制器的應用來說,實在不需要用到 CAN 軟硬體的高建置成本。針對不需要 CAN 頻寬與多功能的非關鍵用途,LIN 即可達到高成本效益的通訊作業。若使用標準序列的通用非同步收發傳輸器 (Universal asynchronous receiver/transmitter,UART),即可透過相對較低廉的價格,將 LIN 嵌入至最新的低價位 8 位元微控制器中。

現代汽車網路結合 LIN 用於低成本應用,主要用於車身電子、 CAN 用於主流動力總成與車身通訊,以及新興的 FlexRay 匯流排,可在主動式暫停等進階系統中進行高速同步資料通訊。 

LIN 匯流排透過 Master/Slave 的方式，以 1 組 LIN Master 搭配 1 組以上的 LIN Slave。

 
^{圖 1:LIN 訊息框架}

訊息表頭包含 1 組斷點 (Break)，可識別框架的起點與次要節點所使用的同步化欄位，以進行時脈同步化作業。識別元 (Identifier,ID) 則包含 6 位元的訊息 ID 與 2 位元的奇偶欄位 (Parity field)。ID 將代表特定訊行的位址 (Address)，而非目的地 (Destination)。根據 ID 的接收與解譯情況,將有 1 組 Slave 開始回應訊息,其中將包含 1 組 8 位元組的資料,與 1 組 8 位元的總和檢查碼 (Checksum)。 

而 Master 將控制訊息框架的排序，使其固定為完整排程。您可依需要變更排程。 

LIN 標準亦有多個版本。Version 1.3 版本為 Byte-Layer 的通訊作業。版本 2.0 與 2.1 則新增了更多訊息發送規格與服務,且完全相容於 LIN 1.3 的 Byte-layer。 

¹ API 本身並未支援此功能，但是仍可建置該項功能。 

^{表 1：表 1. LIN 的 1.3、2.0、與 2.1 版本的比較}

LIN 匯流排為輪詢 (Polled) 匯流排，以 1 組主要裝置搭配 1 組以上的附屬裝置。主裝置包含 1 筆主作業與 1 筆附屬作業。而各組附屬裝置均僅具有 1 筆附屬作業。以 LIN 匯流排所進行的通訊作業，完全由主要裝置中的主作業所控制。由 LIN 匯流排所傳輸的基本單位即為框架 (Frame)，並可將之區分為表頭 (Header) 與反應 (Response)。標頭一律由主節點傳輸,並由三個不同的欄位構成:中斷、同步 (同步) 與識別元件 (ID)。而反應則由附屬作業進行傳輸,且可附加於主要節點或附加節點旁,包含 1 組資料酬載 (Payload) 與 1 組總和檢查碼。 

在正常情況下，主作業將傳輸表頭，以於迴路中輪詢各個附屬作業 (依序為 Break-Sync-ID)。在開始 LIN 之前,每項附屬作業都會設定為將資料發佈至匯流排,或是針對接收的每個表頭 ID 訂閱資料。收到標頭後,每個附屬作業都會檢驗 ID 偶合性,接著檢查 ID,以判斷是否需要發佈或訂閱。若附屬作業必須發佈反應，則將傳輸 1 ~ 8 個資料位元組至匯流排，最後並附有 1 個總和檢查碼位元組。若附屬作業必須簽署,則將從匯流排讀取資料酬載與總和檢查碼位元組,再進行合適的內部動作。 

標準的 Slave-to-master 通訊作業，即是讓 Master 將識別元廣播至網路，且僅有 1 個 Slave 會反應資料酬載。

Master-to-slave 通訊作業，則是透過主要節點中的 1 個獨立附屬作業完成。若為獨立的 Slave 節點，則此作業本身即可接收已發佈至匯流排的所有資料。若要傳輸資料位元組，則 Master 必須先透過所要傳輸的資料值，以更新內部附屬作業的反應。接著 Master 將發佈合適的框架表頭，內部附屬作業會將資料酬載傳輸至匯流排。

^{圖 2：LIN 訊息框架}

1.Break

所有 LIN 框架均以斷點 (Break) 開始，內含 13 個強勢位元 (Dominant bit)，最後以 1 個弱勢位元 (Recessive bit) 的斷點分隔符 (Delimiter) 做為結尾。如此一來，匯流排上的所有節點均可了解此為開始框架 (Start-of-frame)。

2.Sync

Sync 欄位為主作業於表頭中所傳輸的第二個欄位。Sync 定義為字元 (Character) x55。針對自動偵測鮑率的附屬裝置，Sync 欄位可使其量測鮑率期間並調整內部鮑率，以進行匯流排的同步化。

3.ID

ID 欄位為主作業於表頭中所傳輸的最後欄位。此欄位代表網路中的所有訊息的識別碼，且最後可決定網路中的哪個節點應接收或反應各個傳輸作業。所有附屬作業將持續接收 ID 欄位、檢驗其奇偶屬向，並依此特別的識別元決定本身為發佈者 (Publisher) 或簽署者 (Subscriber)。LIN 匯流排可提供 64 組 ID。第 0 ~ 59 組 ID 適用於承載訊號 (資料) 的框架；第 60 與 61 組 ID 將承載診斷資料；第 62 組 ID 保留以用於使用者定義的延伸 (Extension)；第 63 組 ID 則保留用於可能的協定強化 (Enhancement)。ID 是以單一受保護的 ID 位元組型態，透過匯流排進行傳輸；較低 (Lower) 的 6 個位元包含原始 ID，較高 (Upper) 的 2 個位元則包含奇偶 (Parity)。

^{表 2：奇偶 (Parity) 計算方法}

4.資料位元組

資料位元組欄位，是透過反應 (Response) 中的附屬作業所傳輸。此欄位包含酬載資料位元組的 1 ~ 8 個位元組。 

5.總和檢查碼

總和檢查碼欄位，是透過反應中的附屬作業所傳輸。LIN 匯流排將定義 2 組總和檢查碼運算式之一的使用方式，以計算 8 位元總和檢查碼欄位中的值。一般只要加總資料位元組,即可得出總和檢查碼;而若加總資料位元組與受保護的 ID,即可進一步得出強化總和檢查碼。

LIN 2.0 規格則定義了加總檢查碼的計算方式：只要總和大於或等於 256 (與 modulo-255 或 modulo-256 不同)，則即加總所有值與 255 的減損 (Subtraction)。在 LIN 2.0 規格中，一般總和檢查碼必須搭配 LIN 1.3 的附屬節點，而強化總和檢查碼則用於搭配 LIN 2.0 的附屬節點。再進一步說明，第 60 ~ 63 組 ID 必定使用一般總和檢查碼。NI LIN 介面則提供 1 組屬性，可將總和檢查碼設定為一般檢查碼或強化檢查碼。而其預設值為一般檢查碼。在 LIN 2.0 規格中，不論總和檢查碼的屬性設定為何，第 60 ~ 63 組 ID 均是使用一般總和檢查碼。

圖 3 顯示主要作業表頭與附屬作業回應的整合方式,以建立 LIN 的完整框架。 

^{圖 3：建立 LIN 框架}

由於 LIN 匯流排為輪詢匯流排，因此各個框架的處理作業，將分配為下列的 名目時間槽 (Nominal time slot)：

THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
每個框架的處理作業會分配一個最大時間區段,如下所示:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

LIN 匯流排，可於 1 個 LIN 叢集中連接單一主要裝置 (節點)，與 1 組以上的附屬裝置 (節點)。各組節點的行為，則依其節點功能檔案而定。節點功能檔案 (Node capability file) 為系統定義工具的輸入，將可產生 LIN 說明檔案 (LIN Description file，LDF)，說明完整叢集的行為。而 LDF 將於系統產生器進行剖析 (Parse)，已於所需的節點中自動產生特定行為。而在此時點，主要節點的主作業將開始於匯流排上傳輸表頭，且叢集中的所有附屬作業 (包含組要節點本身的附屬作業)，將依 LDF 所指定的行為進行反應。

在一般條件下，LDF 可用於設定並建立 LIN 叢集的排程行為。舉例來說，LDF 可定義鮑率 (主要作業傳輸表頭的順序與時間延遲)，還有各個附屬作業的回應行為。NI LIN 硬體與 NI-CAN Frame API for LIN 本身並未完整支援 LDF，亦即使用者並無法將排程行為 (Scheduling behavior) 下載至硬體。但是仍支援初階的匯流排存取作業 (寫入表頭，並可發佈或簽署至反應)，讓使用者可於應用層級建立此排程行為。如 NI LIN 反應輸入框架 (Response Entry Frame) 類型的說明所提，NI LIN 硬體具備 1 組反應佇列，可儲存附屬作業的反應。反應佇列 (Response queue) 包含 64 個反應，均由 LIN 指定其 64 組 ID 的最大數值。如此將確保 LIN 介面附屬作業，可於 LIN 規格所定義的反應時間內，針對表頭做出反應。

適用於 LIN 的 NI-CAN Frame API 提供可靠的低階互動方式,能與 LIN 匯流排進行完整的互動。如此一來,一般使用者就能透過基本功能開發複雜的 LIN 網路分析與原型製作應用。NI-CAN Frame API for LIN 本身並不支援 LIN 診斷/設定、LDF，或排程表。然而，使用者仍可透過 NI-CAN Frame API for LIN，於應用內建置這些作業。

LIN 2.0 規格闡明，錯誤偵測應由附屬作業執行；因此主作業不需進行錯誤監控。LIN 2.0 規格並不強制於單一 LIN 框架中處理多個錯誤，亦不強制使用錯誤計數器 (Error counter)。只要於框架中發生首次錯誤，則附屬作業將停止處理框架，直至偵測到下 1 組 Break-sync 序列 (由 Master 所傳輸的下一個表頭)。若記錄匯流排錯誤 (Log bus error) 屬性設定為「True」,則匯流排錯誤框架將記錄至讀取中。若記錄匯流排錯誤屬性設定為「False」,則將由 ncWriteNet 或 ncWriteNetMult 回傳錯誤。 

LIN 亦可將錯誤回報至網路中。LIN 2.0 規格則定義了「Response_Error」狀態位元 (Status bit)，而其 Slave 必須透過所傳輸的框架之一，對 Master 進行回報。不論附屬節點是何時傳輸或接收框架，此位元均已設定於反應欄位中包含 1 筆錯誤。在此位元透過 Slave 所發佈的反應之一完成傳輸之後，將隨即清除。NI-CAN Frame API for LIN 本身並不支援「Response_Error」狀態位元，但可讓末端使用者於應用層級輕鬆建置此項功能。只要將記錄匯流排錯誤屬性 (Log bus errors attribute) 設定為 1,即可於讀取中啟動匯流排錯誤框架的記錄功能。而應用可接著透過錯誤代碼找出反應中的錯誤，以監控匯流排錯誤框架的讀數。一旦條件成立，則應用可於局部變數 (Local variable) 中設定「Response_Error 」狀態位元。應用接著可使用 NI LIN 反應輸入框架 (Response entry frame) 類型，透過包含「Response_Error」狀態位元的資料，更新 Slave 的反應佇列，最後清除局部變數中的位元。

LIN 具備可讓裝置進入休眠狀態的機制，可進一步達到省電效果。在 LIN 2.0 規格中，只要由 Master 傳送第一個資料位元組為零的診斷主需求框架 (ID=60)，則所有 Slave 將強制進入休眠模式。此特殊框架即稱為睡眠 (Go-to-sleep) 指令。若 LIN 停用超過 4 秒鐘，則 Slave 亦將自動進入休眠模式。NI-CAN Frame API for LIN 提供較高彈性，讓使用者將位於所需應用層級的 LIN 介面進入休眠。一旦接收到包含休眠要求訊息的完整框架，或是匯流排接收到停止超過 4 秒的框架，則使用者可將「LIN Sleep」屬性設定為「TRUE」，讓 LIN 介面進入休眠狀態。

LIN 也提供可喚醒匯流排裝置的機制。喚醒是可由匯流排上的任何節點 (附屬與主) 啟動的一項作業。根據 LIN 2.0 規格,透過強制讓匯流排主導 250 μs 至 5 ms 的方式,發出喚醒要求。每位附屬人員都應偵測到喚醒需求,並且準備在 100 毫秒內處理頭。主程式也應在附屬節點準備好時 (接收喚醒要求後的 100 ms 到 150 ms 內) 偵測覺醒需求,並開始傳送表頭。若 Master 在接收首次喚醒需求之後，並未於 150 ms 內發出表頭，則 Slave 將試著發出第二波的喚醒需求，並再次等待 150 ms。若 Master 仍未反應，則 Slave 將再度發出喚醒需求，並等待第三次的 150 ms。若仍未有反應，則在 Slave 發出第四次喚醒需求之前，將等待 1.5 秒。NI-CAN Frame API for LIN 將不論 LIN 介面是以 Master 或 Slave 進行作業，均將根據 LIN 2.0 規格執行喚醒。

LIN 2.0 規格進一步將 LIN 框架細分為 6 種類型：

1. 無條件 (Unconditional)
2. 事件觸發 (Event triggered)
3. 分散 (Sporadic)
4. 診斷 (Diagnostic)
5. 使用者定義 (User-defined)
6. 保留 (Reserved)

必須特別注意的是，這些框架類型的差異，即起因於其傳輸時序的不同，或其資料類型內容的相異。姑且不論框架的分類為何，完整的 LIN 框架均應包含主要作業所傳輸的表頭，與附屬作業所傳輸的反應。NI-CAN Frame API for LIN 則可處理所有上述的 LIN 特定框架類型。最常用的即為無條件框架類型。無條件框架將承載訊號 (資料),且其識別元位於 0 ~ 59 的範圍中。

事件觸發框架類型將於 1 個框架槽時間 (Frame slot time) 內，從多個 Slave 要求 1 個無條件框架反應，以節省匯流排頻寬。

事件觸發的框架 ID 可能介於 0 到 59 之間。事件觸發框架的 ID 可能處於 0 ~ 59 範圍內。若 Master 正針對無條件框架進行 Slave 查詢,則各個 Slave 可能自行對事件觸發表頭 ID 進行反應,並將用第一個資料位元組承載可能反應的受保護 ID。事件觸發框架則如下進行作業。Master 將於表頭中寫入事件觸發 ID。而若 Slave 的資料經過更新,則僅對事件觸發 ID 進行反應。

若僅有 1 個 Slave 發佈反應，而 Master 接收之後隨即查看第一個資料位元組，即可得知所接收的確切 Slave (透過受保護的 ID)。若有多個 Slave 發佈反應，則將發生衝突，則主要裝置的附屬作業將回報 1 筆匯流排錯誤。而主要裝置接著將透過無條件框架，查詢來自於各個 Slave 的反應。 

分散框架將嘗試為 LIN 提供某些動態行為。它們一律會攜帶訊號 (資料),其 ID 範圍從 0 到 59 之間。當主工作人員知道框架內的資料值 (訊號) 已更新時,只應將偶發框架的表頭傳送至框架插槽。此項特性可讓主要裝置的附屬作業，成為分散框架反應 (Sporadic frame respons) 的一般發佈器 (Normal publisher)。

診斷框架的長度一般均為 8 個資料位元組，且承載診斷或設定資料。其主要需求框架 ID 為 60；或附屬反應框架 ID 為 61。使用者定義框架的 ID 為 62，可承載任何類型的資訊。保留框架的 ID 為 63，且無法於 LIN 2.0 叢集中使用。

NI-XNET LIN

NI-XNET 產線整合了增速的 CAN、LIN 與 FlexRay 介面、還有最佳化的驅動程式、簡單易用的 API,與組態/除錯公用程式。透過 NI-XNET 介面,即可於 NI LabVIEW、LabVIEW Real-Time、與 C/C++ 中輕鬆開發應用,針對 FlexRay 與 CAN 進行模擬、測試、與原型製作。

NI-XNET PCI/PXI 與 C 系列 LIN 介面也具備整合式 LDF 支援、適用於主要作業的硬體時序排程,以及框架與訊號通訊功能。 

^{圖 4：適用於 CAN、LIN 與 FlexRay 的 NI-XNET 平台}

NI USB LIN

^{圖 5：NI USB-8506 LIN 介面}

您也可以使用 USB LIN 介面卡與 LIN 裝置通訊。這是一款平價的行動解決方案,適用於與 LIN 網路通訊。