服务热线
13313705507
截至今天，大多数 OPC UA over TSN 的集成和评估都集中在 C2C 用例上。控制器已经运行操作系统，其中许多共享库和现有功能可以被 TSN 网络堆栈重用。
尽管如此，完整的网络协议套件仍有大量内存需求。在运行 Linux 的 64 位架构上，交换机和交换端点上以太网/TSN 网络的平均额外 RAM 使用量为 4 到 5 兆字节，用于 NETCONF 服务器、网络时钟同步和动态以太网/TSN 操作所需的网络协议，例如 LLDP和 MSTP。
其他嵌入式操作系统也有类似的观察结果。OPC UA 服务器的内存要求取决于所选的服务器配置文件和应用程序所需的信息模型的大小。作为参考，经常评估的支持“微型嵌入式”服务器配置文件的 open62541 堆栈为非常小的信息模型增加了不到 100 KB。
然后，RAM 使用量随着管理的数据元素的数量线性增加，实验表明，使用 1 兆字节的额外 RAM，可以在 OPC UA 堆栈中管理用于客户端/服务器和发布/订阅访问的数百个数据元素。
发现 TSN 网络的 CPU 负载很低——对于同步协议的典型设置，使用了不到 1% 的嵌入式 800 MHz CPU 内核。在使用 NETCONF 替换现有 SNMP 堆栈的情况下，甚至可以观察到网络功能分配的 CPU 利用率下降。
综上所述，完整的 OPC UA 和 TSN 功能集的资源消耗可以适应 C2C 用例的典型控制器，例如工业边缘服务器、IPC 和高性能 PLC。对于 C2D 用例中资源受限的 PLC 和现场设备，这可能会有所不同。但这不一定是使用该技术的障碍。
大多数使用 TSN 的应用程序只需要在没有切换功能的端点设备上进行常规以太网和时钟同步，并且 OPC UA 信息模型会更小。
在使用 UADP 映射到以太网/TSN 驱动程序时，当前仅针对发布/订阅功能定义了通过 TSN 与 OPC UA 进行确定性应用程序级端到端通信的目标，并且需要适当配置 TSN 网络以提供有保证的PubSub 网络流的延迟。
支持 TSN 的网络上的所有其他 OPC UA 通信旨在通过 TSN 网络提供的常规以太网机制使用 TCP/IP 通信。这符合各种联盟定义的用例以及用户对技术的期望。
用户期望网络融合的好处，即在单个网络基础设施上、同一条线路上、甚至在同一网络接口上使用确定性流量和常规流量。然而，网络融合不应该要求对常规流量进行专门的网络配置，它应该易于实施，并且对确定性流量应该是完全透明的。此外，在 TSN 网络上创建和运行 OPC UA 应用程序不需要终用户具备以太网和 TSN 机制方面的专业知识。
在这一领域，我们观察到不同客户的不同体验。有些人使用 TSN 配置工具和机制来配置他们的系统，这些工具和机制遵循 TSN 官方网络组件配置标准，并且几乎没有遇到任何问题。但是，这种方法需要网络元素上的完整 TSN 网络软件堆栈（特别是 NETCONF）。
其他人需要或更喜欢将配置功能集成到他们现有的配置管理系统中，因为确定性通信（调度）所需的 TSN 配置元素与其他以太网 QoS 功能不同，因此发现这具有挑战性。
然而，在评估中观察到了两条路径——IEEE 配置标准，以及与供应商特定配置的集成——这使得了解基于 OPC UA 和 TSN 的复杂系统的独立于供应商的配置将如何工作变得很有趣专用的 TSN 网络配置机制。
在这里，前景很重要。将 OPC UA PubSub 与 TSN 完全集成的预期解决方案尚未完成标准化，该解决方案允许发布者和订阅者应用程序通过代理架构自动配置 TSN 网络。
一旦可用，用于 OPC UA PubSub 端点之间确定性 C2C（和 C2D）通信的 TSN 网络流的配置将对应用程序开发人员和集成商透明，并且不需要集成商使用专用的单独 TSN 网络配置机制。
迄今为止，这种能力仅在演示系统中展示，是开发成熟解决方案的重要下一步。
我司产品广泛应用于数控机械 冶金,石油天然气,石油化工，
化工,造纸印刷,纺织印染,机械,电子制造,汽车制造,
塑胶机械,电力,水利,水处理/环保,市政工程,锅炉供暖,能源,输配电。
Users expect the benefits of network convergence i.e. using deterministic traffic with regular traffic on a single network infrastructure, on the same wire, even in the same network interface. However, network convergence should not require dedicated network configuration for regular traffic, it should be easy to implement, and it should be fully transparent to deterministic traffic. In addition, creating and running OPC UA applications on TSN networks should require no expert knowledge in Ethernet and TSN mechanisms from the end user.
In this area we observed very different experiences for different customers. Some configured their system with TSN configuration tools and mechanisms adhering to the official TSN standards for configuration of network components and experienced little or no issues. However, this approach requires the full TSN networking software stack (notably NETCONF) on the network elements.
Others need to or prefer to integrate the configuration capabilities into their existing configuration management system, which was found to be challenging because the TSN configuration elements needed for deterministic communication (scheduling) are different than other Ethernet QoS features.
Nevertheless, both paths – the IEEE standards for configuration, and the integration with vendor-specific configuration – are observed in evaluations, which makes it interesting to see just how well vendor-independent configuration of complex systems based on OPC UA and TSN will work for dedicated TSN network configuration mechanisms.
Here, the outlook is important. The intended solution for full integration of OPC UA PubSub with TSN, which lets the Publisher and Subscriber applications configure the TSN network automatically by means of a broker architecture, has not yet been finished in standardization.
Once it is available, the configuration of the TSN network streams for deterministic C2C (and C2D) communication between OPC UA PubSub endpoints will be transparent to the application developer and integrator and not require dedicated separate TSN network configuration mechanisms to be used by the integrator.
This capability, so far only shown in demonstration systems, is the important next step in the development of mature solutions.
