工业级物联网项目架构设计及实施
早在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有如下特色：
- 基于.NET系统进行驱动和策略开发，由于系统自带垃圾回收机制，不用担心在编写驱动和策略过程中，因内存溢出等原因导致系统当机。
- 传统的组态软件一般对外不提供驱动开发SDK，即使有，大都也采用C++进行开发，对开发者要求比较高。YFIOs和传统组态软件不同，驱动可以采用C#和VB.NET进行开发。且驱动有多种运行模式，不仅系统可以调用，用户策略也可以调用。还可以绑定策略事件，通过触发的方式去执行指定的策略。
- YFIOs的驱动可以动态替换，如果配置了相关的连接变量，只要驱动变量接口兼容就可以替换，这大大降低了系统运行后的维护成本，外围的硬件设备可以根据需要进行替换。
- 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和远程服务器进行通信，用户或医生通过网页查看相关信息，其中医生还可以远程留言并发送到设备。采用组态式的架构最大的好处就是， 由于每个家庭已有的血糖仪或血压计型号不同，设备可以根据对应的传感器型号，选择不同的驱动，可远程部署驱动进行适配。
2. 农业大棚监控系统
系统核心为物联网智能网关，外部连接摄像头、温湿度传感器，通过以太网、Wifi或3G路由器把相关数据推送到服务器。
客户可以通过PC、平板或手机远程监控蔬菜大棚中的作物生长情况。
3. 近海渔业监控系统
通过水质传感器，获取当前水质情况（Modbus RTU通信）；通过摄像头获取当前图片；通过GPS获取当前经纬度；通过GPRS模块把数据传送到远端服务器。
4. 村级污水处理监控系统
物联网智能网关通过RS485/CAN和智能终端连接在一起，智能终端采集各种数据，或控制相关设备运行。网关通过无线路由器或GPRS模块向服务器发送数据，或者接收服务器的控制指令。
Web网页可以查看现场工艺流程界面，工艺报表及设置工艺参数等等。
物联网项目开发的未来发展方向
现在国内外互联网企业巨头，瞄准的物联网领域，大都是民用领域，如智能家居、车联网等等。这些领域的特点就是量大、并且相对统一，每个客户不需要特别的定制（特别是硬件层面，区别不大，个性化最多在软件层面）。
但是在非民用领域，即使类似的项目，往往因为最终客户不同，工艺流程的差异，软硬件也会有相对大的变动。另外和民用产品不同，一是应用环境相对恶劣，二是要求24*7连续运行，对稳定可靠性要求比较高，三是要便于扩展，便于维护。
所以这类物联网项目，未来的发展方向，肯定是首先在可靠性上下工夫，满足长期使用的需求后，就是尽可能提取共用部分，让每个项目的修改量降到最低。