翻譯原文：https://research.utwente.nl/files/5502340/kiszka05rtnet.pdf
RTnet – 靈活的硬實時網路框架
Jan Kiszka, Bernardo Wagner Institute for Systems Engineering Real-Time Systems Group University of Hannover, Germany {kiszka, wagner}@rts.uni-hannover.de
Yuchen Zhang, Jan Broenink Control Engineering Group Department of Electrical Engineering University of Twente, the Netherlands y.zhang-4@student.utwente.nl, j.f.broenink@utwente.nl
0 摘要
本文介紹了開源專案 RTnet。RTnet 為乙太網和其他傳輸媒體上的硬實時通訊提供了一個可定製和可擴充套件的框架。 本文描述了 RTnet 的架構、核心元件和協議。
FireWire 是作為乙太網的強大替代品引入的，並介紹了它與 RTnet 的整合。 此外，還概述了該網路框架的可用和未來應用協議。
1 介紹
實時乙太網已經發展成為當前工業自動化研究和應用的核心課題之一。
過去幾年，市場上出現了大量供應商驅動的解決方案，聲稱要取代傳統的現場匯流排。 [18] 上可用解決方案的概述目前列出了 16 種軟硬實時乙太網變體。 它們中的大多數要麼需要對節點或基礎設施元件進行特殊的硬體擴充套件，要麼只提供軟實時保證。
學術界的方法通常旨在展示特定的概念，並且缺乏通用的作業系統或硬體支援。 [7] 中給出了軟和硬實時協議研究的廣泛概述。 最近的一些方法是例如 FTT-Ethernet [16]、RT-EP [12] 或交換機和流量整形器的組合 [11]。所有這些方法都帶有各種傳輸和應用程式協議以及程式設計介面，它們通常彼此不相容。此外，除了乙太網 100Base-T 之外，還有其他接近實時域的傳輸媒體：千兆乙太網、IEEE 802.11 或藍芽等無線媒體，以及使用 FireWire 進行時間關鍵型控制和測量任務等有希望的趨勢。雖然這種解決方案的多樣性可以刺激競爭，但它也干擾了研究和工業場景中應用程式的可移植性和可擴充套件性。此外，問題在於哪些解決方案可以保證長期可用性，尤其是在考慮到其特定的硬體依賴性時。為了提供一個廣泛的硬體獨立和靈活的實時通訊平臺，RTnet 專案於 2001 年在漢諾威大學重新建立，基於想法和原始碼以前提供確定性網路的努力[10]。 RTnet 是一個純粹基於軟體的框架，用於在硬實時約束下交換任意資料。
可用的實現建立在 Linux 上，具有硬實時擴充套件 RTAI [17]。如圖 1 所示，RTnet 堆疊的設計靈感來自 Linux 網路子系統的模組化結構。它以可擴充套件性和可擴充套件性為目標，以適應應用程式和研究場景的不同需求。 RTnet 的軟體方法既解決了支援硬實時通訊的特定硬體的獨立性，也解決了在可用時使用此類硬體的可能性。此外，它還可以整合乙太網以外的各種其他通訊媒體。
本文介紹了 RTnet 的架構及其核心元件的實現。第 2 節描述了由堆疊核心、驅動程式介面、可用傳輸協議（如實時 UDP/IP 實現）、提供給管理工具和實時應用程式的程式設計介面以及資料包捕獲擴充套件 RTcap 組成的 RTnet 基礎服務。第 3 節介紹了確定性媒體訪問控制框架 RTmac，包括其用於時間非關鍵流量 (VNIC) 的隧道網路裝置。該部分還將詳細介紹 RTnet 的乙太網預設訪問控制規則 TDMA。最後，第 4 節通過解決實時配置服務 RTcfg 來結束堆疊概述。到目前為止，RTnet 的實現主要集中在乙太網上。第 5 節介紹了向框架新增實時 IEEE 1394 (FireWire) 支援的概念和最新進展。該部分還指出了該媒體型別的優勢以及在自動化領域的可能應用。此外，第 6 節描述了在 RTnet 上工作的可用和未來的應用程式協議和功能齊全的中介軟體。
2 基礎服務
RTnet 包含一組大多數場景所需的中心服務。下面將介紹這些服務。
2.1 資料包管理
RTnet 的關鍵部分之一是處理包含傳入和傳出資料的資料包的管理。應該傳輸的資料包在傳送任務的上下文中通過堆疊傳遞，即實時應用程式或內部 RTnet 服務。相反，傳入的資料包首先從網路控制器驅動程式傳遞到所謂的堆疊管理器。實時任務通過將資料包傳遞給相應的處理程式，根據它們的協議型別對資料包進行解複用。
堆疊管理器的優先順序必須高於所有使用 RTnet 服務的應用程式，以避免優先順序倒置。這個概念類似於在大多數作業系統中都可以找到的下半部中斷處理。
堆疊和驅動程式使用稱為 rtskb（源自 Linux sk buff 結構）的統一資料結構來處理資料包緩衝區。雖然經典網路堆疊動態分配此類緩衝區和管理結構，但由於實時要求，RTnet 必須使用不同的方案。首先，所有 rtskbs 都是在設定期間預先分配的。由於目前 RTnet 不支援多個使用者之間共享緩衝區，管理結構和有效負載緩衝區形成單個記憶體片段。其次，每個 rtskb 的大小都是固定的，總是可以承載最大的物理資料包。這個限制是必要的，以避免由於記憶體碎片導致的短缺，並允許在使用者之間交換任意 rtskbs。
RTnet 中的資料包生產者和消費者必須建立 rtskb 池才能參與通訊。在執行時，從這些池中分配新的 rtskb。 rtskb 中對其原始池的引用允許在釋放時將其歸還給其所有者。當資料包生產者將 rtskb 交給目標消費者時，只有當消費者能夠從自己的池中提供免費的補償 rtskb 時，所有權才會發生變化。否則資料包被丟棄，相關的緩衝區可以立即被重用。
典型的生產者和消費者是一側的介面卡驅動程式和另一側的套接字。但 VNIC 或 RTcfg 和 ICMP 等管理協議也提供了自己的mem pool。mem pool是使用底層作業系統的不確定記憶體分配服務在非實時上下文中建立或調整大小的。為了在實時上下文中也允許套接字建立和mem pool擴充套件，在這種情況下，所需的 rtskbs 從堆疊初始化期間建立的特殊全域性預分配緩衝區池中傳輸。
2.2 UDP/IP 實現
與標準 UDP/IP 堆疊相比，需要進行一些修改才能建立 RTnet 中包含的確定性變體。首先，動態地址解析協議 (ARP) 被轉換為在設定期間執行的靜態機制。如果稍後未知目標地址，則不會發出解析請求，但會向呼叫者返回傳輸錯誤。否則，資料包的最壞情況傳輸延遲將包括潛在地址解析的延遲。
其次，簡化了路由過程。輸出路由錶針對 RTnet 使用的有限條目進行了優化。為了加快資料包的建立，這些表還包括 ARP 結果，即目標硬體地址。
IP 資料包的碎片整理需要特別注意。在經典網路堆疊中，此任務由 IP 層在涉及任何更高層（如 UDP）之前執行。因此，由於實際接收者尚不清楚，因此需要一個全域性 rtskb 池來在最後一個片段到達之前緩衝所有片段。向現有鏈新增新片段需要在所有當前待處理的 IP 資料包鏈的全域性列表中查詢。此外，必須在超時後清理不完整的鏈以避免緩衝區短缺並保持全域性 IP 片段列表較小。
RTnet 的 UDP/IP 堆疊包含多種機制，以儘可能將碎片整理的效果限制在接收套接字上。為此，第一個片段用於使用第 4 層的擴充套件介面立即解析目標套接字。然後，此資訊與片段一起儲存在收集器資料結構中。其他片段照常通過其 IP 地址和 ID 進行標識。為了允許收集器的有效實現，傳入的片段必須以嚴格的升序到達，否則整個鏈都會被丟棄。當相關的套接字關閉時，不完整的鏈會被清除。收集器的總數是有限的，以便能夠指定查詢延遲的上限。
2.3 Driver Layer
網路介面卡 (NIC) 使用類似 Linux 的驅動程式介面連線到堆疊核心。這允許將標準 Linux 驅動程式直接移植到 RTnet，這已經在大約十個廣泛使用的 NIC 上執行。網路卡的初始化、配置和關閉仍然在 RTnet 下的非實時上下文中執行；移植標準驅動只需要在此處使用底層 RTOS 的適當同步機制。但是，必須特別注意時間關鍵的接收和傳輸路徑。必須對其進行稽核，以便在訪問硬體時檢測並避免潛在的長時間延遲。與標準驅動程式模型相比，需要一些擴充套件才能提供準確的時間戳服務。
RTnet 不依賴於 NIC 的內建時間戳時鐘，這些時鐘仍然不常用。相反，驅動程式必須提供儘可能精確的資料包接收和傳輸時間。這意味著必須在到達時呼叫的中斷處理程式開始時為每個資料包獲取接收時間戳。此外，驅動程式必須提供將當前時間儲存在傳出資料包中並自動觸發其傳輸的功能。這些措施廣泛地將資料包時間戳抖動降低為平臺和 RTOS 特有的單箇中斷抖動。
驅動層還提供了兩個用於重定向傳輸請求和 MTU（最大傳輸單元）查詢的每個裝置掛鉤。這兩個鉤子對驅動程式都是透明的。傳輸掛鉤被媒體訪問控制層 RTmac 和捕獲擴充套件 RTcap 分別用於管理分析傳出資料包。雖然標準網路堆疊通常只提供靜態裝置 MTU，但 RTnet 提供大小可變的邏輯通道，直至物理 MTU 到更高層。 RTmac 規程 TDMA 利用這些通道來強制執行特定的時隙大小（參見第 3.2 節）。
2.4 應用程式介面
應用程式可以通過廣泛符合 POSIX 標準的套接字和 I/O 介面連線到 RTnet 實時服務。套接字介面提供 UDP 和資料包套接字，用於確定性地交換使用者資料。 I/O 介面提供對諸如 TDMA（參見第 3.2 節）等服務向使用者輸出的附加功能的訪問，例如時鐘同步。與 RTAI 一樣，RTnet 允許 API 的經典核心模式和更方便的使用者模式使用（Linux 程式）。
相關的套接字和 I/O API 函式是稱為實時驅動程式模型 (RTDM) 的單獨介面概念的一部分。該介面解決了在 Linux/RTAI 等混合實時系統上訪問硬體時的特定要求，例如區分實時和非實時服務呼叫。目前，RTDM 的實現隨 RTnet 一起提供，但計劃將該功能合併到 RTAI 專案中。這也可以將 RTDM 用於 RTnet 之外的其他實時裝置驅動程式。
2.5 捕獲擴充套件
RTnet 核心的一個強大擴充套件是 RTcap 外掛。它充當實時 NIC 上傳入和傳出資料包的標準流量捕獲服務。到達的資料包與可靠的高精度時間戳一起被記錄，這完全取決於捕獲系統的中斷抖動。當安裝在活動的 RTnet 節點上時，RTcap 只會給時間關鍵的資料路徑增加少量的有限開銷。此外，它不會因 rtskbs 而餓死任何其他資料包使用者，因為它為捕獲的資料包維護單獨的緩衝池。
正常分析網路工具可以與 RTcap 一起使用，因為為每個實時 NIC 建立了一個偽只讀網路裝置來轉發捕獲的資料包。 特別是 Ethereal [5]，如圖 2 所示，非常適合剖析實時通訊，因為它完全理解 RTnet 協議。 但是，RTcap 與流量分析器結合使用當然不限於 RTnet 管理的網路或乙太網。 原則上，任何帶有支援 RTnet 的驅動程式的傳輸媒體都可以使用 RTcap 的高時間戳精度進行研究。
3 實時媒體訪問控制
與具有實時能力的堆疊實現同樣重要的是確定性通訊媒體。例如，迄今為止 RTnet 的主要媒體標準乙太網並沒有為硬實時應用程式提供足夠的服務質量 (QoS) 功能。基於集線器的乙太網段中不可預測的衝突阻止了較短的確定性傳輸時間。交換機可以克服這個問題，但會面臨導致資料包延遲或丟包的擁塞風險。符合 IEEE 802.1q 的啟用 QoS 的交換機在一定程度上改善了這種情況，但它們仍然需要集中佈線，這對於工業應用而言通常過於昂貴。
此外，其他共享通訊媒體可能需要對傳出流量進行額外控制，以便將 QoS 引數轉換為特定於媒體的方案或在必要時擴充套件現有的 QoS 特徵。 RTnet 通過其 RTmac 層解決了對確定性和靈活的媒體訪問控制 (MAC) 機制的需求，如下所述。此外，作為可插入 RTmac 介面的 MAC 規程的示例，提出了基於 TDMA 的協議。
3.1 可插拔 MAC 層
RTmac 是 RTnet 堆疊的可選擴充套件。儘管堆疊在沒有 RTmac 的情況下已經可以正常工作，但如果底層通訊媒體缺乏確定性訪問協議，它就成為強制性的。 RTmac 層旨在為任意基於軟體的 MAC 實現提供這四種基本服務，這裡稱為學科：
-
攔截關鍵的資料包輸出路徑並重定向到特定學科的處理程式。對於傳輸資料包，這是在資料包傳遞給 NIC 驅動程式之前執行的。此外，可以安裝一個處理程式來覆蓋每個資料包的裝置 MTU。
-
交換學科定義的控制或資料資訊
在任何使用者協議之外的 RTmac 框架中。 -
基於每臺裝置的紀律管理。到
每個實時 NIC 都可以在註冊到 RTmac 層時分配一個單獨的 MAC 規則。 -
非實時網路堆疊生成或接收的時間不關鍵資料的資料包隧道服務。該服務為每個 RTmac 管理的實時 NIC 建立一個虛擬網路裝置。隧道資料包由 RTmac 協議幀封裝，以區分其他方面相同的實時和非實時協議，如 UDP。
3.2 TDMA 學科
主要用於標準乙太網，RTnet 提供了一種基於時隙的 MAC 規則，稱為 TDMA（分時多重進接）。當前版本 2 中的 TDMA 是主從協議。它同步一個網段內的 RTnet 節點的時鐘。此外，它定義了任何有效負載資料包的傳輸時間，這些資料包與主機定期釋出的同步訊息相關。
一個 TDMA 從節點可以在任何時候加入一個正在執行的網段，只要它知道它的槽的至少一個引數集。該集合既可以靜態配置，也可以通過 RTcfg 協議分發（參見第 4 節）。
給定這些引數，從機通過向主機傳送校準請求開始加入。反過來，主站回覆一條包含請求到達和回覆離開時間的訊息，這兩個時間都與系統允許的一樣精確（另見第 2.3 節）。通過考慮其本地出發和到達時間，從站能夠計算資料包往返延遲。這個過程在一定的時間間隔內重複，以估計開始在主機上傳送資料包和在從機上獲得接收時間之間的中間時間 ttravel。
主裝置的同步訊息包含計劃的傳輸時間 Tsched 以及資料包釋放前的時間戳。這允許從裝置在計算本地和全域性系統時鐘之間的偏移量 tooffset 時補償主節點上的潛在排程抖動。從機可以進一步提高其自己的時隙開始時間Tslot的精度。
時隙可以在基本 TDMA 週期內自由安排，如圖 3 所示。除了節點分配和偏移之外，時隙大小也可以在傳輸介質的物理限制內定義。 TDMA 允許一個節點在每個週期使用多個時隙。此外，可以設定自定義的週期和時隙的相位以限制網路負載或在不同節點之間共享時隙。 Linux 下提供了一個管理工具，可以基於指令碼建立和維護單獨的配置。甚至在某些約束內進行執行時重新配置也是可行的。
如果多個資料包已在一個時隙上排隊，則傳輸順序由它們的優先順序定義，這些優先順序可由實時應用程式或 RTnet 服務為每條訊息設定。 有 31 個實時級別可用，第 32 個和最低的一個保留用於時間不關鍵的資料，即 VNIC 流量。 每個節點有多個時隙，就需要排程方案。 出於效率原因，TDMA 僅提供顯式排程。 每個節點上的插槽都被編號，預設的實時流量預定義 ID 0，非實時流量預定義 ID 1。 如果只有一個插槽可用，則 ID 1 對映到插槽 0。任何額外的插槽都保留用於通過套接字 API 顯式分配給任意實時應用程式。
由於 master 是單點故障，它的服務可以由一個或多個輔助 master 備份。必須為每個這樣的備份主機分配一個額外的時隙，標記為“Bck.圖 3 中的 Slot”。如果主 master 未能傳送同步訊息，時間軸上的下一個備用 master 將開始釋出自己的訊息。主要和次要主機之間的偏移量自動補償為每個同步幀中包含的預定傳輸時間和實際傳輸時間之間的較大差異。當主主控已修復並再次開始接管時，它首先在活動的備用主控上同步自己的時鐘，以避免明顯的時鐘偏差。之後它再次發出自己的同步訊息，並且備用主控切換到備用。
TDMA 規程為每個受控網路裝置建立一個 RTDM I/O 裝置。這些 I/O 裝置可用於檢索上面介紹的時鐘偏移，並在 TDMA 週期上同步實時任務。
4 實時配置服務
在第一個 TDMA 協議的修訂過程中，很明顯，一方面 RTmac 學科與通用配置以及另一方面的監控服務之間的明確分離對於 RTnet 的可擴充套件性至關重要。出於這個原因，實時配置服務 RTcfg 的設計方式與學科和媒體無關。鑑於支援廣播傳輸，它不依賴於特定的通訊媒體。支援 IPv4 協議，但不是強制性的。可以整合 IPv6 等其他網路協議，甚至可以純粹使用實體地址。
RTcfg的具體任務是：
-
向新加入的節點分發基本學科配置資料。該資訊是主動釋出的，從而使節點能夠在物理媒體和 RTmac 規則允許的範圍內即時加入實時網路。
-
監控活動節點並交換它們的物理和邏輯地址。例如，此服務可用於設定和維護第 2.2 節中提到的靜態 ARP 表。此外，還可以在 RTcfg 的介面之上構建實時網路監控工具。
-
實時網路啟動過程的同步。特定的 RTmac 學科或某些應用場景可能需要公共交匯點才能切換網路模式或同步啟動應用程式。
-
分發任意配置資料，即使在沒有 TCP/IP 的情況下也可以使用其通常使用的檔案傳輸協議（如 TFTP/FTP 等）。
RTcfg 基於客戶端-伺服器協議。中央配置伺服器將每個受管客戶端的引數集儲存在網段中。伺服器使用此資訊來不斷邀請任何已知但尚未活動的客戶端加入。如圖 4 所示，客戶端的啟動過程包括三個階段。第一階段在客戶端收到其單個初始引數包後完成，該初始引數包可通過物理或邏輯目標地址進行識別。這些引數通常包含設定可能的 RTmac 規程所需的最少資訊，例如至少一個 TDMA 時隙配置。
在完成學科初始化後的第二階段，客戶端向任何其他網路節點宣佈其存在，然後這些節點可以更新其地址資訊，如靜態 ARP 表。已經活躍的客戶通過向新節點傳送他們自己的標識來回復此公告。相比之下，伺服器通過傳輸可選的第二組配置資料進行回覆，該配置資料可以分散在多個資料包中。在伺服器從最後一個丟失的客戶端節點接收到最後階段 2 確認訊息之後，網路準備好進行潛在的公共操作模式切換，以防需要這種同步。
作為階段 3，為伺服器和客戶端提供可選的第二個集合點。 它可用於等待所有節點完成處理它們在階段 2 期間收到的配置資料。
設定完成後，可以指示客戶端向伺服器傳送低頻心跳幀，以跟蹤潛在的節點故障。 如果伺服器檢測到缺少心跳幀，它會通過向剩餘節點廣播相關訊息來宣佈客戶端死亡。 結果，所有節點將從其本地表中刪除損壞客戶端的任何地址。 這啟用了修復或替換節點的重新啟動過程。 即使在不同的系統上，失敗的 RTcfg 伺服器也可以重新啟動，而無需再次完成每個執行節點的完整啟動過程。
5 火線的整合
FireWire，也稱為 IEEE 1394 [8]，是一種用於連線異構裝置的高效能序列匯流排。雖然最初針對的是高速視訊傳輸等消費電子應用，但 FireWire 的許多特性使其非常適合工業和實驗室環境。在以下小節中，概述
給出了 FireWire 並描述了它整合到 RTnet 的當前狀態。
5.1 火線概述
FireWire 的匯流排拓撲結構是樹狀的，即具有分支和葉節點的非迴圈網路。物理介質支援 1394a 規範中高達 400 Mbps 的資料傳輸。在 1394b 規範中，速度甚至上升到 3.2 Gbps。 FireWire 支援兩種型別的資料事務：非同步和同步。
如圖 5 所示，同步和非同步事務的混合通過共享總匯流排頻寬來執行，其分配基於 125 μs 間隔，即所謂的 FireWire 週期。
同步事務以一個或多個節點為目標，與多播通道號相關聯。總共最多可以有 64 個通道。一旦為同步事務分配了匯流排頻寬，相關通道就可以在每 125 μs 週期內接收保證的時間片。每個匯流排週期的高達 80% (100 μs) 可以分配給同步通道。
因為這種事務型別不會重新傳輸損壞的資料包，而是以恆定的實時速率傳送資料，所以它非常適合分散式控制系統中的時間觸發狀態訊息傳輸。
在非同步事務階段，FireWire 上的整個網路表現為一個大的 64 位對映匯流排地址空間，每個節點佔用一個 48 位對映空間。地址的高 16 位用於標識節點 1。非同步事務分為兩個子事務：請求訪問另一個節點上的一段地址和響應。請求和響應之間的協調由事務確定。
層協議。由於通過確認提供有保證的資料傳遞，非同步事務針對非容錯應用程式，如分散式控制系統中的命令和控制訊息傳輸。
FireWire 上的匯流排管理包括可以分佈在一個或多個節點之間的不同職責：週期主控、同步資源管理器和匯流排管理器。 Cycle Master 在每個迴圈開始時廣播一條開始訊息。等時資源管理器負責匯流排頻寬和等時通道的分配。匯流排管理器具有多種功能，包括髮布匯流排速度圖和匯流排拓撲圖。由於火線連線的裝置可能不支援相同的最高資料傳輸速度，因此某個節點使用匯流排速度圖來確定它可以與另一個節點通訊的速度。終端使用者可以使用拓撲圖來優化匯流排拓撲以獲得最高吞吐量。
5.2 FireWire 堆疊和 RTnet 整合
FireWire 堆疊，如圖 6 所示，改編自 Linux 變體 [9]。 核心中的功能被解耦成幾個模組。 堆疊上的應用程式通過使用來自應用程式介面和管理層的原語獲取匯流排地址的一部分或一個或多個多播通道。
實時資料包管理的 RTnet 機制也適用於 FireWire 堆疊。 NIC 驅動程式和高階應用程式都是資料包的潛在生產者和消費者。 所有資料包都由通用資料包緩衝區結構 rtpkb 承載。 與 RTnet 一樣，rtpkb 的預分配是在設定期間完成的，每個 rtpkb 承載固定大小的有效載荷，足以滿足各種場景。
這裡，我們只講點對點的非同步事務。 在 1394a 補充中，也定義了非同步事務中的多播資料包。
將傳入的資料包傳遞到應用層的路徑是由一個實時任務實現的，即所謂的 tasklet 伺服器。當一個新的資料包到達時，一個合適的處理程式，無論是非同步的還是同步的，都作為一個小任務連線到伺服器。伺服器按照 First In First Served (FIFS) 規則工作，這意味著資料包按照到達時間的順序進行處理。當沒有 tasklet 排隊時，伺服器保持空閒狀態，直到下一個資料包到達。 RTOS 訊號量用於伺服器和小任務佇列之間的同步。與 RTnet 中的堆疊管理器一樣，伺服器執行的優先順序高於應用程式任務。
FireWire 堆疊和 RTnet 核心之間的連線是通過乙太網模擬實現的。模擬是應用層的一個模組，使用一部分匯流排地址來使用協議將火線資料包轉換為乙太網資料包，反之亦然。通過使用乙太網模擬，FireWire 的功能與 RTnet 中的其他實時乙太網裝置相同。
6 應用協議和框架
在考慮應用協議層時，RTnet 通過廣泛標準化的 API 提供實時通訊服務，而不是通過專門的、僅面向現場匯流排的介面提供實時通訊服務的優勢變得顯而易見。本節介紹其中的一些，並提出一個示例概念，用於在 RTnet 上對映現有的現場匯流排中介軟體 CANopen服務。
6.1 netRPC——遠端實時過程呼叫
RTnet 的首批使用者之一是其主要的實時執行平臺本身。 RTAI（3.x 系列）[17] 帶有一個名為 netRPC 的外掛，它支援分散式使用其 RTOS 服務。此遠端過程呼叫服務 (RPC) 建立在 UDP/IP 協議之上。它可以連線到 Linux 非實時網路堆疊，通常用於測試和演示目的，也可以連線到 RTnet API。在後一種情況下，幾乎透明地向 RTAI 應用程式提供分散式硬實時。一些 RTAI 開發人員在他們的實時多體動力學分析軟體 MBDyn [13] 中利用了這一特性。
6.2 RTPS 協議
實時釋出-訂閱協議 (RTPS) [14] 的開發是為了在乙太網等不可靠的 IP 網路上提供實時通訊服務。
該協議包含檢測關鍵資料包延遲或丟失的機制，並通過使用 UDP 作為傳輸協議來避免不確定的重傳，例如 TCP 原因。為了保持乙太網上的實時通訊正常執行，RTPS 段中只能接受較低的網路負載。 RTPS 可作為商業產品 (NDDS) 使用，幷包含在各種工業產品中，例如某些施耐德 PLC。
此外，還可以使用稱為 ORTE [2] 的 RTPS 開源實現。 ORTE 通過傳統的 UDP/IP 堆疊在大量平臺上執行，此外，還支援 RTAI 之上的 RTnet。通過利用 RTnet 的硬實時 UDP/IP 服務，即使在高非實時網路負載下也可以使用 RTPS，因為 RTnet 可靠地將這種流量與時間關鍵資料分開。
6.3 實時控制框架
對於研究和工業場景，越來越複雜的控制任務需要強大的框架來促進分散式實時系統的開發。
漢諾威的 RealTime Systems Group 開發了其中一個框架，重點是機器人研究 [20]。該框架透明地支援通過 RTnet (UDP/IP) 確定性地支援分散式應用程式，並且通過標準 TCP/IP 沒有時間保證。它的通訊模型包括遠端過程呼叫以及生產者-消費者方案。
一個類似的框架 OROCOS 也利用 RTnet 進行閉環控制 [15]。此外，OROCOS 和相關的 OCEAN 專案計劃在 RTnet 上執行 RTCORBA。後一個專案已經評估了早期版本的 RTnet，並得出結論，將其作為可插入協議整合到 RT-CORBA 實現 ACE/TAO 是一種很有前途的方法 [19]。
6.4 CANopen
CAN in Automation 組織開發了 CANopen 作為自動化領域的應用協議和裝置模型 [1]。除了最初用於 CAN 現場匯流排之外，CANopen 最近還被兩種商業實時乙太網解決方案 ETHERNET Powerlink [3] 和 EtherCAT [4] 採用。在節點定址、訊息優先順序或通訊模型方面，這兩種方法以及 RTnet 都與 CAN 匯流排有很大不同。因此，ETHERNET Powerlink 和 Ethercat 只重用 CANopen 指定的裝置配置檔案。下面簡要分析將CANopen引入RTnet的可行性和潛力。這樣的擴充套件將使軟 PLC 等經典自動化應用程式能夠更直接地在 RTnet 上執行。
由於 CAN 本身與訊息源和目標地址無關，因此 CANopen 將常見的三種定址模式廣播、單播和多播對映到 CAN 訊息識別符號上。廣播訊息用於網路管理、同步、時間戳和報警目的。 CANopen 交換所謂的服務資料物件 (SDO)，以作為單播訊息在兩個節點之間進行時間不嚴格的直接通訊。
承載實時資料的過程資料物件根據多播方案以單個生產者和任意數量的消費者進行傳輸。 RTnet 通過 UDP 和使用者定義的乙太網協議支援廣播和單播。
由於多播支援還不是 RTnet 的一部分，因此此類訊息可以通過單播（以防僅存在一個消費者）或使用接收節點上的附加軟體過濾器作為廣播的方式臨時釋出。基本上，需要對通訊物件 ID (COB-ID) 格式進行擴充套件，該格式最初在定義時僅考慮了 CAN ID。雖然 CAN 根據 ID 隱含地對訊息進行優先順序排序，但現在需要一個顯式值，該值也對 RTnet 上的輸出通道進行編碼。擴充套件的 COB-ID 將需要以下欄位：
- ID 型別（UDP/IPv4、UDP/IPv6、乙太網、CAN 等）
- 目標節點地址（IP、乙太網 MAC 等）
- 訊息 ID（UDP 目標埠、乙太網幀型別、CAN ID 等）
- 優先順序和通道（RTmac 排隊優先順序、TDMA 時隙等）
消費者使用 CAN 特定的遠端傳輸請求 (RTR) 向生產者請求 PDO。可以通過向生產者傳送具有相同 COB-ID 的空 PDO 來模擬此協議。基於提出的定址方案，典型的 CANopen 堆疊，例如各種免費實現 [6] 之一，可能已經在 RTnet 之上重用。某些 CANopen 服務可以直接對映到 RTnet 等價物上。 RTcfg 提供心跳機制，可以替代 CANopen 的變體。 TDMA 帶有一個 API，用於同步節點並分發公共時間基準，這些服務用於代替 CANopen 協議。其他優化潛力在於交換 SDO 時更大的傳輸片段。 CANopen 對 CAN 相關 8 位元組的限制可以通過定義新的、特定於 COB-ID 的 SDO 上傳和下載協議來輕鬆克服，這些協議使用不同的最大資料包大小（例如，通過 UDP/IP 大約 64 KB）。
7 總結與展望
本文介紹了 RTnet 作為一種可適應和可擴充套件的框架，用於通過標準乙太網、FireWire 或其他合適的媒體進行確定性通訊。其開放的、面向標準的、模組化的結構允許眾多應用場景，如分散式實時系統、現場匯流排耦合裝置、智慧 I/O 介面、低成本實時網路分析儀等。應用軟體可以直接與RTnet API 或 RTPS 或 CANopen 等中介軟體可以構建在 RTnet 的服務之上。
未來的工作將集中在 FireWire、千兆乙太網等新媒體的進一步整合以及與其他中介軟體的互操作上。為了解耦組織依賴關係，RT-FireWire 堆疊最近已成為一個單獨的專案。基於通過乙太網模擬與 RTnet 的連線，現在將解決採用 FireWire 的事務模式和 RTnet 服務的時鐘同步問題。此外，還將分析在 RTnet 上分層 CANopen 的潛力，並可能導致擴充套件 CANopen 堆疊的實施。
當前的 RTnet 實現是基於自由軟體構建的，它與許多開源專案緊密互動，因此也可以在開源許可下使用。如需下載和更多資訊，請訪問
8 rtnetproxy
RTnetproxy 可用於為實時和非實時乙太網流量共享單個網路介面卡。
TCP/IP、UDP 和 ARP 可以通過 RTnet 使用（當然不是實時的！）
RTnetproxy 代表標準 Linux 的網路裝置，可以作為任何其他 Linux 網路裝置使用（ifconfig 用於配置），網路裝置的名稱為“rtproxy”。
1.設定：
首先讓您的 RTnet 正常工作！您感興趣的所有 IP 地址都必須通過“rtifconfig ethX route solicit IP_ADDRESS”設定！
insmod rtnetproxy.ko
使用ifconfig配置此網路裝置：
例子：
ifconfig rtproxy up 192.168.10.10 netmask 255.255.255.0
2.模組配置選項：
--enable-proxy：啟用 RTnetproxy 支援，預設情況下僅限於基於 IP 的協議（TCP/IP ！！！）。
來自 ICMP 的傳入幀由 RTnet 直接解釋，不會轉發到 RTnetproxy。如果 RTnet 應用程式沒有請求 UDP 資料包，則它們會被轉發。
--enable-proxy-arp：此選項啟用對 rtproxy Linux 網路裝置的 ARP 支援。傳入的 ARP 回覆被傳送到 RTnet 和 Linux 網路堆疊。 然後 rtproxy 會連線到相應的 RTnet 裝置，預設情況下是 rteth0。
--disable-icmp：此選項禁用 RTnet IPv4 ICMP 支援。然後 ICMP 將由 Linux 網路堆疊通過 rtproxy Linux 網路裝置處理。
3.重要的提示：
強烈建議嚴格區分實時 LAN 流量和非實時 LAN 流量。對於配置/設定階段，TCP/IP 有時非常有用，用於實時資料交換的 buf 應為使用 UDP 的實時流量保留 LAN！
4.內部如何運作：
RTnetproxy 在 RTnet 之上工作。
所有要傳送或接收的資料實際上都是在 RTnet 和 RTnetproxy 之間複製的 => 效能不如標準 Linux 網路驅動程式。
所有傳入的 IPv4 幀（具有 RTnet 未處理的 IP 協議 ID）都將傳遞給 RTnetproxy。
傳遞給 RTnetproxy（TCP 幀）的傳入幀會稍微減慢實時資料的速度——因為所有這些都是在實時模式上下文中完成的！
4.可能的增強功能：
將傳入幀傳遞給 RTnetproxy 不僅要檢查協議 ID，還要通過實際檢查，確定某個幀是否已被 RTnet 處理。
這導致 RTnet 實現發生了一些變化......
9 RTMAC
RTmac 是一個設計用於與 RTnet 一起使用的模組。 它為 RTnet 提供媒體訪問控制 (MAC) 基礎設施。 實際的訪問控制機制是由所謂的學科模組實現的。 當前版本帶有分時多重進接 (TDMA) 規則。 由於 RTmac 的模組化設計，您還可以輕鬆附加針對特定應用優化的自己的 MAC 規程。
Without RTmac:
+---------------+
|RT applications|
+-------v-------+
|
+--------v---------+
| RT UDP/IP stack |
+------------------+
|RT ethernet driver|
+--------v---------+
|
+----v---+
| NIC |
+--------+
With RTmac inserted:
+---------------+ +-------------------+
|RT applications| | Linux network |
+-------v-------+ |stack (TCP/IP etc.)|
| +---------v---------+
+--------v---------+ |
| RT UDP/IP stack | +--v--+
+------------------+ |VNIC |
| RTmac | +--v--+
| Layer | |
| .--------------. <------------+
| |MAC algorithm | |
| `--------------´ |
+------------------+
|RT ethernet driver|
+--------v---------+
|
+----v---+
| NIC |
+--------+
RTmac，如果載入，則對網路驅動程式的傳輸具有獨佔控制權。 每個傳出資料包都被傳遞給 RTmac，RTmac 將其轉發給 MAC 規則。 然後它將決定何時可以將資料包傳送到硬體驅動程式。
TDMA - 分時多重進接
TDMA 媒體訪問控制規則基於主/從層次結構。網路主機週期性地釋出所謂的同步幀，形成基本迴圈。包括主站在內的網路參與者在這些週期內專門分配了訪問視窗（時隙），相對於同步幀定義。為了捕捉中央主機的潛在故障，可以設定額外的備用主機，以在主要主機失敗的情況下接管傳送同步幀。
一個時隙可用於傳輸最大指定最大大小的單個資料包。此規則修訂版支援將時隙靈活分配給實時網路參與者。每個週期可以使用多個插槽。此外，參與者之間可以共享一個時隙，只需每第 N 個週期佔用一個時隙。除了每個參與者至少一個有效載荷槽外，還必須為同步幀保留槽，並且可選地，為一個或多個備份同步幀保留槽。具體時間在很大程度上取決於所有網路參與者的能力。因此，最壞情況抖動或最小時隙間隙等時序要求不是靜態指定的，它們可以為每個專案單獨定義。
與早期的 TDMA 規則修訂相比，從配置不再由 TDMA 主分配。這意味著從裝置在將任何資料傳送到 TDMA 管理的網路之前必須知道它們的插槽設定。因此，必須將所需的設定儲存在從站上，或者，如果需要集中管理，則必須使用 RTnet 配置服務 RTcfg（有關詳細資訊，請參閱相關文件）。
插槽識別和選擇
時隙帶有一個內部 ID 號，每個參與者都是唯一的。 這些數字用於確定應傳送傳出資料包的時隙。 TDMA 規程不包含自動排程機制。 相反，傳送者，即使用者或服務，要麼明確提供所需的插槽 ID，要麼使用預設插槽。
槽位號 | 描述
---------+---------------------------------------- -------------------------
0 | RT的預設槽； 如果插槽 1 缺失，也是預設的 NRT 插槽
1 | 非RT槽； 如果缺少，則使用插槽 0
2 | 使用者槽，用於顯式排程的資料包
: |
配置檔案
為了簡化基於 TDMA 的網路的設定，RTnet 發行版提供了 rtnet 啟動指令碼。它由通常名為 rtnet.conf 並儲存在 /etc 中的配置檔案控制。通過在此檔案中設定 TDMA_MODE，站的角色設定為“主”或“從”。
除了這個通用引數之外，啟動指令碼還支援 TDMA 的兩種配置模式。在簡單模式下，只需要在 TDMA_SLAVES 中列出所有從機的 IP，在 TDMA_CYCLE 中必須提供迴圈週期，並且必須在 TDMA_OFFSET 中指定槽偏移差。然後為每個站分配一個 ID 為 0 的時隙，從主節點的偏移量 0 開始，即主節點的有效負載幀將直接跟隨同步幀。進一步的偏移量是通過為每個進一步的站將先前的值增加 TDMA_OFFSET 來計算的。
相反，擴充套件模式允許對每個節點進行詳細配置。要啟用此模式，需要一個 TDMA 配置檔案（通常是 /etc/tdma.conf）。該檔案的路徑必須在變數 TDMA_CONFIG 中提供給 rtnet.conf，同時必須禁用 TDMA_SLAVES、TDMA_CYCLE 和 TDMA_OFFSET，例如通過註釋掉。除了與 TDMA 相關的引數外，還可以為每個從節點設定單獨的 stage-2 檔案，覆蓋 rtnet.conf 中的公共 STAGE_2_SRC 變數（有關配置概念的詳細資訊，請參閱 RTcfg 文件）。 TDMA配置檔案的格式定義如下：
參考
[1] CiA. CANopen, Application Layer and CommunicationProfile. CAN in Automation, Feb. 2002.
[2] O. Dolejs, P. Smolik, and Z. Hanzalek. On the Ethernet use for real-time publish-subscribe based applications. In 5th IEEE International Workshop on Factory Communication Systems, Vienna, Austria, Sep. 2004.
[3] ETHERNET Powerlink Standardization Group.www.ethernet-powerlink.org.
[4] EtherCAT Technology Group. www.ethercat.org.
[5] Ethereal. www.ethereal.com.
[6] CANopen free software resource center. canopen.sourceforge.net.
[7] F. T. Y. Hanssen and P. G. Jansen. Real-time communication protocols: an overview. Technical Report TR-CTIT03-49, Centre for Telematics and Information Technology,Univ. of Twente, The Netherlands, Oct. 2003.
[8] IEEE. IEEE standard for a high performance serial bus, Std 1394-1995 and amendments, 2002.
[9] IEEE 1394 for Linux. www.linux1394.org.
[10] LinuxDevices.com. Lineo announces GPL real-time networking for Linux: RTnet. www.linuxdevices.com/news/NS4023517008.html, July 2000.
[11] J. Loeser and H. Haertig. Low-latency hard real-time communication over switched Ethernet. In 16th Euromicro Conference on Real-Time Systems, Catania, Italy, 2004.
[12] J. Mart´ınez, M. Harbour, and G. J.J. A multipoint communication protocol based on Ethernet for analyzable distributed real-time applications. In 2nd InternationalWorkshop on Real-Time LANs in the Internet Age, 2003.
[13] Multibody dynamics analysis software on real time distributed systems. www.aero.polimi.it/mbdyn/mbdyn-rt.
[14] Real-Time Innovations, Inc. Real-Time Publish-Subscribe Wire Protocol Specification, Protocol Version 1.0, Draft Document Version 1.17, 2002.
[15] Open Robot Control Software. www.orocos.org.
[16] P. Pedreiras, L. Almeida, and P. Gai. The FTT-Ethernet protocol: Merging flexibility, timeliness and efficiency. In 14th Euromicro Conference on Real-Time Systems, 2002.
[17] Real Time Application Interface. www.rtai.org.
[18] J. Schwager. Real-time Ethernet in industry automation.www.realtime-ethernet.de.
[19] M. Wild et al. OCEAN deliverable D2.1: Design of the DCRF lower layers including hardware requirements.www.fidia.it/download/ricerca/ocean/deliverable21.pdf, 2003.
[20] O. Wulf, J. Kiszka, and B. Wagner. A compact software framework for distributed real-time computing. In 5th Real-Time Linux Workshop, Valencia, Spain, Nov. 2003.