【机翻】RTnet – 灵活的硬实时网络框架

翻译原文：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的体系结构、核心组件和协议，并介绍了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节描述了RTnet基础服务，包括堆栈核心、驱动程序接口、可用的传输协议（如实时UDP/IP实现）、提供给管理工具和实时应用程序的编程接口以及数据包捕获扩展RTcap。第3节介绍了确定性媒体访问控制框架RTmac，包括其用于时间非关键流量的隧道网络设备（VNIC），并详细介绍了RTnet用于Ethernet的默认访问控制纪律TDMA。最后，第4节通过介绍实时配置服务RTcfg来结束堆栈概述。到目前为止，RTnet的实现重点集中在Ethernet上。第5节介绍了将实时IEEE 1394（FireWire）支持添加到框架中的概念和最新进展，并指出该媒体类型的优点和在自动化领域中可能的应用。此外，在第6节中介绍了在RTnet上工作的可用和未来的应用程序协议和完整功能的中间件。

2 基础服务

RTnet包含一组中央服务，这些服务对于大多数场景都是必需的。在下面，将介绍这些服务。

2.1 包管理

RTnet的关键部分之一涉及包的管理，这些包包含传入和传出的数据。要传输的数据包在发送任务的上下文中（即实时应用程序或内部RTnet服务）经过堆栈，而传入的数据包则首先从网络控制器驱动程序传递到所谓的堆栈管理器。这个实时任务根据协议类型将数据包进行分解，通过将它们传递给各自的处理程序。堆栈管理器的优先级必须高于使用RTnet服务的所有应用程序，以避免优先级反转。这个概念类似于大多数操作系统中的底半部中断处理。

堆栈和驱动程序使用一个称为rtskb（源自Linux sk buff结构）的统一数据结构来处理数据包缓冲区。传统的网络堆栈动态分配这样的缓冲区和管理结构，但由于实时需求，RTnet必须使用不同的方案。首先，在设置期间预先分配所有rtskbs。由于RTnet目前不支持多个用户之间的缓冲区共享，管理结构和负载缓冲区形成单个内存片段。其次，**每个rtskb都有一个固定大小，始终可以携带最大的物理包****。这种限制是必要的，以避免由于内存片段化而导致的短缺，并允许在用户之间交换任意rtskb。
RTnet内的包生成和消费者必须创建一组rtskb池以参与通信。在运行时，这些池中分配新的rtskb。rtskb对其原始池的引用允许在释放时将其返回给其所有者。当包生成者将rtskb交给目标消费者时，只有在消费者能够从自己的池中提供免费的补偿rtskb时，所有权才会改变。否则，数据包将被丢弃，相关缓冲区可以立即重新使用。

典型的生产者和消费者是适配器驱动程序和套接字。但是，VNIC或像RTcfg和ICMP这样的管理协议也提供了自己的池。池是在非实时上下文中使用底层操作系统的不确定性内存分配服务创建或调整大小的。为了允许在实时上下文中创建套接字并扩展池，所需的rtskb在这种情况下从初始堆栈期间创建的特殊全局预分配缓冲区池中转移。

2.2 UDP/IP 实现

与标准UDP/IP堆栈相比，需要进行几项修改才能创建包含在RTnet中的确定性变体。首先，动态地址解析协议（ARP）被转换为在设置期间执行的静态机制。如果以后目标地址未知，则不会发出解析请求，而是向调用者返回传输错误。否则，数据包的最坏传输延迟将包括潜在地址解析的延迟。其次，路由过程被简化。输出路由表已经优化用于RTnet使用的有限条目数量。为了加速数据包的设置，这些表还包括ARP结果，即目标硬件地址。
IP 数据包的重组需要特别注意。在传统的网络堆栈中，此任务在任何更高的层如UDP之前由IP层执行。因此，由于实际的接收器尚未确定，全局rtskb池需要用于缓冲所有片段，直到最后一个片段到达。向现有链添加新片段需要在所有当前待处理的IP数据包链的全局列表中进行查找。此外，必须在超时后清除不完整的链以避免缓冲区短缺并保持全局IP片段列表小。
RTnet的UDP/IP堆栈包含几种机制，将重组的影响尽可能局限于接收套接字。为此，第一个片段用于立即通过扩展到第4层的接口解析目标套接字。然后，该信息与片段一起存储在收集器数据结构中。其他片段通常由其IP地址和ID标识。为实现收集器的高效实现，传入片段必须按严格升序到达，否则整个链将被丢弃。在相关套接字关闭时清除不完整的链。为了能够指定查找延迟的上限，收集器的总数是有限的。

2.3 驱动程序层

网络接口卡（NIC）使用类似Linux的驱动程序接口连接到堆栈核心。这使得标准的Linux驱动程序可以直接移植到RT-net上，并且已经为大约十个广泛使用的NIC执行了此操作。NIC的初始化、配置和关闭仍在RT-net下的非实时上下文中执行；移植标准驱动程序只需要在此处使用适当的底层RTOS同步机制。不过，需要特别关注时间关键的接收和传输路径。必须进行审计，以便检测和避免访问硬件时潜在的长时间延迟。

与标准的驱动程序模型相比，需要进行少量扩展以提供精确的时间戳服务。RT-net不依赖于NIC的内置时间戳时钟，这仍然很少见。取而代之的是，驱动程序必须尽可能精确地提供数据包的接收和传输时间。这意味着，必须在到达时调用的中断处理程序的开头为每个数据包获取接收时间戳。此外，驱动程序还必须提供在传出数据包中存储当前时间并以原子方式触发其传输的功能。这些措施可以显著减少数据包时间戳的抖动，使其仅受到特定平台和RTOS特征的单个中断抖动的影响。

驱动程序层还为每个设备提供了两个挂钩，用于重定向传输请求和MTU（最大传输单元）查询。这两个挂钩对驱动程序是透明的。传输挂钩由媒体访问控制层RTmac和扩展RTcap使用，分别用于管理和分析传出数据包。尽管标准的网络堆栈通常仅提供静态设备MTU，但RT-net提供了可变大小的逻辑通道，最多可达物理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 实时媒体访问控制

与实时能力堆栈实现同样重要的是确定性通信介质。例如，标准以太网目前是RT-net的主要媒体，但不为硬实时应用程序提供足够的服务质量（QoS）功能。基于集线器的以太网段中难以预测的冲突会阻止短的确定性传输时间。交换机可以解决这个问题，但会面临拥塞风险，导致数据包延迟或丢失。IEEE 802.1q协议支持的具有QoS功能的交换机在一定程度上改善了这种情况，但它们仍需要集中布线，这在工业应用中通常过于昂贵。

其他共享通信媒体也可能要求对出站流量进行额外控制，以便将QoS参数转换为特定于媒体的方案或在必要时扩展现有的QoS功能。 RTnet通过其RTmac层来满足对确定性和灵活的媒体访问控制（MAC）机制的需求，如下所述。此外，本文还介绍了一个可插入RTmac接口的MAC纪律示例，即基于TDMA的协议。

3.1 可插拔 MAC 层

RTmac是RTnet堆栈的可选扩展。虽然在没有RTmac的情况下堆栈已经具有功能，但如果底层通信媒体缺乏确定性访问协议，则RTmac变得必不可少。 RTmac层旨在为任意基于软件的MAC实现（在此称为纪律）提供这四个基本服务：

拦截关键数据包输出路径并重定向到特定于纪律处理程序的处理器。对于传输数据包，这是在将数据包传递给NIC驱动程序之前执行的。此外，可以安装一个处理程序以每个数据包为基础覆盖设备MTU。
在任何用户协议之外交换由纪律定义的控制或数据消息的RTmac帧。
每设备基础上的Discipline管理。针对每个实时NIC，可以在其注册到RTmac层时分配一个单独的MAC Discipline。
非实时网络堆栈生成或接收的时间非关键数据包的数据包隧道服务。此服务为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.

posted @ 2022-04-26 21:30 沐多阅读(1837) 评论(0) 编辑收藏举报

刷新页面返回顶部