opc ua客户端开发_ThingWorx开发小结

最近一段时间尝试了下用ThingWorx做开发，下面是一些心得和小结。

1、ThingWorx作为IoT平台(Connectivity+Thing)

ThingWorx整合了Kepware，作为ThingWorx Connectivity部署。

Kepware的PLC驱动可以快速配置，实现和主流PlC的双向通信。

Kepare的IoT Gateway提供了Rest Server/Rest Client/MQTT Client这3种代理，实现和IT系统的通信。

ThingWorx内置了一个OPC Client，叫做Industrial Connection，可以通过Discover工具实现对OPC目录和TAG的浏览和绑定，非常方便。

由于Kepware同是PTC的产品，因此和ThingWorx的整合是相当深入的，只需要在Kepware中做一些简单的配置，就可以在ThingWorx中调用OPC，这一点比起其它SCADA产品方便得多。

最大的缺点是不支持对OPC TAG的动态名称调用。

我们知道OPC TAG是一个字符串形式的内存变量，可以通过拼接的形式得到完整的TAG名称，象GE Cimplicity和Ignition都支持对OPC TAG的动态读写，这样可以通过编写服务来重复调用、简化代码。

而ThingWorx的核心是Thing这个对象，OPC TAG是作为一个绑定的远程变量附加到某一个属性上的，因此每一个TAG都是独立管理的。

从PTC ThingWorx Manufacturing Apps的代码（Controller.UpdateProperty）我们也可以看出，ThingWorx是作为REST Client来实现动态回写OPC的（与Kepware的Rest Server通信）。

2、ThingWorx作为数据展示平台(Mashup)

展示方面，ThingWorx提供了Mashup、Gadgets、Style、State等工具。

其优点是美观、现代化，IT工程师开发起来顺手。

相比较而言，ThingWorx适用IT工程师开发，而传统SCADA适合控制工程师开发。

为什么这么说呢？

一个重要的原因是，ThingWorx是基于JAVA开发的，因此有大量的配置、继承。

比如Menu菜单、Media图片、Style样式、State数据规划，这些都是独立的对象，Mashup只能引用。

举个简单的例子，你想要把字体放大一号，你必须新建一个Style，然后在Mashup中引用。

这些对于JAVA工程师来说不以为怪，但是对于工控工程师来说就很头大了。

此外，ThingWorx自带的一些Widgets也不是很成熟，如：Label的字体最小号是9px，饼图不能显示数值和百分比，柱状图的文字长度受限等。

3、ThingWorx作为客户端(Mashup)

ThingWorx是B/S架构的，因此其客户端相当于运行一个Mashup实例。

但是Mashup本身不具备任何的逻辑处理能力，只有基本的复位数据等固定功能。

在ThingWorx中，只有Thing是真正的逻辑实体，所有业务逻辑都是通过Service传递给Mashup的。

因此，任何客户端的业务逻辑，都必须绑定远程的Thing.Service来予以实现。

举个简单的例子，客户端采集到条码后要进行有效性校验，但是客户端不能执行校验逻辑，必须调用服务端的逻辑实现，其路径是：JavaScript/Query --> Service --> Thing --> Mashup.

目前JAVA和B/S能在互联网大行其道，一个重要原因是允许客户端JavaScript的执行，甚至衍生出了前端程序员这个工种。

但是ThingWorx不支持客户端JavaScript调用，是其一个较大的局限。

4、ThingWorx作为集成开发环境(Platform)

我们可以把ThingWorx作为一个简化的集成开发环境，它对JavaScript/SQL的支持非常好，开发也非常方便。

下面谈几点短板。

我们知道，和JAVA相比，.Net是一个半C/S、半B/S的架构，因为.Net客户端可以通过.Net Framework来调用系统dll，从而得到OS操作权限及实现分布式架构。

比如，.Net客户端可以调用本地opc client直接和opc server通信，这样通信的链路就分散开来，减少了服务端专用opc client的阻塞和性能需求。

而ThingWorx基于Java开发，是典型的B/S架构。而JAVA基于安全的考虑，服务器是不具备操作系统权限的。

以文件操作为例，ThingWorx定义了一个文件存储的根目录，所有ThingWorx管理的文件必须在此目录下。因此，ThingWorx不能处理服务器上其它目录的文件，也不能处理局域网内通过文件夹共享的文件。

因此，我们必须通过MQTT、FTP等方式来处理远程文件。

ThingWorx提供了一个FTP Client扩展，但是坑爹的是只提供文件读、写功能，不能执行删除操作。

那么假设我们需要从某台设备PC采集文件数据，怎么操作比较方便呢？我们需要在ThingWorx上建立一个FTP SERVER，然后把ThingWorx文件子系统映射成FTP虚拟子目录，然后在设备PC上通过FTP CLIENT上传数据； 然后在ThingWorx文件子系统进行文件的读写。

ThingWorx还有一个缺点是对项目的管理不是很完善。比如说，我们有很多Media/Style/State，会需要在许多项目中使用，但是这些对象只能绑定到一个Project，这就不是很合理了。

此外，Service的调试是不支持中断的，要调试代码，必须自己写LOG，然后在Monitoring中查看日志。