翻譯原文：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 [email protected], [email protected]

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，要麼使用默認插槽。

配置文件

爲了簡化基於 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.

【機翻】RTnet – 靈活的硬實時網絡框架