物联网应用中间件及高铁智能应用介绍

物联网应用中间件及高铁智能应用介绍

【编者按】由国家金卡工程协调领导小组办公室主办，国家金卡工程物联网应用联盟、中国RFID产业联盟共同承办的“2013中国国际物联网博览会”于2013年6月4-6日在北京展览馆隆重举行。RFID中国网作为本届博览会指定官方网站，对博览会论坛的精彩内容进行了编辑整理。本文是根据易程科技股份有限公司副总裁邵晓风在物联网创新机遇与商业模式专题论坛上的主题发言整理而成，供业界朋友分享。邵晓风：我们是在这5、6年来一直参与高铁方面的建设，也是集成商之一，我们深刻感受到，我们在核心竞争力方面确实有待于大力的加强这方面的工作。在这方面我们有两个比较切实的体会，就是整个在国家物联网的需求方面如何体现到我们跟高铁相关的事情上，我举两个例子。一个是我们国家高铁从2004年开始引进动车组，到2011年我们的京沪高铁做到了481公里的时速，在这个过程中，我们参与了一个智能列车方面的研发工作。这是一个什么样的情况呢？就是在京沪通车前大概4月份的时候，从枣庄到蚌埠当时叫做京沪的先导段做了实验，当时内部掌握是希望能够做到500公里的时速，当时在这个段上跑到481公里的时候，当时车上的专家和司机说算了，别再加速了，天气不太好。所以就是差10几公里，没有达到预定目标。因此大家就产生了一些思考，因为不可能所有专家都在车上，所以大部分的机车的专家都在列车下面看着这个车的实验。所以很多的实时数据都在车上，如何通过各种办法把这些数据传到下面来，让车下面的专家做决定，后来的这十几公里能不能再往前跑，这是一个很重要的需求。所以智能列车项目目前在国外动车组的基础上，在一列车上又增加了大概1800多个独立的传感器网络，把车辆行驶的实时信息都采集下来传到地面，通过地面来做相应的一些实时的安全方面的、速度方面的、旅客服务方面的一些整合和考虑。我们在参与的过程中，把这么多传感器的数据要进行融合、处理，把一些相关的结论传到地面去，因为传输带宽非常有限。我们另外一个项目组是在做整个高铁运维的工作。因为2008年中国高铁京津线通车了以后，在2011年也出保了，再往下就是大量的维护和运营工作摆在了相关铁路人的面前。在这个过程当中，我们另外一个组也是把车站的轧机、广播导向揭示、自动检票系统，查询机等所有的设备监控起来，也有类似的需求。他们也是为了这个事做的项目，把这些数据作为综合整合，提上来去指导实践。我们有两组团队，根据不同的需求做了相应类似的工作，而且互相之间还没有太多的借鉴和可重复、可重用的关键技术。在两年以前我们就下决心，我们做物联网中间件方面的工作，这是核心竞争力的积累。实际上我们在这方面的工作要能够支撑我们集团公司内部的几个子公司项目组，对于工业界需求的支持。同时也是希望在这个中间件的过程当中摸索出来能够作为产品向广大的物联网产业界开发运营的人员能够使用。我们自己也有体会，做物联网中间件，因为上面远离应用，下面远离传感器，实际上是一个非常枯燥的工作。所以要求团队至少要有24个月的封闭的，不与外界接触的精神做这种物联网方面相关的工作，所以在这方面的工作实际上是跟清华，跟科学院的团队共同参与了一个国家项目，把这个中间件的工作往前推进。这是整个物联网中间件的一个平台。最底层是中科院计算所做的工作，主要是物联网的一个嵌入式的网关，主要解决的问题就是把所有的设备统一接入，上面一点是DDS，这里用的是OMG的平台，这个实时可靠是说在特殊的应用上，比如说军用或者高可靠的一些传输方面由这个平台进行传输。再往上面一层就是所谓的应用服务的中间件，我们主要是把CEP的技术做了深入的研究和实施化的工作。旁边的开发平台和管理平台都是一些插件技术，Plug-in的技术可以热插拔，整个形成一个大的架构。这是刚才提到的整个过程的部署情况，左边就是一个网关的中间件，通过传输的服务进到后面的实时的大数据处理。我们这两年的工作当中有一个重要的体会，我们是觉得SOA过去4、5年以前最热的，如果把这个跟事件驱动和CEP结合起来的话，SOA的工作我们认为就发展得比较完美了，能够快速的解决我们所需要的一些使用的要

求。这张图其实是提到了从下面的数据采集进行预处理以后进行一些事件流的处理，通过模式匹配得到了相应的一些复杂模式的一些研究和事件的输出，通过这种评估了以后，向BPM 的事件驱动流程发布，同时也做事件驱动的人机交互，这里强调的是一种实时应的展现。我们基本上就是把SOA跟EDA和CEP做了这种有意识的一种整合。快速介绍一下我们现在这个产品。现在这个产品基本上算是介乎于β和1.0之间，基本上四大块，这是数据采集部分，把现在已经有的传感器和这种网关基本上需要的时候就加上去，有一个丰富的数据库，这是一些界面，就是怎么样支持各种适配器，怎么样支持各种协议，用图形拖拽的办法串起来，这些都是一些软件编程的办法，包括一些数据的采集，实例的应用等等。再就是处理，包括了预处理，先把事件按照一定的规则进行定义，然后把这个事件的定义作为一个处理，现有的一些函数和我们自定义的函数都支持用户的灵活操作。除了界面操作以外，还可以通过各种形式配置策略，这是文件操作的方式。刚才提到的分发，通过一些规则的配置和过滤，把相应的我们处理过的事件、数据分发到我们事先定好的目的地，这里有很多相关的一些接口、协议的支持。展现我们就是定义了一些展现的样式等等这些数据，这个展现我们现在跟用户在探讨的时候我们也认为实时性是最重要的，所以这个展现本身并不复杂，也并不完整，但是它能够实时的能够把相关的展现数据反馈给我们的监控用户。在整个软件物联网中间件产品当中有这样一些特点，这里面要提到的是高吞吐，因为用了这个引擎，单点每秒可以做26万条的处理，有效的提高了处理能力。在集群方面我们也做了大量的工作，我们认为谁能把集群做好，谁就能够占领一个现在的物联网应用的制高点。微秒级的延迟跟性能，跟刚才的高吞吐是有关的，适配器我们做的工作主要是能够支持热的插拔。我们对于EDA来讲有这样一个体会，我们引用了Event Bus的概念，事件的生产者和事件的消费者都在事件注册的总线上进行订阅，通过事件的接收、校验、转化等等，推送到订阅服务的消费者面前，我们对总线的概念做了相关的工作。这是CEP标准五步的处理法，都在我们这个当中实现了。下面这个就是可以通过模式编排的方式，能够实时的把一些事件进行处理。大家注意，在输出的一块有一条线能够转回到输入，这样能够把一些相对来说较为复杂和更为复杂的工作经过多次的循环能够把它处理掉。在这里面是通过五个层次做了这个处理方法。这是我们做的适配器，所有适配器通过协议的转换、适配层，通过路由的办法把各种的数据进入到引擎层。这是我们从第三方测试的结果，软件评测中心测出来是26万条是单点，我们内部在做测试的时候，实际上是能够做到76万条，当然这个CPU比较大。这个技术现在很热，大家现在都在应用复杂事件引擎的工作，由于它主要是在内存中操作，单点能做到26万条，肯定是在内存当中做操作。有几个致命性的问题，包括持久化的问题，集群化的问题，我们觉得持久化相对来说容易解决，一些状态方面，我们通过数据库，内存数据库等等可以做。但是集群化这个事情是一个相当大的挑战，如果这个问题解决不了，现在所谓的大数据、云各方面都提不上，都做不来。所以在高可用上尽管我们并没有实现，但是我们实现了所谓工作节点的HA，就是等于这一个节点我们已经实现了，我们自己也认为这是一个小的突破。但是光这一个节点不够，所以我们实际上有一些想法，就是在纵向的节点方面，我们怎么样来实现我们做了一些工作。同时在横向方面，这里面因为有时序，把一个复杂的事件我们按照时序分成了两个或者两个以上的流程，所以这个工作我们在设计过程中，还有控制器，实际上我们在控制器上也有一些双机的要求，在管理节点上我们来实现所有的节点管理控制。下面是几个应用，一个是香港高速铁路广深港段香港段现在正在紧锣密鼓的实施，所以我们把这套东西用到了我们香港的实施团队，基本上左边是整个一套管理端，右边蓝色的部分是香港方面的需求，所以中间接入端这一块是用我们的中间件进行实施的。还有就是高铁智能运维，这块东西目前的需求量非常大，因为在300多个车站，我们从2008年开始实施了300多个高铁的车站，每一个车站都是大型的甚至是超大型的一个体量，所以在这里面每个站有上万个点的数据量，所以在这方面我们等于在集团内部强