开发物联网服务的成本效益,必须明确业务目标,并建立在实际地反复采集并分析数据的基础上。
开发重点:
(一)设备
- 需要收集哪些设备的数据
- 需要收集这些设备的什么数据进行分析
- 以什么方式,以什么频率进行收集
- 数据分析结果能够带来什么
- ThingWorx Real-Time Production Performance Monitoring
- ThingWorx Asset Monitoring and Utilization
- ThingWorx Connected Work Cell
- ThingWorx Asset Monitoring and Utilization
- (二)架构 – 处理方式设计
- 如何追加新设备
- 如何应对数据量增多
###如何追加新设备
2.1.1借用面向对象编程的相关理念,通过Thing, Thing template, Thing Shape在ThingWorx对设备进行管理。
a. Thing的概念和特点
Thing是ThingWorx的主体,创建出来的Thing通常代表实体设备,系统和装置。为了方便管理,所有的Thing是基于Thing template来创建。
b. Thing template的概念和特点
在面向对象编程中,Thing template是一个类,可以定义properties, services, events, subscription来代表实体对象或者称为类的实例。Thing template可以实现多个Thing shape,帮助对象的重用。
c. Thing Shape的概念和特点
类似于面向对象编程中的抽象接口,也类似于制造过程中的模具。我们可以利用模具创建出实体的对象出来,但模具本身不能替代Thing,所以可以利用Thing shape创建出Thing,但不能代替Thing。
2.1.2 支持多种设备通信协议
数据接收服务器 – 数据处理服务器 – 数据库服务器
为了减少追加设备对主服务器和其它设备的影响,需要设计分层化数据处理,即在发送数据给主服务器时,先通中间层把接收到的数据转换成规定的数据格式。那么追加设备种类时就能不牵扯到共同处理的部分,只单独扩展和开发与设备相关的部分即可。
a. ThingWorx AlwaysOn 协议 ---Thingworx的特有协议。
b. Websocket 协议
c. HTTP 协议
d. MQTT 协议
2.1.3 Thingworx提供的中间层软件
a. Kepware
b. Thingworx C-SDK
c. Thingworx DOTNET-SDK
d. Thingworx JAVA-SDK
e. ThingWorx Edge MicroServer
###如何处理负载,应对容量增加
2.2.1队列设计
2.2.2数据库扩展设计
Thingworx使用适当的JDBC驱动程序可以连接到多种关系数据库,扩展性很强。
2.2.3分散功能
在大规模的物联网系统中,连接的终端成千上万,在服务器进行接收处理可能会来不及。这种情况可以在接收处理和把功能分散给设备及网关方面考虑。
有些时候,即便设备能够在1秒内传递多次数据,但从业务应用的角度来看,只要每10分钟更新1次数据就够了。也就是说,如果持续向服务器发送不用的数据,就会浪费线路成本和存储空间。此时重要的不是用服务器端接收所有数据,而是要在网关终端上下功夫,例如以下这些情况:
· 通过过滤来监控数据,只发送异常数据
· 通过初步分析只发送分析结果
基于此,Thingworx提供的中间层软件就相当有必要。
(三)网络
不要忽视通信成本
3.1选择协议
3.2压缩数据
### 选择协议
a. ThingWorx AlwaysOn协议
b. ThingWorx Connection server
(四)安全性
(五)应用和维护
5.1系统监控
Prometheus and Grafana
ThingWorx Foundation Prometheus Metrics
JMX Exporter & Means Attributes (Tomcat and C3P0)
Connection Server
5.2 故障服务
日志设计:从数据经过的设备,网关,服务器的各个构成要素中分别获取我们需要的每个主机操作系统和启动应用程序上的日志。也为了避免日志溢出问题,在设计日志时,先考虑好系统的日志容量和存储时间等因素。
5.3 系统维护
ThingWorx的二次开发,通过extension的方式进行服务扩展,也是其优势。
Thing对象的导出导入从而重用和维护,也是其优势。