DDS和TSN:实时数据交换的未来?

本文探讨了DDS(数据分发服务)和TSN(时间敏感网络)如何协同工作,以满足实时系统的需求。TSN通过以太网提供确定性的数据传输,而DDS则提供高级别的QoS策略和应用集成。两者结合可以简化复杂性,降低成本,并确保实时服务质量。目前,OMG正在为带有TSN的DDS开发新标准,这将促进硬实时应用的标准化和互操作性。

在这里插入图片描述

最近,我的一位同事参加了在奥地利林茨开普勒大学的座谈会,发生了一件有趣的事情。尽管时间敏感型网络(TSN)是一个相对较新的标准,但他仍然惊讶于有关TSN和数据分发服务™(DDS)如何一起工作的问题而感到惊讶。这告诉了我们一些事情:许多系统架构师似乎已经相信,TSN在未来的系统设计中将扮演越来越重要的角色。

TSN是一组IEEE标准,旨在通过以太网提供对时间敏感的数据传输。TSN非常适合需要以确定性方式发送周期性信息的实时系统的通信要求。

但是,TSN可能会做更多的事情。原因很简单:TSN可以为以前无法在以太网上运行的全新应用程序提供实时通信的基础。因此,这些应用程序可以使用效率,带宽和性能改进的新领域。

但是,当然,没有什么是凭空运作的:TSN是一种低层网络技术(第1层和第2层),需要与更高层的网络和连接技术(第3-6层)结合才能发挥其全部潜力。在我看来,DDS是实现这一目标的最佳方法。例如,当DDS位于堆栈中的TSN上方时,突然之间,您可以通过简单地配置应用程序级QoS并使用DDS进行发布-订阅通信来使用实时服务质量(QoS)。这将确定性直接带给Edge Autonomy应用程序,而无需配置网络交换机或执行自定义编程。

最适合实时性需求

那么,为什么DDS和TSN天生适合?关键原因在于,将它们结合使用时,它们可以使用商业上可用的标准技术集成实时应用程序组件。这是一个明显的优势,因为定制或专用技术的制造成本往往很高且难以维护。随着技术的发展,自定义技术将无法跟上并最终成为孤岛,无法与新系统和技术集成。网络技术的演进提供了一个示例:早期,有数百种彼此不互操作的网络技术。随着时间的流逝,所有这些技术都被整合为各种以太网标准(用于第1层和第2层)和TCP / IP(用于第3层和第4层)。其他技术成为孤立的孤岛,无法从Internet的技术进步中受益。

如今,Internet应用程序使用高级(第5层和第6层)中间件和“连接框架”技术(例如MQTT,DDS,OPC-UA,HTTP / REST等)进行集成。这些中间件技术将应用程序与细节隔离开来。网络化,并使其能够构建强大的分布式系统,并且可以随着时间的推移而发展。它们促进了数据模型的创建和共享,并为简化了应用程序开发的通信模式(例如发布-订阅和远程服务调用)提供了支持。

但是,由于中间件和网络技术无法提供应用程序所需的性能和/或确定性(例如,有限的延迟和抖动),因此许多硬实时系统无法利用这些优势。因此,他们被迫使用专用解决方案,包括专用的“工业协议”和定制的网络硬件。

DDS和TSN的组合可以改变这种情况。为了理解这一点,让我们剖析每种技术提供的功能以及它们如何协同工作。

TSN提供了一项出色的技术,可以通过以太网传递实时流量。它允许定义每个流的时序要求,并配置网络路径(包括交换机)以确保满足要求。它还为不同的流提供隔离,因此实时流量不会受到同一网络上发生的其他通信的干扰。但是,由于该技术在配置堆栈中处于较低级别,因此应用程序必须配置流,数据包大小,频率,优先级,网络端点等。尽管可以为几个节点和流的简单应用程序完成此操作,但对于更复杂的系统却变得很棘手。

DDS提供了一项出色的技术,可以集成由单独的组件构建的应用程序。它离应用程序更近。它在主题,应用程序数据类型,与应用程序相关的QoS(例如,可靠性,持久性,优先级,截止日期)方面提供了更高级别的界面,并处理了诸如发现端点和建立通信之类的较低级别的细节。路径。但是,尽管DDS尝试通过使用有效的二进制协议来尽力而为,但它不能保证确定性的行为,因为它不控制底层网络层:它必须与基础网络(例如UDP / IP)可以提供的内容兼容。

DDS和TSN的结合提供了两全其美的方法。

增强QoS策略

实时系统的关键是QoS的整个概念。结合DDS和TSN,可以在分布式系统中指定和实施与应用程序相关的QoS。这使系统管理员可以指定诸如哪些流需要可靠,延迟预算,期限,耐用性要求,数据寿命等方面的信息。DDS可以使用此信息自动配置TSN网络,从而可以保证QoS。

将DDS与TSN结合使用还可以通过DDS中的QoS功能节省时间。除了配置与应用程序相关的DDS QoS外,该应用程序无需做其他事情。自动配置下层TSN概念的繁琐细节,因此大大简化了应用程序集成和部署。

降低复杂度

TSN的原始驱动程序是音频和视频社区,因为那些系统发送需要精确协调的高带宽信号。例如,发送到多个扬声器的信号需要精确同步,以使听众获得正确的声音感知。随着这种趋势的发展,许多其他行业指出它们也面临着类似的挑战。多轴控制机器,机器人,3D打印和汽车都是很好的例子,因为它们涉及在多个端点发生的协调动作。

因此,所有流量都可以共享一个实时TSN,而不是使用多个网络和多个线路。这在复杂性和硬件方面提供了显着的节省。它还可以保证设计的前瞻性:只需将新组件插入公共TSN网络即可添加新组件。

DDS在应用程序层也解决了该问题。应用程序流程和组件也可以“插入”通用DDS数据总线。除了改善分布式系统的互操作性,带宽和性能外,您将不会受制于看起来像1950年代电话总机的系统架构。

结论

显然需要DDS和TSN可以一起完成。当前,甚至有一个建议,对象管理小组(OMG)为带有TSN的DDS开发新的标准,有望在2020年成为OMG标准。

使用标准技术和中间件集成硬实时应用程序的能力可能是革命性的。这将使跨商业技术提供商生态系统开发通用工具链。这将降低成本,并大大简化应用程序开发人员和系统集成商的职责。此外,这将确保生成的系统不会孤立,并保留轻松整合未来技术优势的能力。

本文转自微信公众号【DDS论坛】


译文连载

RTPS规范-译文连载:实时发布订阅协议(RTPS)DDS互操作网络协议规范-中文翻译_001
DDS规范-译文连载:DDS (Data Distribution Service) 数据分发服务-规范中文翻译_001

相关链接

DDS科普:一文读懂DDS(数据分发服务)
DDS定义:什么是DDS?

在这里插入图片描述

<think>嗯,用户现在问的是AGV控制器软件架构,采用ROS2CODESYS的优缺点,需要详细比较。首先,我需要回忆一下这两个框架的基本信息它们在工业自动化中的应用场景。 ROS2,机器人操作系统2,是一个开源的机器人中间件,主要用于机器人软件开发,提供通信、工具库的支持。它支持分布式计算,适合需要复杂算法多传感器融合的场景,比如自动驾驶移动机器人。而CODESYS是一个工业自动化领域的开发环境,常用于PLC编程,强调实时性、可靠性标准化,适合工业控制系统的硬实时需求。 接下来,用户可能是在设计AGV的控制系统,需要选择软件架构。他们可能关心实时性、开发效率、生态系统、硬件支持、维护成本等方面。需要比较这两个框架在这些方面的优劣。 首先比较实时性。CODESYS基于IEC 61131-3标准,支持硬实时任务,这对于需要精确控制电机、紧急停止等关键功能的AGV来说非常重要。而ROS2虽然通过实时中间件(如Cyclone DDS实时操作系统(如RT Linux)可以实现软实时,但硬实时支持有限,可能存在抖动问题。这点可能是CODESYS的优势,尤其是在高精度控制的场景下。 然后是开发灵活性。ROS2使用现代编程语言如C++Python,支持分布式节点,模块化设计,适合快速原型开发复杂算法集成。CODESYS主要使用结构化文本(ST)、梯形图(LD)等工业标准语言,更适合传统的PLC逻辑控制,但可能在算法开发上不够灵活。所以对于需要复杂导航或AI集成的AGV,ROS2可能更合适,而传统控制逻辑则CODESYS有优势。 生态系统方面,ROS2有庞大的开源社区,提供丰富的软件包(如导航、SLAM、仿真工具),适合研发创新。CODESYS的生态系统集中在工业自动化领域,支持多种PLC硬件工业协议,适合标准化生产线集成。如果用户需要与现有工业设备兼容,CODESYS可能更优;如果需要前沿算法,ROS2更好。 硬件支持方面,ROS2依赖Linux系统,可能需要较高的硬件配置,而CODESYS可以运行在低成本的PLC硬件上,资源占用低。但瑞芯微平台如RK3588可能同时支持两者,需要具体分析。 安全性可靠性方面,CODESYS符合工业安全标准(如IEC 61508),适合高可靠环境。ROS2虽然能通过社区包实现部分安全功能,但整体不如CODESYS成熟,特别是在认证方面可能存在不足。 开发成本学习曲线方面,ROS2需要熟悉Linux现代编程,适合有软件背景的团队;CODESYS则需要熟悉工业PLC编程,适合传统自动化工程师。维护上,ROS2的模块化设计便于更新,而CODESYS的逻辑集中,维护简单但扩展性差。 用户可能的深层需求是平衡实时控制与智能功能,或者整合现有工业设备与新型AI算法。例如,使用CODESYS处理实时控制部分,ROS2处理导航感知,通过OPC UA或自定义中间件进行通信。这种情况下,混合架构可能更优,但需考虑复杂性维护成本。 总结优缺点,可能需要指出两者在不同场景下的适用性,以及可能的混合方案。此外,用户提到的瑞芯微平台,可能需要确认其对ROS2CODESYS的支持情况,如是否有合适的驱动社区支持。</think>针对AGV控制器软件架构选择ROS2与CODESYS的对比分析,以下是详细的比较框架与技术评估: --- ### **一、架构核心特性对比** | **特性维度** | **ROS2(Robot Operating System 2)** | **CODESYS(IEC 61131-3工业控制平台)** | |--------------------|--------------------------------------------------------------|--------------------------------------------------| | **实时性能力** | 软实时(依赖RT Linux/DDS配置,时延约1-10ms) | 硬实时(μs级确定性响应,满足IEC 61131-3标准) | | **开发语言** | C++/Python为主,支持现代编程范式 | 结构化文本(ST)、梯形图(LD)等工业标准语言 | | **通信机制** | 基于DDS(Data Distribution Service)的发布/订阅模型 | 基于工业现场总线(EtherCAT/Profinet)的周期通信 | | **硬件兼容性** | 需x86/ARM Linux环境,适配瑞芯微RK3588等高性能平台 | 直接支持主流PLC硬件(如倍福、西门子、汇川等) | | **生态扩展性** | 开源社区活跃,集成Gazebo、MoveIt等机器人专用工具链 | 工业协议库丰富(OPC UA、Modbus等),标准化程度高 | | **安全认证** | 需额外开发满足SIL2/PLd等级 | 原生支持IEC 61508/62061功能安全认证 | --- ### **二、AGV场景下的优势对比** #### **ROS2核心优势** 1. **复杂算法集成** - 支持SLAM(如Cartographer)、路径规划(Nav2)、3D感知(PCL)等先进算法,适合动态环境下的AGV导航。 - 多传感器融合(激光雷达+视觉+IMU)通过`tf2`库实现高精度时空同步。 2. **模块化开发** - 节点化架构允许分布式部署(如分离导航节点与控制节点),提升系统容错性。 - 借助`colcon`构建工具实现增量编译,开发效率提升50%以上。 3. **仿真验证能力** - 与Gazebo/Isaac Sim结合,可进行物理级数字孪生测试,减少现场调试风险。 #### **CODESYS核心优势** 1. **硬实时控制** - 精确周期任务调度(如1ms电机控制环),确保AGV驱动系统的稳定性。 - 支持安全逻辑(STO/SLS)直接嵌入PLCopen功能块,符合ISO 13849标准。 2. **工业协议兼容性** - 原生集成EtherCAT、CANopen等总线协议,与伺服驱动器/IO模块无缝对接。 - 通过OPC UA实现与MES/SCADA系统的数据贯通。 3. **工程化部署** - 支持在线热更新、变量监控、故障诊断等工业级运维功能。 - 代码可复用性高(库管理+面向对象编程),适合批量AGV产线部署。 --- ### **三、典型应用场景对比** | **场景需求** | **推荐方案** | **关键理由** | |----------------------|----------------------------|-----------------------------------------------------------------------------| | **高动态智能AGV** | ROS2为主 + 实时补丁 | 需处理复杂视觉导航、多机协同算法,ROS2的算法生态分布式架构更匹配 | | **重载工业AGV** | CODESYS为主 + 安全PLC | 对硬实时安全等级要求高(如汽车生产线),CODESYS的确定性控制更可靠 | | **混合型AGV** | ROS2+CODESYS异构架构 | 通过ROS2-Codesys Bridge(如opc_ua_ros2)实现上层智能决策与底层控制的协同 | --- ### **四、关键技术挑战与解决方案** #### **ROS2在AGV中的局限性** 1. **实时性瓶颈** - **问题**:默认DDS配置无法满足μs级控制周期需求。 - **优化方案**: - 采用实时Linux内核(如PREEMPT_RT) + Cyclone DDS(低延迟模式) - 关键控制回路通过`micro-ROS`部署到实时协处理器(如STM32H7) 2. **工业协议支持弱** - **问题**:缺乏原生EtherCAT/Profinet驱动。 - **解决方案**: - 通过ROS2-EtherCAT主站(如`soem_ros2`)桥接工业网络 - 使用OPC UA Pub/Sub实现与CODESYS的数据交换 #### **CODESYS在AGV中的局限性** 1. **算法开发效率低** - **问题**:ST语言实现复杂算法(如SLAM)代码量大、调试困难。 - **解决方案**: - 通过C/C++功能块集成第三方算法库(需CODESYS V3.5+) - 与边缘计算设备(如RK3588)协同,ROS2处理算法,CODESYS专注控制 2. **动态环境适应性差** - **问题**:传统逻辑控制难以应对非结构化环境变化。 - **改进路径**: - 集成AI推理引擎(如TensorFlow Lite for Codesys)实现在线学习避障策略 --- ### **五、选型决策树** ```plaintext ┌───────────────┐ │ AGV核心需求? │ └──────┬────────┘ │ ┌───────────────┴───────────────┐ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ 是否需要复杂环境感知 │ │ 是否强依赖硬实时控制 │ │ 或多机协同算法? │ │ 或工业协议? │ └───────┬─────────────┘ └───────┬─────────────┘ │ Yes │ Yes ▼ ▼ 选择ROS2 选择CODESYS │ │ ▼ ▼ ┌───────────────────┐ ┌───────────────────┐ │ 是否需硬实时补丁? │ │ 是否需要AI扩展? │ └──────┬────────────┘ └──────┬────────────┘ │ Yes │ Yes ▼ ▼ 集成RT内核+micro-ROS 外挂AI协处理器 ``` --- ### **六、混合架构实践案例** **某汽车厂物流AGV项目架构**: - **上层决策层**(ROS2): - 运行于RK3588平台,处理3D视觉导航(Intel Realsense D455)、动态路径规划(Nav2) - 通过OPC UA发布目标坐标、速度指令 - **底层控制层**(CODESYS): - 倍福CX2040 PLC实现1ms周期电机控制(EtherCAT驱动Beckhoff AX5000) - 安全逻辑通过CODESYS Safety实现PLd等级认证 - **通信桥梁**: - 使用`ros2_opcua`组件实现双向数据同步(100Hz更新率) **成效**: - 导航算法迭代周期从2周缩短至3天(ROS2仿真加速) - 运动控制抖动从±1.5mm降低至±0.2mm(CODESYS硬实时保障) --- ### **七、未来演进趋势** 1. **ROS2与IEC 61499融合** - 通过`ROS2-FBD`工具将ROS节点映射为功能块,兼容CODESYS工程标准。 2. **5G-TSN协同** - ROS2的DDS over TSN实现广域低时延通信,CODESYS负责本地确定性控制。 3. **AI原生控制** - 在RK3588 NPU上部署ROS2推理节点,与CODESYS安全逻辑形成闭环。 --- ### **总结建议** - **研发型AGV**:优先ROS2架构,快速验证先进算法,通过实时补丁满足基本控制需求。 - **量产型AGV**:采用CODESYS确保可靠性与认证合规,复杂AI功能通过边缘计算卸载。 - **高端AGV**:推荐异构架构,ROS2与CODESYS通过OPC UA/TSN深度协同,兼顾智能与实时。 两种技术栈的融合将成为AGV控制器演进的主流方向,开发者需根据具体场景在灵活性、实时性、成本之间取得平衡。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值