- LIN Bus簡介及實例
- LIN Bus技術現況
- 運作架構
- 系統最佳化技術
- 與CAN Bus的區隔
- 門控建置開發
LIN Bus在車用總線中以低成本、省資源為其特點，妥善運用將可提高汽車附加價值。本文將介紹LIN Bus技術現況、運作架構、系統最佳化技術、與CAN Bus的區隔，并以門控建置開發實例提供進一步的說明。
今日汽車的設計在安全、舒適、便利和環保等訴求下，對電子技術的仰賴日益加深。目前在汽車架構中的車體（Car body）、傳動系統（Power train）、安全系統（Safety）和車載資通娛樂系統（TelemaTIcs/Infotainment）等各個部分中，都可以看到愈來愈多的電子控制組件（ECU），它們賦與汽車更具智能性的操控能力，例如會自動檢查門窗、車燈是否關閉，在駕駛人進入車內前自動接通電源，離開時則會檢查是否切斷電源等等。
目前汽車內電子組件的連結愈來愈復雜，一臺車中平均存在著80個左右的電子組件或模組系統。過去采用傳統的電纜方式來連結車燈、電動機、電磁閥、加熱器、空調等設備，若以此方式來連結電子組件，龐大的纜線數量將造成車體重量的沉重負擔。因此，有必要導入標準化的總線技術，此舉除了降低建置的困難度及配線重量外，也能提升控制的精確性，而且比較不會有線路老化、磨損的問題。
在此趨勢下，已有各種總線技術出現在車載網路（In-Vehicle Network）當中，它們各有其技術特色，適合不同的應用領域。大致上可以分為五類：第一類是傳輸速度最低的LIN、TTP/A，適用于車體控制；第二類包括低速CAN、SAE J1850、VAN（Vehicle Area Network）等中速網路總線，適用于對即時性要求不高的通信應用；第三類包括高速CAN、TTP/C等，適用于高速、即時閉環控制的多路傳輸網；第四類包括IDB-C、IDB-M（D2B、MOST、IDB1394）、IDB-Wireless（藍芽）等，專門用在車載資通娛樂網路之中；第五類則包括 FlexRay和Byteflight，用在最具關鍵性、即時性最高的人身安全系統（請參考表一）。
本文將探討LIN的技術規格現況及在門控系統中的建置實例。
LIN Bus技術現況
區域互連網路（Local Interconnect Network, LIN）是基于序列通信協定的車載總線的子集系統（sub-bus system）。為了支持多個智慧性節點的分布式系統設計，LIN提供標準化的API以及軟件設計流程。它的傳輸速度雖然不高，但其低成本的特性，能為不需要用到CAN的裝置提供較為完善的網路功能，包括空調控制（Climate Control）、后照鏡（Mirrors）、車門模組（Door Modules）、座椅（Seats）、智能性交換器（Smart Switches）、低成本感測器（Low-cost Sensors）等，請參考圖一。
在重要規格的演進上，自1999年推出LIN 1.0版、2002年12月修訂LIN 1.3版，并在2003年9月再次發布LIN 2.0版規范，持續改進了LIN總線的性能與適用性。此外，美國汽車工程師協會（SAE）下屬的車輛架構任務組（Task Force）也基于LIN 2.0提出J2602規范，進一步降低了LIN 2.0中軟件單元的復雜性，此舉讓LIN從節點所需要的軟件代碼長度縮短，在建置上會更有效率。此外，市場上的領導業者也會針對LIN的效能提出改善技術，例如ST的LINSCI。一般來說，LIN的主要特色及優勢包括：
- 采用一個主節點、多個從節點的概念（最多支持16個節點）；
- 由于基于普通UART/SCI接口協定，其軟硬件成本極低；
- 在從節點（slave node）中不用晶體振蕩器（crystal oscillator）或陶瓷諧振器（ceramic resonator）時鐘，也能做到自同步性，這能進一步降低成本；
- 信號傳播時間可預先計算，以滿足信號傳輸的確定性；
- 基于應用交互作用的信號；
- 可達 20 kbps資料傳輸率；
- 總線電纜的長度最多可以擴展到40公尺；[page]
LIN Bus運作架構
LIN網路是基于「一主多從」的主從原則（master/slave principle）而形成的拓樸結構，因此需要由主節點周期性地對從節點發出詢問動作。周期的設定必須根據事件偵測的即時性要求，并將從節點的偵測結果傳送到到主控制器。
在LIN上傳輸的訊號，其訊框結構上是由一個由主任務提供的標頭（header）和由從任務處理的回應部分（Response）所構成。標頭包含一個13 位的同步間隔欄位（synch break field）；一個由主任務產生的同步欄位（synch field）；以及一個辨識欄位（identifier field）。其中每一個位組欄位都以串行位元組方式發送，起始位元組的第一位編碼為“0”，而終止位編碼為“1”。
在回應部分則包含二、四或八個位組的資料欄位（data filed），以及一個位組的驗證欄位（checksum field）。由主任務執行的訊框標頭會依整個LIN叢集的進度表決定每個訊框的傳輸時間，以確保網路不會超載，并能確保資料傳輸的確定性。在LIN網路中只有主節點采用晶體振蕩器來為系統提供精確的基本時鐘，此時鐘會嵌入上述的同步欄位中，讓從任務能與主節點時序同步。請參考圖二。
LINSCI最佳化LIN系統
以標準SCI所建置的LIN網路雖已具備極佳的建置優勢，但讓想讓系統等級獲得最佳化，仍存在一些限制。若想得到最佳化的LIN系統，必須考慮以下因素：
- LIN傳輸所需要的CPU負荷；
- 應用上所需要的時脈準確性；
- LIN傳輸的頻寬；
- LIN界面的穩定性/有效性；
因此，為了達到最佳化的需求，有必要在硬體技術上進行強化。ST的LINSCI即是經過強化的硬體SCI埠，可透過減少CPU負載來提升系統效能；另外，其內部的1MHz震蕩器、帶有運算放大器的快速10位ADC，以及低電壓檢測器的可修整重啟電路─可透過消除對這些功能所需之外部電路的需求來簡化系統設計并降低制造成本。8Kbyte的擴充快閃記憶體能在單一供給電壓下操作，以降低電路板復雜度并提供更快速的編程能力。
LINSCI可以被嵌入在一顆很小的8-bit MCU中，它的目的就是要讓從設備的LIN功能能完全發揮，其功能包括標頭偵測（Header Detection）、指示器（Identifier）和非相關位組過濾（Irrelevant Byte Filtering）、延伸性錯誤偵測（Extended Error Detection）和再同步化（Resynchronisation）等。LINSCI的訊框架構請參考圖三。
進一步來看，LIN的鮑率（Baud rate）是10kbps和20kbps，這很難達成標準SCI位時間取樣原則所需要的2%準確性。這是因為鮑率預定標器（prescaler）的有限分辨率所造成的。假設CPU的頻率是8MHz，LIN的鮑率是20kbps，由于LIN的時脈容忍度是15%，這造成2.33%的量化錯誤。在LINSCI 中則以12位unsigned定點值（即LDIV）來取代8位整數值的鮑率預定標器，能讓上述的量化誤差下降到0.15%。
門控系統建置案例
以下將以門控模組系統的建置，進一步說明LIN總線的應用及設計要求。在今日中階及高階車款中的門控系統，往往需要這些功能：
- 門鎖（lock）和防盜門鎖（dead lock latch）；
- 動力車窗（Power Window）升降；
- 踏腳燈（Footstep light）；
- 切換面板照明（Switch panel illumination）；
圖四顯示以LIN網路組成的門控系統，它的主控節點是由一個中央車體控制單元（Central Body ECU），它和車體CAN網路相連結。每個車門都由一個車門模組（DM-Driver, DM-Passenger, DM-RearRight, DM-RearLeft）所組成，能夠提供動力車窗及門鎖功能。此外，兩個前門都有后視鏡控制（MMR, MML）的從節點。在此系統中，還會有一個嵌在駕駛端的中央切換面板（Central Switch panel, SP），它是一個獨立的從節點，由它來控制所有的動力車窗、手動門鎖及后視鏡調整等功能。
此系統會對LIN網路形成下述要求：
- 當主控器收到從遙控鑰匙發出的有效訊號時，必須要啟動門控系統，從節點通常是通過CAN總線來接收；
- 當正確的鑰匙打開前門時，也同時啟動門控系統；從節點會直接反應而不需經由與主控器的通訊；
- 對切換面板的詢問動作（Polling），以確?；貞獙Ω鱾€驅動裝置控制（動力車窗、后視鏡調整、門鎖）的主動式切換；
- 對所有從節點的詢問動作，以得到車窗升降的位置狀態，以及車門的開關情況；
- 對所有從節點的睡眠模式控制（即電池供應操作模式）；
在清楚了LIN網路的要求后，我們必須選擇功能相符的微控制器（MCU）來達成。這些MCU必須針對車窗的升降提供防夾（AnTI pinch）、馬達的PWM控制及車窗位置的監控功能；能以SPI接口來控制門鎖馬達；對于車鑰匙的拔出及開門的動作，能夠提供電源供應模式的接觸式監控，以及對后視鏡及切換面板的操控功能。（圖五）是門控模組的功能方塊圖架構。
在系統的規劃上，要一些注意的要領，這包括時序的準確性，也就是為了正確的運作，車門模組需要一個容忍度小于3%的時間參考，車窗防夾（anti- pinch）功能的復雜算法就需要這種準確性。此外，針對安全性（如防夾）和便利性（如門鎖偵測）等功能，都會有實時性的要求。
以手動打開汽車門鎖的動作為例，從鑰匙插入門鎖到打開，可接受的延遲時間必須小于200ms，這表示反應時間很短。傳動馬達需要約100ms去打開門鎖，這只留100ms給MCU來完成從低功率模式啟動、偵測到鑰匙，并觸發傳動裝置等動作。因此這個網路必須采用LIN最快的傳輸速率，也就是 20kbps。而在20kbps的傳輸率下，CPU的反應時間必須要小于1ms，否則資料會漏失，LIN的傳輸會失敗。
另一個設計議題則是功耗，這對于多數的ECU來說都是很關鍵的。以門控系統來說，即使車子熄火了，系統仍需進行間隔性的監控詢問動作，這就會造成車子電力的持續消耗。監控的延遲間隔設定是蠻矛盾的事，因時間間隔太長，則會造成反應動作上的遲鈍現象，但太短，又會增加系統的功耗。[page]
故障安全設計
相較于車體CAN總線系統，LIN總線并不具有錯誤容忍性（fault tolerant），因此必須考慮短路時總線線路的故障安全（fail-safe）機制，也就是每個節點必須有能力分辨出短路的總線線路。反應動作必須遵循特定的程序（例如讓門鎖維持在打開的狀態，而每個節點的功耗應盡可能降低）。
以ST的L9638 LIN收發器為例，它能提供額外的故障安全裝置（fail-safe）功能，例如對短路狀態的處理。當MCU辨識出短路的LIN總線線路，電子控制器（ECU）可以把自己關掉，當收發器在消除短路狀況后還能夠重新啟動。
LIN Bus與CAN Bus有所區隔
目前電子控制組件已散布整臺車子，它們讓傳動及感測功能變得更有智能性。在本文介紹的LIN網路是屬于低傳輸速率的總線規格，但它的低成本及傳輸的正確性，仍然相當受到車廠的歡迎。據估計在歐洲新出廠的車子中，LIN的應用占了相當大的比例。
當然，LIN不會有和CAN總線控制網路相同的效能，因此，在某一特定的車載系統中，LIN總線是否能提供滿意的效能，就得看應用本身的需求而定。此外，透過專屬的設計，能夠讓LIN的功能得到全面性的發揮，例如將LIN協定以硬體方式建置（如LINSCI），可以讓LIN的驅動程序碼更為簡化，也能增加系統的可靠性。MCU的設計也是一大關鍵，以ST72F361為例，它在標準MCU上提供先進的SCI接口，并支持LIN功能，除了能降低 CPU的負荷外，也能省卻較高成本的精準時序資源。
LIN總線本來就是為了與CAN形成區隔而設計的，以門控系統來說，它能大大降低從主控器連結到每個車門的線路數量，而成本也會比采用CAN總線控制的解決方案來得低。不過，如果是更關鍵性的應用，就得考慮成本更高的CAN，以兩線總線來提供容錯能力及更高的效能。
