【編者按】由國家金卡工程協調領導小組辦公室主辦，國家金卡工程物聯網應用聯盟、中國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多個高鐵的車站，每一個車站都是大型的甚至是超大型的一個體量，所以在這里面每個站有上萬個點的數據量，所以在這方面我們等于在集團內部強行采用了這樣一個技術，不斷的有一些反饋上來，對于我們的開發團隊有一個新的需求和新的挑戰。所以這個運維的工作在北京南站已經實施，因為北京南站是最先出保的單位，現在其他高鐵的各線各站都在逐步開展使用。高鐵的智能服務平臺，在整個旅服平臺上，像PADS，自動售檢票、查詢、客戶求助等等，所有這些東西都Plug-in這一個中間件的平臺上，能夠起到快速的實施應用，同時也是為了將來的擴展。因為高鐵的線路目前還是高鐵自行成網，按照鐵道部的規劃，既有線會不斷的插入進現有的系統當中來。所以通過CEP引擎為關鍵技術的中間件能夠非常容易的實現快速的擴展。
我們覺得在我們這個行業已經得到了一些初步的甜頭，就是用中間件的辦法，減少重復開發的工作量，可重用我們沉淀的一些相關的技術，相信未來在其他的行業中也會有相應的一些應用和發展，謝謝大家！
