IOT网关,接收sensor数据的总入口,主要是日志,安全防护,流控,协议转换等功能,
图1 IOT网关
之前有提到IOT网关是基于python的twisted框架实现的,初期的时候该IOT网关主要实现的功能是 数据接收和转换功能 和 安全防护 。
数据接收和转换功能 ,这里很简单,拟定好数据交互格式后,IOT网关按照约定好的格式进行解析,然后转发给后端服务进行进一步的处理
安全防护 ,设备的区分主要是依靠烧录到硬件的SN号来实现,SN号包含的信息比较多,如生产批次,设备型号等,受制于厂商我安全防护不能做的非常完善,同时sensor与IOT网关的交互不能非常复杂。安全防护这一块理论上是设备接入要一型一密或者一机一密,协议上还应该启用tls/ssl安全通信协议。
图2 鉴权
安全防护要做ssl这类的安全通信协议的话,要考虑设备厂商实现通信模块能力,设备功耗,设备性能(低端设备cpu性能可能比较差,可考虑对称加密形式),IOT网关也需要引入相应模块。
另外认证从性能方面考虑,后期在设备比较多的情况下,可以加入redis等内存型key-value数据库,缓存设备信息,提高鉴权模块性能。
实践中,我们的sensor基本都是依靠电池供电,因此我们的IOT网关基本是面向短链接(后期我们有监测设备,依靠外部电源直接供电,为长连接),因此在每次发起连接我们都要进行一次鉴权,鉴权通过后,设备方可上传传感器监测数据和设备自身状态。
图3 数据交互流程
这一块的调试工作长达半年左右,才基本稳定下来,主要集中在设备商处除了硬件稳定性,还有在调试中发现传输的字符串乱码(c语言处理问题),沾包(厂商开发人员tcp协议不熟),优化传输效率,关闭cork或者 Nagle 算法(传输包很小)。
因为IOT网关不能主动断连接,理论 *** 作中,IOT网关应该和sensor有心跳协议,保证连接的有效性。设备商在数据流程交互完成后,竟然没有close 连接,直接休眠,导致网关所在服务器的连接的文件描述符一直没有正常释放,后面为了预防这种现象,我开启了 *** 作系统层面的keepalve定时器,回收失效连接(系统默认时间是2小时左右,我缩短了失效时间),理论上来说应该是应用层面去实现心跳协议。
整个IOT网关的设计,是无状态,可伸缩的,单网关在普通型ecs上可轻松达到数百tps。
实现从“数字环保 ”到“智慧环保”的跨越,关键是要在原有“数字环保”的基础上,重点加强感知层与智慧层的建设。一是利用物联网技术,建设实时、自适应进行环境参数感知的感知系统;二是利用云计算、模糊识别等各种智能计算技术,整合现有信息资源,建设具有高速计算能力、海量存储能力和并行处理能力的智能环境信息处理平台,为最终实现“智慧环保”的各项应用服务提供平台支撑与信息服务。
“智慧环保”的基础是物联网。基于“数字环保”平台和物联网技术在环保领域的深入发展,构建环保领域覆盖全国的物联网系统,是实现由“数字环保”向“智慧环保”转化的第一步。在全国选择基础较好的地区开展“智慧环保”试点,建立环境物联监测网络,实时采集污染源数据、水环境质量数据、空气环境质量数据、噪声数据等环境信息,对重点地区、重点企业实施智能化远程监测 ,对各种环境信息进行智能分析,将为“智慧环保”的全面推进奠定良好基础。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)