ThingWorx与Axeda有何不同？是否值得考虑改用？ | 博客

PTC逐渐退出其Axeda平台。
尽管初次看之下两个平台看起来很相似，但Axeda和ThingWorx在功能方面却大不相同。
当前的Axeda客户应考虑改用ThingWorx。
Transition Technologies PSC与PTC一起并肩工作，来促进Axeda客户转移到ThingWorx。

自PTC在2013年收回ThingWorx以来，该CAD参数系统的先驱和PLM的领导者理所当然希望大幅增加其在工厂和运营部门中的存在。大量投资使PTC能够强调自己到物联网领域的进入，但其范围受限制。从历史上看，他们从来与OT关系不大，所以从与项目工程师打交道到与工厂车间人员打交道并非易事。

当PTC在2014年6月宣布收购Axeda时[1]，其原因的正式立场是“扩展PTC的物联网技术产品组合” [2]。然而，在大家都知道，PTC还希望利用拥有Axeda的超过150个客户群。当时的Axeda平台技术“每天都处理了来自各行各业中的数亿条消息”。这即使对于像PTC这样成熟的组织也是真正的挑战。因为PTC努力赢得了客户运营部门的认可，所以对他们来说，这次的挑战肯定很大。因此，这项收购很有意义。

然而，有一件事变得很清楚：PTC已经在市场相似的领域具有两种相同的产品。尽管ThingWorx和Axeda的基础非常不同，但实际上页共享许多相似的功能以及潜在的应用。显然，从长远来看将无法维持该商业模式，所以PTC有可能终止其中的一种解决方案。当PTC-Rockwell Automation的联盟于2018年被宣布时[3]，许多M2M（机器对机器）和M2C（机器对云端）解决方案突然出现了。

不出所料，最终决定了进行“Axeda服务的停止”，结果它将慢慢失去其支持并变得过时，也有可能成为在任何组织中使用的所谓危险工具。用户放弃该技术已经不再是《是否》的问题，而是《何时》的问题。

在详细研究可能的选项（其中一种似乎从Axeda转移到ThingWorx）之前，重要的是了解这两种产品是什么以及可以做什么。

区分这两个的最快方法是将ThingWorx定义为一个灵活的平台，使组织可以根据特定需求快速开发原型和解决方案，并具有PTC或其合作伙伴生态系统创建的附加扩展和应用程序。Axeda不仅应被描述为非标准产品，实际上可以进行大量的自调整和扩展，但与ThingWorx相比，绝对更麻烦，动态性更低，有时甚至更受限制。

进一步研究这两个平台的功能可以使我们更详细地了解它们之间的区别：

ThingWorx	Axeda
安全模型
为用户提供对用户（或小组或组织）访问权限更加精确的控制。可以将访问权限应用于系统中的每个实体、服务或属性。	根据用户在小组中的成员资格确定的资讯资产/区域/组织/位置小组的可见性模型。
可见性、运行时和设计时安全性的明确区分。	允许为用户或小组启用或禁止全球定义的活动，而无需按实体、服务或属性进行区分
无需刷新用户上下文即可应用更改（登出并重新登录）。
添加新功能/扩展现有功能
几乎无限地添加新功能： 1. 用JavaScript库功能、界面的控件 2. 用Java库新功能的扩展	扩展的应用程序——数量有限的web应用程序，能够使用自定义JavaScript和函式库以及Axeda API
市场上有很多解决方案	平台直接提供Groovy服务，但不带编辑器——您只能将代码放入简单的文本字段即可。[4]
特定用途的OOTB（开箱即用）扩展，例如PTC Manufacturing Apps，Navigate等。	通过添加直接与平台核心代码一起使用的Java / JSP可以调整Axeda，但这绝不是建议的方法。
可从Thingworx Composer直接在编辑器中获得JavaScript服务
集成
体系结构和灵活性允许与第三方解决方案进行简单的集成。	必须使用上述的自定义构建方法。
提供Flow之类的外加附件，使轻松与其它平台集成。
通过Marketplace获得与多个系统集成的扩展。
连接性
ThingWorx OOTB边缘功能不像Axeda那样广泛。	先进的OOTB代理，“从一开始”能做很多。
可用于多种编程语言（C、Java、.NET、iOS、安卓）的软件开发工具包，使获得更大的灵活性。	可以用C / C ++编程来扩展代理。
ThingWorx支持Axeda代理。[5]	代理可以执行以代理所运行的操作系统支持的编程语言的脚本。
本地化
允许为自定义添加的部件（控件、扩展等）轻易定义多语言的解决方案	扩展应用程序需要创建单独的支持。。
适用于通过Composer添加的所有部件。	核心补丁可以以类似于在平台本身中的使用方式来使用Java机制。
数据库[6]
持久性提供程序允许将各种数据库作为存储数据的后端。	适用于Windows的Oracle 11g 11.2.0.4 ——仅在硬件上能运行。[7]
支持PostgreSQL、MS SQL、SAP Hana、AWS H2、MS AzureSQL。	Oracle Enterprise Linux 5 64位
快速的应用程序原型设计和开发
其架构和灵活性允许使用简单的工具——ThingWorx Composer快速对整个应用程序进行原型制作。。	与使用Axeda API的自定义网络应用程序类似，每次的自定义都需要从头开始开发

当然，这些并不是这两个平台之间所有的区别，而仅仅是我们认为最要的。通过搜索网络，您可以找到两个平台之间差异的许多示例。例如，本文介绍了两种平台上的eMessage Agents之间的区别。

总而言之，这两种产品之间的区别为：ThingWorx平台可让您创建可处理几乎所有问题的物联网应用程序和解决方案，而Axeda是为处理特定问题而定制的产品（M2M和M2C通信）。

客户仍然可以选择继续使用Axeda。但是，我们建议不要这样做。为什么？像技术遗产通常会遇到的那样，当其所有者最终决定“想开”，安全和支持是最明显的原因。随着网络安全威胁与日俱增，新技术正在渗透到我们（和公司）生活的方方面面，重要的是要在这两个领域保持能跟得上。

此外，找到具有相关Axeda知识足够的天才，使这项技术有效工作，将随时间变得越来越困难。另一方面，ThingWorx社区的发展仍在与许多PTC合作伙伴而进行，其中有PTC自身最信任的Transition Technologies PSC（TTPSC），从而能帮助这个组织的指定、创建、实施、维护和支持其ThingWorx的解决方案。。

从这个角度来看，Axeda的客户显然应该考虑向前迈出一步。PTC建议转移到ThingWorx。这是因为有Axeda Agents已经与ThingWorx兼容，并且可以将所接受的数据直接流式传输到平台上。ThingWorx对Axeda Agents的一般支持是开发团队的首要任务之一，并且在写本文的同时而迅速发展。

当然，许多客户已经构建了Axeda的基本定制解决方案，从而支持各种用途并提供独一无二的功能。好在PTC从未希望放弃其客户（以前是Axeda平台客户）。数周甚至数月的时间里，许多关键团队一直在与TTPSC编程专家并肩工作，准备让客户尽可能顺利地从Axeda转移到ThingWorx所需的流程和工具。Axeda的任何自定义功能都可以重新编程为在ThingWorx上运行，并且PTC和TTPSC等合作伙伴可以一直提供帮助。

PTC还提供先前定义的“成功服务”，旨在创建一个“详细计划，其中包含从Axeda转移到ThingWorx的建议步骤，同时保持Axeda的关键功能，但是展望将来如何使用ThingWorx平台。” [8]。如果有人更喜欢从头到尾与优选合作伙伴合作，则TTPSC之类的三方也可以提供此类服务。

在未来几个月里，大多数Axeda客户将受到PTC或TTPSC的计划和转移支持。因为上述的客户很多，所以此过程可能需要一段时间，并且与客户的联系及其转移将花费一年以上。当想要加快此过程，请与TTPSC代表联系：