物联网建设中通讯互联层的终极解决方案

1.自我介绍

本人已经工作10年,一直在工业领域。在一线干过实施,下过矿井;干过项目,带过团队;干过软件研发,出过产品;干过项目群管理,售前和市场也接触过;期间在纯软件公司也干过将近两年的时间,熟悉软件开发流程与管理。虽然没有取得多大成绩,也算经历丰富了。

互联网“行业”如火如荼的发展,曾经也想过转行去做“互联网”,奈何犹豫太久,已然提不起太多兴趣。凭借当年的沉淀与积累,有个半成品的框架,在工作索然无味的情况下,毫不犹豫的投身到物联网框架的开发与产品化的进程中。别人都说物联网的时代来了,如果真的是这样,也不知道是自己的选择好,还是命好。

这方面的工作纯属个人爱好,业余时间在干,一般晚上21点到23点是自己的第二个工作时间。这两年积极的投身到新的框架开发中,提高性能、统一接口、跨平台……等方面的工作。也做了自己的基础硬件产品,智能网关。

有人会问,那你正式工作是干什么的?在某集团公司工业版块负责大数据建设的相关工作。在没有大数据、云服务概念的时候,做过远程E服务相关的项目。说实话,对于传统行业来讲,是很困难的一件事。但是作为企业来讲,要么等死,要么在改变中死,完全在于自己的选择。

2.占领大脑和丢了脚

不知道从什么时候,物联网、大数据、云服务、云计算……等一批概念流行起来。大厂都在争夺高制高点,大数据、云服务、各种标准……,做这些事情都很有意义。但是我在想,大家都去占领大脑,脚就不重要了嘛?!显然不是,应该是同等重要。华为设备部、中兴仪器仪表……对于基础物联层,也是很头痛的一件事,这是大厦的根基,特别是工业领域。所以,我坚信对于我们的框架有很大的市场应用空间,创造的直接价值那是另外一回事。

3.物联的现实困难

对困难理解的前提是对现实世界的认知,有些传统制造业都不具备物联的基础条件,更谈不上物联网、智能制造、智能工厂,但是至因为落后,才有广阔的市场空间。就算有物联的基础,条件比较落后,底子比较薄,面临四个多样性:设备多样性、协议多样性、通讯机制多样性、数据多样性。这就是我们面临的问题,难道问题有多大吗?为了生存,企业都说能做。但是结构化的多样性问题,要用结构化的手段或框架来解决,这是各方面保障的前提。

4.效率与成本

接触一家上海公司,有专人负责网关层的数据采集,有专人负责服务(云)端的对接,不太稳定、经常出现问题。解决细节问题,不能用细节的思维方式去解决,而是要有更广阔的思维、结构化思路才能够彻底的、更好的解决问题。网关层、服务端是否可以使用同一套框架?并且框架之间是否可以无缝对接?如果可以实现,应用同一套框架,开发效率会提高,用人成本和时间成本会降低。好的组织结构、好的框架总之要解决效率和成本,否则没有任何价值。

5.逆向思维

大厂都在搞云平台、协议标准……,当然他们有资本和实力这样搞,软件用他们的、硬件用他们的,对于他们来讲,养这么多人,反而成本是最低的。他们奉行一流企业定标准,用这种思维模式去整合资源,竞争比的就是占领资源的多少。我们认真考虑一下,对于传统企业来讲,本来生存就很困难,和房地产、互联网拿投资的没法比,他们有能力一下子完全统一化的更新换代嘛?!参加上海工业博览会,也进行了市场调查,简直是开玩笑。我们再认真考虑一下,用框架性的东西去解决设备多样性、协议多样性、通讯机制多样性、数据多样性的问题,在物联网和集成系统的建设中是否也是整合资源的一种手段?!先解决企业互联监控的问题,再解决企业标准化的问题,这样是否也是一种思维模式?!是的,我们就先这样干!

5.智能网关,跑Windows 10 IOT和Ubuntu Mate

网关在物联网和集成系统建设中是重要的一个环节,实现数据的初步整合(采集),再进行数据的转发,形成体系层次清晰的级联网络系统。市场的网关大至分为两类:纯硬件接口的转换、搭载操作系统的小型机。当然也有在硬件基础上搭载自己的软件框架,但是不多见。在我们的智能网关上可以实现搭载我们ServerSuperIO物联网框架,使软件和硬件无缝结合,设备驱动的接口统一,可以开发一套驱动跑在不同的嵌入式操作系统上,Windows 10 IOT和Ubuntu Mate,对于系统建设的方案选择更灵活。

智能网关的硬件配置:

l  四核1.2GHz Broadcom BCM2837 64位CPU。

l  1GB RAM。

l  板载BCM43143 WIFI和蓝牙低功能耗(BLE)。

l  40引脚扩展GPIO。

l  4个USB接口。

l  全尽寸HDMI,并且转VGA接口。

l  微型SD卡端口,用于运行操作系统和存储数据的介质。

l  升级切换的微型USB电源,高达2.5A。

l  可搭载的操作系统:Ubuntu Mate、Windows 10 IOT。

智能网关实体机照片:

6.SuperIO到ServerSuperIO发展历程和解决的实现问题

      SuperIO&ServerSuperIO最早的雏形于2010年开始开发,当时主要是解决公司内部硬件产品众多、协议众多、以前的软件经常出问题、维护成本高、搞集成系统时各方面都很累。经过两三年的发展,确实解决了公司内部的产品体系问题,所有硬件产品都可以挂载到平台下运行。离开公司之后,感觉这个平台从代码、应用等方面还有很大发展空间,2014年逐步产品化后才形成了SuperIO(SIO)这个平台。

但是SIO也只是解决了设备驱动(众多协议)插件式挂载的问题,不过只限于运行在Windows系列操作系统下,一般性的PC机和工控机上数据采集完全没有问题。但是在运行效率方面还有很大提升空间、设备驱动的接口还可以进一步标准化(为了各层级都可以应用)、跨平台运行必须攻克、设备(驱动)之间信息交互与控制必须实现、框架在不同层级应用的级联与控制必须实现、多服务实例的应用等等,一系列的框架和技术性问题还可以进一步完善。从整体物联网建设的框架性方面考虑,从2015年初开始,基于SIO的核心思想重新开发新一代物联网框架,也就是现在的ServerSuperIO(SSIO)框架,经过两年多的发展,搭载在智能网关的基础上,可以形成综合性的解决方案。

7.一套设备驱动,支持多种IO通讯

不管是zigbee、wifi、有线网络,还是RS485、RS232、RS422,总之主要分为两种硬件接口:网口和串口。至于OPC协议,可以用SSIO服务接口的形成间接实现,形成服务插件的一部分。如果不结构化的设计IO,网口和串口独立存在,随着产品越来越多,是很头痛的一件事,也不一定运行稳定。对于ServerSuperIO框架,在此基础上开发一套设备驱动可以分别实现通过网口或串口与硬件设备(传感器)进行交互,非常方便。有人认为通讯很简单,其实如果把众多问题都考虑进去,那么将变得很复杂。也有很多纯网络通讯框架,业务场景、通讯机制的不同,纯网络通讯框架也未必能够完全的适用于现场环境。根据多年的工作经验,针对SSIO增加了通讯机制与应用场景,参见:《连载 | 物联网框架ServerSuperIO教程》1.4种通讯模式机制

示意图如下:

8.一套设备驱动,统一接口,多种平台挂载运行

针对ServerSuperIO框架的设备驱动接口进行标准化设计,另外针对ServerSuperIO框架本身进行了跨平台运行的移植工作,所以一次开发设备驱动,可以在多种平台下挂载运行。现在支持的平台包括:Windows xp SP3以上的版本操作系统(包括Server)、Windows 10 IOT嵌入式操作系统、Ubuntu&Ubuntu Mate操作系统。

示意图如下:

9.物联通讯的级联

如果单单是采集硬件的数据与控制,也只能算是本地的系统,但是在物联网和集成系统建设中,必须形成体系化、网络化框架。所以ServerSuperIO在采集本范围内的数据信息与控制外,还要形成与上一级的ServerSuperIO进行数据交互,以及接收下一级的ServerSuperIO的交互数据,那么ServerSuperIO之间就形成了级联的关系,主要完成两大职责:数据的级联上传和反向控制,进而对设备本身进行级联控制。

结构示意图如下:

10.设备之间的通讯、控制

采集与控制单个设备,在实际应用中还远远不够,还要能够设备与设备之间进行信息传递与控制,并且返回给发送控制源设备确认信息。例如:在监测流量计严重报警的情况下,是否应该调节或控制液体源头的阀门。类似的例子很多。

在ServerSuperIO最新的3.1版本中(还没有发布),支持设备向另一个设备发起传递信息和控制后,被控制设备是否立即返回确认信息,还是自主异步决定返回确认信息。增加了异步返回确认信息的功能,因为控制命令只是发给了另一个设备驱动,设备驱动还会进一步与实际的硬件设备进行交互,与实现硬件交互成功后,再返回确认信息给发起的源设备驱动。

示意图如下:

11.与云端的交互、控制

ServerSuperIO提供了服务驱动的接口,一些除设备驱动类的功能以外,都可以以服务驱动的方式存在,例如:多设备采集的数据的融合模型计算、与其他平台或上层进行交互等等,在此仅以与服务端进行交互为实例进行介绍。与设备驱动之间的交互与控制不同的是,设备驱动主动把采集的数据信息传递给服务驱动,服务驱动与云端进行交互,在接收云端指令后,发起传递信息或控制设备驱动,设备驱动再返回确认信息给服务驱动。

示意图如下:

12.未来的规划

从大环境来讲,肯定是有很广泛的应用;从本公司来讲,将来在工业基础物联层面,肯定也会用的上;从个人兴趣来讲,也乐意能够继续做这方面的工作,当然是除正式工作之外。

从ServerSuperIO本身来讲,3.1版本(未发布)对代码进行优化以及增加了异步返回确认信息的交互能力。后期会增加对数据安全方案的验证机制,以保障在工业领域应用数据交互与控制的安全性。另外从体系结构来讲,以ServerSuperIO框架为基础,增加云端的建设能力,例如:数据分布式持久化等。从嵌入式应用为讲,要增加远程可配置能力等。

13.结束语

在现在的社会,长期坚持做一件事很不容易,做成产品级以及配合体系方案更不容易。慢慢往下走吧,希望机会会眷顾那些踏实、实干的人。天道酬勤!!!



1.[连载]《C#通讯(串口和网络)框架的设计与实现》

2.[开源]C#跨平台物联网通讯框架ServerSuperIO(SSIO)介绍

2.应用SuperIO(SIO)和开源跨平台物联网框架ServerSuperIO(SSIO)构建系统的整体方案

3.C#工业物联网和集成系统解决方案的技术路线(数据源、数据采集、数据上传与接收、ActiveMQ、Mongodb、WebApi、手机App)

5.ServerSuperIO开源地址:https://github.com/wxzz/ServerSuperIO

物联网&集成技术(.NET) QQ群54256083



连载教程:

1.4种通讯模式机制
2.服务实例的配置参数说明
3.设备驱动介绍
4.如开发一套设备驱动,同时支持串口和网络通讯
5.轮询通讯模式开发及注意事项
6.并发通讯模式开发及注意事项
7.自控通讯模式开发及注意事项
8.单例通讯模式开发及注意事项
9. 协议过滤器,解决一包多发、粘包、冗余数据
10.持续传输大块数据流的两种方式(如:文件)
11.实现设备(驱动)与设备(驱动)交互和级联控制。
12.服务接口的开发,以及与云端双向交互
13.自定义视图显示接口开发,满足不同的显示需求
14.配制工具介绍,以及设备驱动、视图驱动、服务实例的挂载



物联网建设中通讯互联层的终极解决方案

时间: 2024-12-28 20:56:37

物联网建设中通讯互联层的终极解决方案的相关文章

数据仓库建设中的数据建模方法(转)

简介: 本文的主要内容不是介绍现有的比较流行的主要行业的一些数据模型,而是将笔者在数据仓库建设项目中的一些经验,在这里分享给大家.希望帮助大家在数据仓库项目建设中总结出一套能够合乎目前业界规范的,满足大部分行业数据仓库建设标准的一种方法. 所谓水无定势,兵无常法.不同的行业,有不同行业的特点,因此,从业务角度看,其相应的数据模型是千差万别的.目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR,这两家公司的除了能够提供较为强大的数据仓库平台之外,也有各自的针对某个行业的数据模型. 例如,在

浅谈数据仓库建设中的数据建模方法

所谓水无定势,兵无常法.不同的行业,有不同行业的特点,因此,从业务角度看,其相应的数据模型是千差万别的.目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR,这两家公司的除了能够提供较为强大的数据仓库平台之外,也有各自的针对某个行业的数据模型.       例如,在银行业,IBM 有自己的 BDWM(Banking data warehouse model),而 NCR 有自己的 FS-LDM 模型.在电信业,IBM 有 TDWM(Telecom Data warehouse model)

嵌入式中通讯协议的设计(转)

源:嵌入式中通讯协议的设计 说得太精彩了! 公司里做项目,嵌入式系统大大小小,到处都是.因为都是一个系统里的,所以都需要通讯,既然通讯就涉及到协议问题. 谈及协议,很多工程师觉得协议的设计相对简单,主要是报文的设计.大多数时候,协议的应用场景简单,没有复杂的交互.这么做的确也是没什么太大的问题.然而,就是这么简单的场景,仍有一些协议会在实际中发生意想不到的问题.归根结蒂,还是没有把握协议涉及的规律.下面我们简单的聊聊协议设计的规律. 协议设计中面临的问题: 1.设计者大多数情况下,从应用出发,仅

快印客人工智能名片,拨开销售管理中的7层“迷雾

人工智能名片,拨开销售管理中的7层"迷雾 在这个新陈代谢极快的时代里,中小企业要想从激烈的市场竞争中脱颖而出,并不容易.诸如许多中小企业在经营.管理过程中,表面看是缺人才.缺客户.缺生意,实际上是缺培养机制.缺管理--以下是快印客总结的中小企业经营的七大痛点.看看你被戳中了几条?作为最受销售员们喜爱的销售利器,快印客人工智能名片又是如何帮助企业解决销售管理难题的呢? 痛点一 表面缺生意,实际缺思路 在移动互联网时代,你的企业还在疯狂砸金投电视广告?或者烧钱去投水很深的信息流广告?一般大企业可能耗

Python中OSI七层模型

OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯,因此其最主要的功能就是帮助不同类型的主机实现数据传输 . 完成中继功能的节点通常称为中继系统.在OSI七层模型中,处于不同层的中继系统具有不同的名称. 一个设备工作在哪一层,关键看它工作时利用哪一层的数据头部信息.网桥工作时,是以MAC头部来决定转发端口的,因此显然它是数据链路层的设备.具体说:物理层:网卡,网线,集线器,中继器,调制解调器 数据链路层:网桥,交换机 网络层:路由器 网关工作在第四层传输层及其以上

网站建设中前端常用的jQuery+easing缓动的动画

网站建设中前端人员利用jQuery实现动画再简单不过了,只是要实现更酷的效果还需要插件来帮忙,easing就是一款帮助jQuery实现缓动动画的插件,经过试用,效果很不错! 下载该插件:jquery.easing.1.3.js jquery.easing.compatibility.js 该插件美化排版后是130行左右,压缩后更小.这个插件弥补了jquery里面的动画效果的不足,是其动画效果更加强悍. X轴表示时间,Y轴表示的是动画效果的变化.查看这些曲线变化,更利于掌握这个插件的效果. 插件支

OVS中对于用户层和datapath层的多个通道利用epoll进行控制

这里先暂时记录下代码流程,有待完善. static int construct(struct ofproto *ofproto_) { struct ofproto_dpif *ofproto = ofproto_dpif_cast(ofproto_); const char *name = ofproto->up.name; int max_ports; int error; int i; error = dpif_create_and_open(name, ofproto->up.type

六:二叉树中第k层节点个数与二叉树叶子节点个数

二叉树中第k层节点个数 递归解法: (1)如果二叉树为空或者k<1返回0 (2)如果二叉树不为空并且k==1,返回1 (3)如果二叉树不为空且k>1,返回左子树中k-1层的节点个数与右子树k-1层节点个数之和 代码如下: int GetNodeNumKthLevel(BinaryTreeNode *pRoot, int k) { if(pRoot == NULL || k < 1) return 0; if(k == 1) return 1; int numLeft = GetNodeN

Quick-cocos2d-x3.3 Study (十四)--------- 遍历 TiledMap 中的对象层,并取得所有坐标

遍历 TiledMap 中的对象层,并取得所有坐标 1 -- 将心心添加到背景层中 2 function BackgroundLayer:addHeart( ) 3 -- body 4 -- getObjectGroup 方法从地图中获取到指定的对象层(也就是个 ObjectGroup 对象组对象), 5 -- 对象组 ObjectGroup 中包含了多个对象, 6 -- 所以我们可以通过 getObjects 方法从 ObjectGroup 中获得所有的对象. 7 -- objects 在这里