FlexRay 汽車通訊匯流排概述

若要讓汽車持續提升安全性、提升效能、減少環境影響並提升舒適度,車輛電子控制單元 (ECU) 之間通訊的資料速度、數量與穩定性都必須提高。 高階的控制與安全系統，必須整合多組感測器、致動器，與 ECU，且要能超越現有標準 Controller Area Network (CAN) 的同步化功能與效能。 若再加上高頻寬需求,目前高階車款的甚至搭載超過 5 組獨立的 CAN 匯流排,而汽車工程師更渴望下一代的嵌入式網路。 這幾年在 OEM、工具供應商，與末端使用者的合作之下，FlexRay 標準已成為蓬勃發展的車內通訊匯流排，並可進一步解決新款車輛的需求難題。

若要於複雜的嵌入式設計 (如汽車系統) 中納入新的網路標準，則將耗上許多時間。 而 FlexRay 正可針對車用網路，解決其目前的高端挑戰與未來的主流難題，且不至於取代另外 2 項車內標準 – CAN 與 LIN。 為了妥善運用成本並降低傳輸難題，新一代汽車將 FlexRay 用於高端應用、CAN 用於主流的傳動通訊，而 LIN 則是低價位的車體電子系統。 

若工程師要能通盤了解車輛設計與生產過程的所有概念，必須先了解 FlexRay 運作的方法。 此篇文件將說明 FlexRay 的基礎核心概念。

FlexRay 的許多部分都是專為降低成本而設計,同時在嚴苛環境中提供絕佳效能。 FlexRay 是採用非抗雜訊式雙絞線連接節點。 FlexRay 所支援的單通道與雙通道設定，亦分別包含 1 或 2 組雙絞線。 而各組雙絞線的差動訊號產生功能，不需昂貴的抗雜訊裝置，亦可降低外部雜訊對網路的影響。 大多數的 FlexRay 節點均具備電源線與接地線，可供電予收發器與微處理器。

雙通道設計可提升頻寬及/或容錯功能。 大多數的第一代 FlexRay 網路僅利用 1 個頻道，藉以降低接線成本；但由於應用複雜度與安全性需求不斷提升，將來的網路勢必使用此 2 個通道。 

FlexRay 匯流排的末端均需要端點 (Termination)，即是在雙訊號接線之間所連接的電阻器。 僅限於多點 (Multi-drop) 匯流排上的末端節點，才需要端點。若端點過多或過少，均可能阻斷 FlexRay 網路。 特殊網路的建構方式不一，而常見的 FlexRay 網路則具有 80 ~ 110 歐姆的接線阻抗，且末端端點均必須符合此阻抗。當將 FlexRay 節點連至測試設定時，端點即為發生中斷 (Frustration) 的常見原因之一。目前電腦架構的 FlexRay 介面均可能內建了快取 (On-board) 端點電阻器，以簡化接線作業。 

FlexRay、CAN 與 LIN 與更傳統的網路 (例如乙太網路) 的區別之一,就是其拓撲或網路配置。FlexRay 可支援簡易的多點 (Multi-drop) 被動連結，亦可針對更複雜的網路支援主動星形連結。 根據車輛配置與 FlexRay 的使用層級,應選擇正確的拓撲,為相關設計達到最佳的成本、效能、與穩定性考量。 

多點 (Multi-drop) 匯流排

FlexRay 常用於簡易的 多降線匯流排拓撲,其中採用單一網路連接線,用於連接多個 ECU。 CAN 與 LIN 亦使用相同的拓撲,並近似於 OEM 拓撲;因此成為第一代 FlexRay 車輛最普遍的拓撲。 每個 ECU 都可「分支」至匯流排的核心「分流」(trunk) 與之間的短距離。網路端點安裝端點電阻器,可排除訊號反射的問題。 相較於 CAN 的 1 Mbit，FlexRay 是以較高的 10 Mbit/s 頻率進行作業，因此 FlexRay 工程師必須注意網路目前的端點與配置情形，以避免發生訊號密度的問題。 而車輛往往共用類似的配置，但由於多點格式亦可符合車輛的需求，可簡化安裝作業，並減少車體中的接線數量。 

星形網路 (Star Network)

FlexRay 標準支援「星形 (Star)」設定,即以獨立接線連至主動的中央節點。 此節點的功能,近似於電腦乙太網路架構中的集線器 (Hub)。 主動式的星形設定,可於長距離執行或切割 FlexRay 網路,因此當網路發生錯誤時,星形設定可穩定持續運作某個部分的網路。若星形網路的其中 1 個分支發生中斷或短路，則其他分支亦可繼續其功能。 由於長距離接線可能產生更多環境噪音 (由大型電子馬達所產生的電磁波)，因此若能使用多個分支，則可縮短接線總量，並協助提升雜訊抑制功能。 

混合式網路

匯流排與星形拓撲可合併成 混合 式拓撲。未來的 FlexRay 網路極可能包含混合式網路，以利用匯流排拓撲的簡單易用性與成本優勢，並可享有車輛所需的星形網路效能與穩定性。 

FlexRay 協定是獨一無二的時效觸發協定,可針對可預測的時間範圍內 (降至微秒) 到達的精確資料提供選項,以及類似 CAN 的動態事件導向資料,以處理多種框架。FlexRay 並可透過預先設定的通訊週期 (Communication cycle)，完成此混合的核心靜態與動態框架，且此框架可為靜態與動態資料提供預先定義的空間。網路工程師並可透過網路設定此空間。  CAN 節點僅需確認通訊的正確鮑率,而 FlexRay 網路上的節點必須確認網路中所有區塊的設定狀態,才可進行通訊。  

在搭配任何多點式匯流排時，單次僅限 1 個節點可透過電子方式，將資料寫入至匯流排中。 若有 2 個節點要同時寫入資料，則將造成匯流排衝突與資料毀損的情形。 有多種機制可用來防止匯流排受到衝擊。舉例來說,CAN 使用的仲裁方案是在匯流排上看到優先順序較高的訊息時,節點會傳輸至其他節點。 這項技術雖然靈活且易於擴充,但無法提供極高的資料傳輸率,也無法保證能及時傳送資料。  FlexRay 則是透過分時多工存取 (Time Division Multiple Access，TDMA) 架構管理多個節點。 每個 FlexRay 節點都會同步化至相同的時脈,而每個節點都會等待其在匯流排上寫入。 由於時序在 TDMA 架構中是一致的,因此 FlexRay 能確保傳送至網路節點的資料精確度或一致性。若系統極為依賴節點之間的即時資料,則此架構理所當然可提供多項優勢。 

嵌入式網路將依電腦架構的網路而有所不同，即便具備類似的組態，但若一旦於產線中完成組裝，則再也無法更改。 如此一來,幾乎不需要附加機制,即可於執行期間尋找並設定裝置,即如電腦在加入新的接線或無線網路所進行的作業一般。 由於可提早設計網路組態，因此工程師可省下大量成本並提升網路穩定性。 

若要讓如 FlexRay 的 TDMA 網路正常運作，則必須正確設定所有節點。 FlexRay 標準可適用於多種不同類型的網路,並讓網路工程師能對網路更新速度、精確資料量、動態資料量,與其他參數之間取得系統的平衡。 每組 FlexRay 網路均可能有所不同,所以在各個節點加入至匯流排之前,必須設定正確的網路參數。  

為了簡化節點之間的網路組態維護作業，FlexRay 組織設定了標準化格式，以利於設計程序中儲存並傳輸這些參數。 Field Bus Exchange Format 或稱為 FIBEX 檔案,即為 ASAM 所定義的標準,可讓網路設計、原型製作、檢驗、與測試作業,均可輕鬆共用網路參數,並迅速設定 ECU、測試工具、硬體迴路模擬系統等等,以輕鬆連線匯流排。 

通訊週期 (Communication Cycle)

FlexRay 通訊週期 (Communication cycle) 為 FlexRay 媒體存取架構的基本要素。網路設計期間的週期持續時間固定的,但通常約為 1-5 ms。 通訊週期包含四個主要部分: 

 
^{圖 1：通訊週期}

1. 靜態區段
   針對在固定期間抵達的精確資料,保留時間槽 (Slot)。 
2. 動態區段
   動態區段 (Dynamic Segment) 動態區段的動作較類似於 CAN,且用於多種較低精確度的事件架構資料。 
3. Symbol Window
   一般用於啟動網路時的網路維護與訊號產生。 
4. 網路閒置時間 (Idle Time)
   網路閒置時間 (Idle Time) 已知的「安靜」時間,可用於維護節點時脈之間的同步化狀態。

^{圖 2：FlexRay 細節}

FlexRay 網路的時間最小實用單位 (Practical unit) 即為a Macrotick。若 FlexRay 具備多組控制器，則可自行主動進行同步化並調整區域時脈 (Local time)，而 Macrotick 將於相同時間點內，發生於網路上的所有節點。巨集雖然可針對特定網路進行設定,但長度通常是 1 毫秒。 由於巨集會同步化,因此需要依賴的資料也會同步化。 

1.靜態區段

^{圖 3： 包含 3 組 ECU 的靜態區段,將資料傳輸至 4 個保留時間槽 (Slot) 的情形。}

靜態區段代表了框架的藍色部分,也就是週期中專門排程數個時間觸發的框架的空間。 此區段可分割為數個時間槽，每個時間槽均包含資料的保留框架 (Reserved frame)。 當各個時間槽準時發生，所保留的 ECU 則有機會將其資料傳輸至時間槽中。一旦時間過去,ECU 則必須等到下一個週期,才能將資料再次傳輸至時間槽中。 由於早已知道週期中的確切時間點，因此程式可確實知道資料產生的時間。此特性特別適於根據穩定間隔的數據，計算出控制迴圈。 圖 3 表示由 3 組 ECU 所使用的簡易網路，其中包含 4 組暫態時間槽。實際的 FlexRay 網路可能包含多達數十個暫態時間槽。 

^{圖 4：缺少 ECU #2 的靜態插槽插圖。}

若 ECU 離線或暫停資料傳輸,則其時間槽將保持開放,且其他 ECU 亦不會使用之;如圖 4 所示。 

2.動態區段

^{圖 5：圖 5. 僅透過 1 組 ECU 廣播資料的 FlexRay 動態時間槽。}

大多數的嵌入式網路，均具備少量的高速訊息，還有大量的低速、低時效性網路。 若要容納多筆資料，且不致讓大量靜態時間槽拖慢 FlexRay 週期，則可讓動態區段偶爾客串進行資料傳輸作業。 動態區段為固定的長度，因此在每個週期中，能置於動態區段的資料數量亦有所限制。為了排列資料的優先性，將會為各組資料框架預先指派迷你時間槽 (Minislot)，以於動態區段中進行合適的傳輸作業。 迷你插槽的長度通常是 macrotick (1 個微秒)。  優先順序較高的資料會在接近動態框架起點時獲得小插槽。 

一旦發生迷你時間槽，則 ECU 將有較簡短的機會 (Brief opportunity) 以廣播其框架。 若未能廣播，則遭喪失其動態框架中的點 (Spot)，且接著產生下 1 個迷你時間槽。 此過程會將迷你時間槽下移,直到 ECU 決定要廣播其資料。 當廣播資料後,往後的迷你時間槽必須等待 ECU 完成其資料廣播。若動態框架分窗 (Window) 結束,則較低優先性的迷你時間槽必須等待下一個週期,以取得廣播機會。 

^{圖 6：此圖顯示 ECU 2 與 3 正於其迷你時間槽中進行廣播,且沒有留下多餘時間給較低優先性的迷你時間槽。}

圖 5 顯示 ECU #1 在前 7 個小插槽選擇不進行廣播之後,在其迷你插槽中進行廣播。 圖 6 的第二與第三號 ECU 則使用了前 2 個迷你時間槽，而沒有多餘的時間讓第一號 ECU 進行廣播。 第一號 ECU 必須等待下 1 個週期再進行廣播。 

動態區段的最終結果,就是類似於 CAN 所用的仲裁方案。

3.Symbol Window

Symbol Window (符碼) 主要用於維護與辨別特殊週期,例如冷啟動週期。 大多數的高階應用並不會與 Symbol window 產生互動。 

4.網路閒置時間 (Idle Time)

網路閒置時間是透過 ECU 預先定義的已知長度而來。 ECU 可利用此閒置時間，針對上 1 個週期所發生的任何漂移 (Drift) 進行調整。 

資料安全與錯誤處理

FlexRay 網路可進行單或雙通道通訊，以提供可調整的容錯功能。針對高安全性的應用，連接匯流排的裝置可能同時使用 2 個通道以傳輸資料。然而，若不需要冗餘 (Redundancy) 功能時，亦可能僅連接 1 個通道；或是使用 2 個通道傳輸非冗餘資料，藉以提升頻寬。

在實體層 (Physical layer) 中，FlexRay 可進行快速錯誤偵測與訊號產生作業，並以獨立的匯流排監控器 (Bus Guardian) 進行錯誤抑制 (Error containment)。Bus Guardian 為實體層中的機制，可針對未經叢集通訊排程所指派的通訊作業，保護通道避免受其干擾。

框架格式

^{圖 7：FlexRay 框架細節
靜態或動態區段的每個插槽均包含一個 FlexRay 框架。而此框架可分割為 3 個區段：表頭 (Header)、承載 (Payload),與表尾 (Trailer)。}

表頭 (Header)

^{圖 8：FlexRay 框架的位元組切割}

標頭為 5 個位元組 (40 個位元) 長,並包含下列欄位: 

1. 狀態位元 (Status Bit) - 5 位元
2. Frame ID - 11 位元
3. 承載長度 (Payload Length) - 7 位元
4. 表頭 CRC - 11 位元
5. 週期計數 (Cycle Count) - 6 位元

Frame ID 將定義所應傳輸框架的時間槽，並可針對事件觸發的框架指派其優先性。Payload Length 則包含框架所要傳輸的字數 (number of words)。Header CRC 則於傳輸期間偵測錯誤。Cycle Count 則包含計數器的值；每次通訊週期開始，該值將隨之遞增。

有效載荷

^{圖 9：FlexRay 框架的承載。}

承載包含由框架所傳輸的實際資料。FlexRay 酬載或資料框架的長度最高 127 個字 (254 位元組),比 CAN 更長 30 倍。

表尾 (Trailer)

^{圖 10：FlexRay 框架的表尾。}

表尾包含 3 組 8 位元的 CRC，可偵測錯誤。

訊號

^{圖 11：框架訊號轉換}

FlexRay 資料是以位元組 (Byte) 的方式呈現。 大多數應用均必須以到小數點的實際值呈現資料，包含單位、比例，與相關限制。 當從 FlexRay 框架取得 1 個以上的位元或位元組，並套用相關比例與偏移 (Offset)，即可得到 1 組訊號，可溝通 ECU 之間的實際參數。 大多數 ECU 程式均可搭配 FlexRay 資料以構成訊號,並讓驅動程式或初階的通訊協定,將該筆資料轉換為原始的框架資料。 

一般車輛即可產生數百到數千筆的訊號。 由於這些訊號的調整 (Scaling)、偏移 (Offset)、定義,與位置均可改變,因此 FlexRay 網路可將這些定義儲存於用以定義網路的 FIBEX 資料庫。如此可簡化 FlexRay 網路的寫入程式，讓工程師僅需專注於程式碼中的訊號名稱。當該程式更新至 ECU 或測試系統時,編碼器或驅動程式將接著提取最新的調整或偏移資訊。 

時脈同步化與冷開機 (Cold start)

^{圖 12：簡化 FlexRay 網路的同步化作業}

FlexRay 具備專屬功能，不需外部的同步化時脈訊號，亦可同步化網路上的節點。 如此必須使用 2 種特殊框架：Startup Frames 與 Sync Frames。 若要啟動 FlexRay 叢集，則需要至少 2 個不同的節點以傳輸開始框架。 要開始 FlexRay 匯流排的動作，即為所謂的冷開機 (Cold-start)，而傳送開機框架的節點即為冷開機節點。 開機框架如同起始觸發器 (Start trigger)，可告知網路上的所有節點開始作業。 

網路啟動後,所有節點都必須將內部震盪器與網路巨集同步。 只要再多使用 2 個同步化節點，即可完成此作業。 此可為網路上任何 2 個預先指派的獨立節點，當首次將之開啟時，即可廣播特定的同步化框架。 網路上的其他節點將等待同步化框架廣播完成，並量測各次廣播之間的時間，以透過 FlexRay 的時間校準其內部時脈。同步框架會在 FIBEX 網路設定中指定。 

一旦網路同步並上線,就會量測網路閒置時間 (圖中空白空間),並用於調整從週期到週期的時脈,以維持緊密的同步化。 

週期內控制

^{圖 13：「In-cycle control」功能將讀取 4 個車輪的位置,並於單一 FlexRay 週期中更新車輛的控制輸出。}

「In-cycle control」屬於 FlexRay 的進階功能。 圖 13 表示框架靜態時間槽所廣播的 4 個車輪位置。由於在 5 號中央控制器最後更新指令之前，即已產生車輪的位置，因此控制器有充裕的時間處理，並於同一通訊週期中快速輸出。 此即為 FlexRay 網路所提供的極高速控制速率。 

Field Bus EXchange (FIBEX) 格式是由 ASAM 聯盟所定義的 XML 架構標準化檔案格式,用於描述汽車網路。FIBEX 資料庫格式屬於 FlexRay 網路的標準格式，因此可相容於多種不同的汽車協定，屬於彈性的標準。FIBEX 資料庫一般均由車輛網路工程師所設計,並可共用於車輛的特定概念之上。透過 FIBEX 檔案、電腦介面或是可支援的 ECU,不需手動設定介面與訊號定義,即可輕鬆與車輛網路進行互動。 

FIBEX 包含特定網路的多個概念,包括: 

• 傳輸與接收排序
• 框架定義
• 訊號定義
• 訊號的位元組編碼
• 網路拓撲
• ECU 資訊
• 包含鮑率與時序的網路組態

如需更多關於 FIBEX 的資訊,請參閱 FIBEX 簡介文章。

NI 提供高效能的 PCI 與 PXI FlexRay 介面,可連接電腦與 FlexRay 網路。 透過電腦架構的介面,即可於 FlexRay 啟動的 ECU 上執行多項設計作業,包含: 

• 快速原型製作
• 硬體迴路 (HIL) 模擬
• 匯流排記錄與除錯
• 訊號資料擷取
• 系統診斷
• 客制化應用

如需 NI FlexRay 介面的詳細資訊,請參閱 NI-XNET FlexRay 平台簡介。

FlexRay 通訊網路可滿足新一代汽車的精確、能容錯的高速匯流排系統效能需求。

相關連結：

• FIBEX 介紹
• NI-XNET FlexRay 平台介紹。