本文介绍了开源项目 RTnet。RTnet 为以太网和其他传输媒体上的硬实时通信提供了一个可定制和可扩展的框架。 本文描述了 RTnet 的架构、核心组件和协议。
目录- RTnet – 灵活的硬实时网络框架
- 0 摘要
- 1 介绍
- 2 基础服务
- 2.1 数据包管理
- 2.2 UDP/IP 实现
- 2.3 Driver Layer
- 2.4 应用程序接口
- 2.5 捕获扩展
- 3 实时媒体访问控制
- 3.1 可插拔 MAC 层
- 3.2 TDMA 学科
- 4 实时配置服务
- 5 火线的整合
- 5.1 火线概述
- 5.2 FireWire 堆栈和 RTnet 集成
- 6 应用协议和框架
- 6.1 netRPC——远程实时过程调用
- 6.2 RTPS 协议
- 6.3 实时控制框架
- 6.4 CANopen
- 7 总结与展望
- 8 rtnetproxy
- 1.设置：
- 2.模块配置选项：
- 3.重要的提示：
- 4.内部如何运作：
- 4.可能的增强功能：
- 9 RTMAC
- TDMA - 时分多址
- 插槽识别和选择
- 配置文件
- 参考
翻译原文：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。
主要用于标准以太网，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 的当前状态。
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 CANopenCAN 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 rtnetproxyRTnetproxy 可用于为实时和非实时以太网流量共享单个网络适配器。
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
--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 网络设备处理。
强烈建议严格区分实时 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 实现发生了一些变化......
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.