浅谈工业级物联网项目架构设计及实施

【说明】这是发表在《程序员》电子刊10月B架构专题文章

网页链接:http://www.csdn.net/article/2015-10-31/2826093

摘要:互联网+和物联网由于发展的侧重点不同,在做架构设计上肯定有所不同。而以中小项目为主的物联网项目,其实更看重的,一是系统稳定可靠,能保证系统长期稳定的运行。本文主要介绍工业级物联网项目的架构设计及实施。

前言

早在1999年就已经有了“物联网”这个概念,但是直到十年之后的2009年,IBM提出“智慧地球”的概念,才推动很多国家把物联网研究和发展提升到战略层面。但是比较遗憾的是,直到现在的2015年,我国的物联网的发展依然主要靠政府项目来拉动,所以现在的发展似乎前景越来越不明朗。

政府似乎意识到这是个问题,在一些互联网公司的倡导和推动下,提出了“互联网+”的概念。虽然“互联网+”和“物联网”都是以网为主,但是发展的侧重有了本质区别。“互联网+”是以互联网为主,外围智能模块和传感器为辅,构建互联生态。而“物联网”却是以互联网为基础,重点在传感器数据采集,设备控制,远程监控为主。

但是现在很多互联网公司,做的是“互联网+“的事,却以”物联网“的名义来宣传。所以现在的人越来越搞不清”物联网“的真实定位了。

我一直认为从技术角度来看,所谓“物联网“就是传统工控网的一个外延。传统的工业现场,考虑到生产安全,都是内部网络。另外实施和维护的代价相对较高。而在互联网和移动互联网越来越完善的今天,在各个领域都有了远程测控的要求。比如目前比较典型的农业大棚监控、森林防火监控、鱼塘监测和养殖管理等等。

“互联网+”和“物联网”由于发展的侧重点不同,在做架构设计上肯定有所不同。“互联网+“的项目,其实更看重的是用户数,通信数据流量,这是衡量一个”互联网+“项目成功的标志,当然这是也是那些做云平台为主的互联网公司最看重的,用户数和通信数据流量正是他们的利益点所在。

而以中小项目为主的“物联网”项目,其实更看重的,一是系统稳定可靠,能保证系统长期稳定的运行,因为有些监控点往往部署在人迹罕至的地方,系统的可靠性成为关键。二就是系统便于开发和维护,因为基于不同行业,不同工艺需求的,很难开发出像民用领域的通用产品,需要根据现场实际调整相关的业务逻辑和监控画面,所以是否易于开发很关键。当然维护更为重要,因为偏工业级的“物联网”项目一般设计至少是三年或更长的生命周期,所以项目维护难以避免,甚至系统还会根据现场工艺的变更进行变化,易于维护是“物联网“项目一个不可或缺的要素。

由以上的说明,我们可以很清晰地了解,从技术角度来讲,做“互联网+”和“物联网”项目的架构设计是有很大的不同,本篇文章主要介绍工业级“物联网”项目的架构设计及实施。

工业级物联网的概念和特色

由于笔者曾经在传统工控领域工作7年之久,所以理解“物联网”更多是从工控的角度来考虑。所谓的工业级物联网,不是工业领域的物联网,而是具备工业领域的特色的物联网项目,比如农、林、牧和渔业等领域的相关项目。和工业领域的项目不同,没有那么庞大和要求严格,采集和监控的数据也相对较少,对设备、及实施和维护的成本比较敏感,并且一般要求远程监控。但是相同的要求是,设备要稳定可靠,便于根据工艺要求调整控制策略,方便升级、扩展,易于维护。

传统工控项目,一般相对庞大,环节多,开发和实施周期都比较久,当然项目的费用也是相对高昂的。往往一个实施工控项目的公司,一年能做十几个这样的项目就已经很繁忙了。而在物联网时代,由于互联网和移动互联网基础设施比较完善,云服务公司也是层出不穷,可以花最少的代价,相对快速的完成一些项目。

由于开发和实施的代价大大降低,所以可做的领域被大大拓宽了,形成了一个良性循环,做的越多,越可靠,也越便宜。越便宜,可做的项目也越来越多。

工业级物联网项目架构设计思想

了解了工业级的物联网项目的一些特色,所以架构设计方面就有了方向和思路。我们先从技术角度分析,当前一个典型的物联网项目,从组成上来讲,至少有三部分:一是设备端,二是云端(主要指公有云),三是监控端。

1. 设备端架构设计

设备端主要负责数据采集,工艺逻辑执行及控制。

无论底层的设备数量有多少,通信协议有多复杂,考虑到项目安全等等因素,往往和云端通信,汇集在一个设备上,这样的设备的角色往往是物联网网关,除了专门负责和云端进行通信外,有时候也会对原始数据进行一定的处理,执行一些业务逻辑相关的代码。 和云端通信有很多协议可选,常见的有基于HTTP协议的Get或Put方法,从服务器获取一些设置及状态,及向服务器推送采集到的数据。但是对数据量相对比较大,实时性要求高的,往往是直接的Socket TCP/UDP通信,这样传输的代价相对较低,但是对编程设计方面要求比较高。

由以上分析,从功能层面上分,设备端架构一般可分三层,一是数据采集&控制输出层;二是工艺流程执行层;三是数据上传&命令接收通信层。

2. 云端架构设计

云端一般包含三部分:Web前台+ Web后台+中间件;

作为工业级的物联网项目,Web前台一般会显示这几部分内容,一是工艺画面,和现场实际的设备和工艺流程一一对应,画面可以实时反映工业现场运行的情况。二是各种数据报表、曲线数据的保存、查询和打印等。三是运行日志,保存各种运行情况,以备查询。四是显示系统诊断信息,便于系统出现问题的时候,及时判断问题所在。

Web后台相对复杂一些,一般完成三部分内容的工作,如果是设备端基于HTTP协议通信,往往需要处理Get和Put请求。由于前台有实时画面,所以Web后台有时候也需要向前台界面传输实时数据,目前有些实时数据是通过Web Socket协议进行传输,也可以由专门的程序来处理。还有一部分功能比较重要,就是要建立设备数据和各种报表,曲线,日志的对应关系,以便于适用尽可能多的现场。

在工业级物联网项目中,一般中间件必不可少,其主要功能就是负责和现场设备进行通信,获取数据或发送相关控制指令。此外还有一个比较重要的功能,由于中间件程序一般是作为系统的一个服务程序或普通应用程序,生命周期较长,可以长时间连续运行,可以处理一些相对复杂的业务逻辑、数据换算及数据转储。

3. 监控端架构设计

监控端一般包含PC、手机或平板监控。

对一般项目而言,也许通过Web前台就可以掌控一切了,但是在移动互联网的时代,如果对应的手机或平板上没有对应的APP,那这个项目就感觉有了一个很大的缺憾。有了手机或平板APP,就可以身在任何地方,都可以相对方便的监控现场。

从功能上划分,架构可以相对简单的分为两层,一就是UI界面显示及操作层,二就是数据通信层,实现和服务器信息交互。

4. 小结

如果抛开其他一切因素,仅从技术角度来讲,实现以上三个大环节的功能,用什么系统平台,任何开发语言都可以完成其预定的功能。但是所谓的架构设计,不仅仅从功能角度来设计整个的系统平台,更多还要考虑其可靠性,扩展性,维护性等几个方面。

作为工业级的物联网项目,大都是面向工、农、牧、渔等具体行业,每种行业虽然从技术角度而言有很多类似的部分,但是从工艺流程角度又有很大的区别,所以针对具体的项目,进行代码调整及相关功能的扩展及二次开发必不可少。但是面向一线的工程师往往技术水平及能力相对比较低,能否快速编写出可靠、健壮的代码显的非常重要,毕竟每个项目现场实施时间是有限的,但是同时项目要求也是比较高的。

另外一个物联网项目,包含了嵌入式设备的开发、Web前后台的开发、服务程序开发还有手机和平板程序开发,每一项从技术平台上来说各种各样,比如嵌入式设备,有微软体系的Windows CE/XPE/.NET Micro Framework,有linux体系的嵌入式linux/uclinux等等,还有uCOSII/FreeRTOS/mbed OS等等实时嵌入式操作系统,其开发工具,系统架构各不相同,各有特色。手机和平板目前至少也有三种开发类型,一种是iOS开发,一种是安卓开发和windows 10 UWP通用程序开发等等。另外Web开发就更多了,这里就不一一举例了。

所以如果在整体架构设计中,每种部分都选用不同的技术路线,那么每一种技术路线,意味着都要有一个团队去开发,并且开发完毕后,还需要上下进行沟通,以便于把整个项目有机地联系在一起。

开发完毕后,更多的还有维护工作,不仅是开发团队的维护,更为重要的是现场维护,除了问题,如何及时定位,及时解决。针对如上问题,加上多年的现场实施和维护经验,所以我更看重统一化和组态化的架构设计,下面我就讲讲我们是如何构建物联网项目的。

物联网通用中间件平台架构设计

由于是一个物联网通用中间件开发平台,所以着眼点并不是一两个非常有行业特点的项目平台,而是面向不同行业,不同具体应用的二次开发平台,更多考虑跨行业应用的技术通用部分及同一个运行时平台支持多个项目点的功能。

下面我们就设备端、云端中间件及物联网通用平台分别进行介绍。

4.1 物联网嵌入式数据组态YFIOs架构设计

在工控领域,组态软件司空见惯。为什么很多工业项目采用组态软件,原因主要有两点,一是模块化搭积木式的设计,技术门槛低,实施速度快,非常适合工控技术人员使用;二是可靠性非常高,由于模块之间耦合性低,重用度高,并且每个模块往往在不同项目现场,实际都得到过运行考验,所以稳定性自不待言。

YFIOs的设计思想就来源于标准的组态软件,但是又具备了一些物联网时代的功能特色。

图1 YFIOs系统架构

从图1架构图上可以看出,YFIOs包含三大部分:驱动层、策略层和核心层。

底部驱动层支持大部分物理通信接口,主要功能就是和传感器(或智能模块)通信,获取相关的传感器数据及发送控制执行指令。

上部策略层除了加载执行一些系统策略(如系统通信策略)外,还可以加载用户策略,这样可以基于现场工艺流程,立即就可以进行相关的工艺控制操作,不用送到服务端,等服务端远程发出控制指令。

中间核心层是最关键的,除了启动驱动和策略引擎外,还创建了两个内存数据库。一个是IODB,主要存放点数据(如温度、湿度数据),另外一个是IOBC,主要存放块数据(如摄像头图片)。策略程序和驱动程序,完全解耦合,通过IODB和IOBC进行数据交互。

和传统组态软件(特指数据组态部分)相比,YFIOs有如下特色:

  1. 基于.NET系统进行驱动和策略开发,由于系统自带垃圾回收机制,不用担心在编写驱动和策略过程中,因内存溢出等原因导致系统当机。
  2. 传统的组态软件一般对外不提供驱动开发SDK,即使有,大都也采用C++进行开发,对开发者要求比较高。YFIOs和传统组态软件不同,驱动可以采用C#和VB.NET进行开发。且驱动有多种运行模式,不仅系统可以调用,用户策略也可以调用。还可以绑定策略事件,通过触发的方式去执行指定的策略。
  3. YFIOs的驱动可以动态替换,如果配置了相关的连接变量,只要驱动变量接口兼容就可以替换,这大大降低了系统运行后的维护成本,外围的硬件设备可以根据需要进行替换。
  4. YFIOs系统支持远程升级和远程调试。支持三个层面升级,YFIOs运行时升级、YFIOs驱动和策略升级和YFIOs配置升级。

针对设备端,我们也设计了基于物联网画面的组态软件YFHMI,由于这部分其实和传统的画面组态区别不是很大,所以这里限于篇幅,不再介绍了。

2. 物联网云端中间件YFCloud架构设计

云端YFCloud中间件平台,可以说是完全脱胎于嵌入式YFIOs,从图2的架构图上就可以明显看出,可以这样说,YFIOs是一个“单机版”的数据组态平台,而YFCloud是一个“网络版”数据组态平台。

YFCloud和YFIOs都可以运行策略程序和创建IODB内存数据库,不同的是YFCloud去掉了IODC内存数据库,并且驱动层简化为一种,就是TCP/IP通信接口,每一个远程设备,服务器都会分配一个Socket连接,登录成功后,才能正常通信。如果设备30秒上传数据无变化,则发送心跳信号,否则60秒无数据收到,服务器会主动关闭连接。

图2 YFCloud中间件架构

YFCloud还集成了WebSocket服务器,Web动态网页可以通过WebSocket协议和服务器进行通信。

YFCloud物联网中间件平台是以项目为最小单位来进行管理的,一个或多个项目对应一个项目模板,项目通过项目ID进行区分。由于是二次开发平台,所以YFCloud提供了一个平台级的开发接口,通过接口可以管理相关的项目模板和项目(如创建、编辑、删除、启动和停止等)。

3. 物联网通用平台架构设计

图3 物联网通用平台架构

YFIOs嵌入式数据组态运行在物联网智能网关上,直接和YFCloud进行通信(云端中间件通过导入YFIOs的上传IO表,就可以直接进行通信了)。

物联网通用平台的Web前台,目前默认具备如下功能(每个项目模板可以根据需要,进行选择所需要的功能,项目完全继承了项目模板的选择)工艺流程显示、工艺报表(日报表,统计报表)、工艺曲线显示、项目运行日志、工艺参数配置和摄像头监控等等。

物联网通用平台的Web后台,主要功能就是用户管理、角色管理(和功能匹配的角色)、项目模板管理和项目管理。限于篇幅,就不详细介绍了。

4. 小结

该平台的最大优势就是,从软到硬,全部采用了.NET平台。所以不需要太多的技术人员,就可以从上到下进行项目开发。对客户来说,由于涉及到的技术领域比较少,所以二次开发及后续平台维护也比较容易。

物联网项目案例简介

1. 家庭远程健康监控系统

这是比较早的一个案例了。设备外接血糖仪、血压计、摄像头、温湿度模块,内部集成了RFID刷卡器及3G模块。通过3G和远程服务器进行通信,用户或医生通过网页查看相关信息,其中医生还可以远程留言并发送到设备。采用组态式的架构最大的好处就是, 由于每个家庭已有的血糖仪或血压计型号不同,设备可以根据对应的传感器型号,选择不同的驱动,可远程部署驱动进行适配。

图4 远程监控检测设备连接图

2. 农业大棚监控系统

系统核心为物联网智能网关,外部连接摄像头、温湿度传感器,通过以太网、Wifi或3G路由器把相关数据推送到服务器。

客户可以通过PC、平板或手机远程监控蔬菜大棚中的作物生长情况。

图5 农业大棚手机监控图

3. 近海渔业监控系统

通过水质传感器,获取当前水质情况(Modbus RTU通信);通过摄像头获取当前图片;通过GPS获取当前经纬度;通过GPRS模块把数据传送到远端服务器。

图6 渔业监控设备连接示意图

4. 村级污水处理监控系统

物联网智能网关通过RS485/CAN和智能终端连接在一起,智能终端采集各种数据,或控制相关设备运行。网关通过无线路由器或GPRS模块向服务器发送数据,或者接收服务器的控制指令。

Web网页可以查看现场工艺流程界面,工艺报表及设置工艺参数等等。

图7 污水监控设备连接示意图

图8 污水监控Web界面图

物联网项目开发的未来发展方向

现在国内外互联网企业巨头,瞄准的物联网领域,大都是民用领域,如智能家居、车联网等等。这些领域的特点就是量大、并且相对统一,每个客户不需要特别的定制(特别是硬件层面,区别不大,个性化最多在软件层面)。

但是在非民用领域,即使类似的项目,往往因为最终客户不同,工艺流程的差异,软硬件也会有相对大的变动。另外和民用产品不同,一是应用环境相对恶劣,二是要求24*7连续运行,对稳定可靠性要求比较高,三是要便于扩展,便于维护。

所以这类物联网项目,未来的发展方向,肯定是首先在可靠性上下工夫,满足长期使用的需求后,就是尽可能提取共用部分,让每个项目的修改量降到最低。

当然未来最有可能的发展方向就是,随着现在分工越来越细,云计算发展的越来越成熟,物联网协议标准的确立和客户技术能力的提高,未来也许是在最终客户的统一协调下,不同物联网厂商各做一部分(或软或硬),共同完成最终的项目。

(责编/ 钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件[email protected],交流探讨可加微信qshuguang2008,备注姓名+公司+职位)

作者简介:刘洪峰,网名叶帆,叶帆科技创始人兼CEO,前微软(中国).NET Micro Framework开发团队成员,微软全球最有价值专家(MVP),CSDN十大MVB。以微软.NET MF系统为核心,研发了物联网智能网关、YFIOs和YFHMI等物联网中间件软硬件平台。

时间: 2024-10-18 19:37:05

浅谈工业级物联网项目架构设计及实施的相关文章

浅谈HTML5单页面架构(二)——backbone + requirejs + zepto + underscore

本文转载自:http://www.cnblogs.com/kenkofox/p/4648472.html 上一篇<浅谈HTML5单页面架构(一)——requirejs + angular + angular-route>探讨了angular+requirejs的一个简单架构,这一篇继续来看看backbone如何跟requirejs结合. 相同地,项目架构好与坏不是说用了多少牛逼的框架,而是怎么合理利用框架,让项目开发更流畅,代码更容易管理.那么带着这个目的,我们来继续探讨backbone. 首

AngularJS进阶(二十五)requirejs + angular + angular-route 浅谈HTML5单页面架构

requirejs + angular + angular-route 浅谈HTML5单页面架构 众所周知,现在移动Webapp越来越多,例如天猫.京东.国美这些都是很好的例子.而在Webapp中,又要数单页面架构体验最好,更像原生app.简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多. 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1.requirejs+angular+angular-route(+zepto) 最后这个zepto可有可无

浅谈图片服务器的架构演进

浅谈图片服务器的架构演进 现在几乎任何一个网站.Web App以及移动APP等应用都需要有图片展示的功能,对于图片功能从下至上都是很重要的.必须要具有前瞻性的规划好图片服务器,图片的上传和下载速度至关重要,当然这并不是说一上来就搞很NB的架构,至少具备一定扩展性和稳定性.虽然各种架构设计都有,在这里我只是谈谈我的一些个人想法. 对于图片服务器来说IO无疑是消耗资源最为严重的,对于web应用来说需要将图片服务器做一定的分离,否则很可能因为图片服务器的IO负载导致应用 崩溃.因此尤其对于大型网站和应

浅谈大型web系统架构

动态应用,是相对于网站静态内容而言,是指以c/c++.php.Java.perl..net等服务器端语言开发的网络应用软件,比如论坛.网络相册.交友.BLOG等常见应用.动态应用系统通常与数据库系统.缓存系统.分布式存储系统等密不可分. 大型动态应用系统平台主要是针对于大流量.高并发网站建立的底层系统架构.大型网站的运行需要一个可靠.安全.可扩展.易维护的应用系统平台做为支撑,以保证网站应用的平稳运行. 大型动态应用系统又可分为几个子系统: 1)Web前端系统 2)负载均衡系统 3)数据库集群系

浅谈HTML5单页面架构(一)——requirejs + angular + angular-route

本文转载自:http://www.cnblogs.com/kenkofox/p/4643760.html 心血来潮,打算结合实际开发的经验,浅谈一下HTML5单页面App或网页的架构. 众所周知,现在移动Webapp越来越多,例如天猫.京东.国美这些都是很好的例子.而在Webapp中,又要数单页面架构体验最好,更像原生app.简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多. 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1.requirejs

浅谈数据仓库的基本架构(转)

数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持(Decision Support).其实数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫“仓库”,而不叫“工厂”的原因.因此数据仓库的基本架构主要包含的是数据流入流出的过程,可以分为三层——源数据.数据仓库.数据应用: 从图中可以看出数据仓库的数据来源于不同的源数据,并提供多样的数据应用,数据自上而下流入数据仓库后向上层开放应用,而数据仓库只是中间集成化数据管

基于Repository模式设计项目架构—你可以参考的项目架构设计

关于Repository模式,直接百度查就可以了,其来源是<企业应用架构模式>.我们新建一个Infrastructure文件夹,这里就是基础设施部分,EF Core的上下文类以及Repository层都放在这里面.新建一个IReposotory的接口,其内容就是封装了基本的CRUD: public interface IRepository<TEntity> where TEntity : class { ///获取当前实体的查询数据集 IQueryable<TEntity&

转:浅谈图片服务器的架构演进

现在几乎任何一个网站.Web App以及移动APP等应用都需要有图片展示的功能,对于图片功能从下至上都是很重要的.必须要具有前瞻性的规划好图片服务器,图片的上传和下载速度至关重要,当然这并不是说一上来就搞很NB的架构,至少具备一定扩展性和稳定性.虽然各种架构设计都有,在这里我只是谈谈我的一些个人想法. 对于图片服务器来说IO无疑是消耗资源最为严重的,对于web应用来说需要将图片服务器做一定的分离,否则很可能因为图片服务器的IO负载导致应用 崩溃.因此尤其对于大型网站和应用来说,非常有必要将图片服

浅谈redux-form在项目中的运用

准则 先说一下redux的使用场景,因为如果没有redux,那更不会有redux-form. redux基于Flux架构思想,是一个状态管理框架,其目标是解决单页面应用中复杂的状态管理问题. 日常前端开发中,如果只是做一个简单的运营活动页面,甚至是一些路由稍微复杂一些的SPA项目,都可能用不到redux:只有在页面存在多种数据来源,交互非常复杂的项目中,才有必要引入redux.   redux的作者Dan Abramov指出: "只有遇到 React 实在解决不了的问题,你才需要 redux .