基于REST架構的離散制造業物聯網平臺

姚明海,陳占省,顧勤龍

(浙江工業大學 計算機科學與技術學院，浙江 杭州 310023)

?

基于REST架構的離散制造業物聯網平臺

姚明海,陳占省,顧勤龍

(浙江工業大學 計算機科學與技術學院，浙江 杭州 310023)

摘要：因離散制造業傳統物聯網系統設計臃腫、擴展性差、復雜度高且系統應用之間耦合性大，使得新應用的引入與集成需要大量的工作，難以滿足企業日益增長的業務需求.提出了基于REST架構風格的離散制造業物聯網平臺.將傳感節點和節點狀態數據抽象成資源，采用REST架構風格設計適合離散制造業的物聯網平臺原型并積木式搭建系統，便于系統整合應用，屏蔽設備異構.最后描述了系統的具體實現細節并將平臺應用于企業生產實踐進行驗證.

關鍵詞：REST；物聯網；離散制造

隨著傳感網絡、嵌入式技術和無線通信等物聯網技術的不斷成熟，離散制造業在信息化過程中也越來越多的引入物聯網系統.物聯網系統的引入，可以有效地幫助企業提高工藝流程的精確度、降低人工成本和提高效率.但企業物聯網地引入是分階段的引入，不同階段引入不用的物聯網應用，而這些不同階段引入物聯網應用都是獨立開發，這些應用通常采用SOA架構進行設計，應用之間接口各異且契約不統一，導致應用之間孤立，信息流通困難，造成了整個系統緊耦合擴展性差、并且復雜度高，同時存在設備異構等缺點[1].

基于這些離散制造業現有的問題，提出了基于REST架構風格的離散制造業物聯網平臺.將傳感節點和節點的狀態數據抽象成資源，采用REST架構風格組建應用，設計適合離散制造業的物聯網平臺原型，便于整合應用，屏蔽設備異構，并描述了具體實現以及驗證.

1相關工作

1.1REST技術

REST(Representational state transfer，表述狀態轉移)是由Roy Thomas Fielding博士于2000年在其博士論文中作為組建大規模分布式超媒體系統的架構風格首次提出的[2].REST架構風格將Web中的所有事物抽象成資源的集合，使用統一的資源標識符(URI)對資源進行標識，利用HTTP動詞(GET，POST，PUT，DELETE等)作為統一接口對資源進行操作，同時客戶端和服務器之間的交互式無狀態的，但是交互的信息具有自描述性.所有的這些特性為構建一個低耦合、低復雜度及高擴展性的Web應用提供了良好的架構約束.

在REST被提出之前，也有一些架構風格也能實現統一接口的特性，如SOAP.但REST具有更好的效率與可擴展性.REST的統一接口是基于HTTP這一廣泛使用的協議的接口；而SOAP使用的是自定義的接口[3-4].REST支持多種的數據交換格式，如XML，JSON，HTML等，但SOAP是一種基于XML的協議.當Web請求需要跨越兩個或兩個以上的Web服務時，可能會引起通信延時，REST Web服務相較于SOAP Web服務能減小這種通信延時[5].

1.2REST與物聯網

目前，已經有一些研究者將REST思想應用在物聯網上，文獻[6]是基于Big Web Services采用SenseWeb將傳感器等設備集成到Web服務中，但Big Web Services最初是為了整合分布式系統異構的API而設計的，會隨著物聯網應用的整合而變得復雜.隨著android系統與智能移動設備以及Arduino與Raspberry Pi等開源硬件的發展，文獻[7-9]將REST物聯網應用到了這些方面.文獻[10-12]將REST應用于物聯網平臺，但未涉及到具體行業業務.文獻[13]將REST應用到了智能農場物聯網，文獻[14]將REST物聯網應用到了地下作業安全方面.不同于以往的工作，實現了一個針對離散制造業基于REST架構風格的物聯網平臺的原型，解耦了離散制造業中不同的物聯網系統，屏蔽了底層網關及節點與平臺之間的異構，并提供了統一的接口.

2離散制造業物聯網總體設計

離散制造業的物聯網系統是一個分層系統，各個層次之間通過統一的REST風格接口進行信息交流，可以有效的降低各層系統之間的耦合性.下面將詳細描述系統的各個層次，并重點描述系統服務平臺的設計思想，以及層次統一接口的設計方式.

2.1離散制造業物聯網體系結構

離散制造業的物聯網體系結構，遵循著傳統物聯網的體系結構,如圖1所示.

圖1　離散制造業聯網體系結構Fig.1　IOT for discrete manufacture system structure

感知設備層：該層的主要職能是采集生產中的實時數據并將這些數據發送到網絡接入層.該層的設備是傳感器節點，可以是Zigbee節點(如XB24-API-001J節點)，也可以是支持REST API的節點.Zigbee節點將采集到的數據傳輸到網絡接入層進行處理.而支持REST API的節點，則可以直接將采集好的數據解析后通過統一的API接口發送到服務平臺層，能夠省去網絡接入層的網關，減少傳輸開銷.但支持REST API節點的價格比較昂貴.

網絡接入層：該層是服務平臺層與感知設備層之間的數據通道.該層的主要職能是收集感知設備層采集的數據，將這些數據進行整合(如數據分類，格式轉化等)，并將整合完成的數據通過以太網轉發到服務平臺層.同時也對外提供REST API，服務平臺可以通過網關提供的REST API，將節點的配置信息發送網關，網關將這些信息轉化成節點的配置命令，進而動態的配置節點信息.

服務平臺層：是整個物聯網體系最重要的部分.服務平臺提供了一系列的統一接口.這些統一接口能夠減小行業應用層系統之間的耦合度，能靈活的為企業提供不同的應用服務；對下層的物理設備，這些統一接口能夠接收不同節點傳送的感知數據，同時也能為用戶提供統一的節點配置方式，實現了不同應用與傳感設備之間的靈活組網，也屏蔽了物理節點的多樣性給平臺帶來的影響.服務平臺的主要模塊如下：

1) 路由模塊，負責處理平臺的通信功能.不論是接收節點或網關的信息，或是為行業應用提供數據，對外REST式Web服務API都是由路由模塊去的驅動.可以說是路由模塊定義了服務平臺的訪問方式.

2) 數據處理模塊，負責整個平臺的數據處理，包括了將接收到的節點數據解析存儲，根據行業應用層的業務需求對數據進行分析、篩選以及序列化后再將數據提供給業務使用.

3) 設備管理模塊，為設備提供了動態的注冊、配置與注銷功能.該模塊通過對外的API，接收設備的信息，不論是節點發送的注冊信息，或是用戶發送的動態配置信息或注銷信息.該模塊會對這些信息進行分析，在對這些信息進行存儲或轉發.

4) 緩存模塊，對數據的查詢結構進行緩存，減小了對數據庫的IO讀寫，優化了應用數據查詢的效率.

5) 日志管理模塊，提供了對平臺故障的記錄及平臺訪問的記錄，為系統錯誤恢復提供了依據與保險.

行業應用層：該層是針對離散制造業行業特點所創建的應用集合.如制造資源計劃(Manufacture resource planning, MRPII)、企業資源計劃(Enterprise resource planning, ERP)和制造執行系統(Manufacture execution system, MES)等系統.這些系統實現了企業生產的自動化與信息化，提高了企業的生產效率.

2.2REST接口設計與實現

REST架構風格將所有的事物都被抽象成資源，需要有為每個資源分配一個URI，來對資源進行標識.

下面以節點實時數據收集這一離散制造業物聯網最基本的功能為例.節點采集的實時數據對應的URI就是http://[DOMAIN]/realtime/nodes/{id}/.URI中的[DOMAIN]表示部署平臺服務器的域名，也可以是該服務器的IP地址.上述的URI分為兩類：

1) http://[DOMAIN]/realtime/nodes/是集合類型，表示整個平臺收集的節點實時數據的集合.

2) http://[DOMAIN]/realtime/nodes/id/是單一類型，該URI帶有特定的唯一id，指定了與該id對應的某一條實時數據.

REST接口除了需要每個資源的URI之外，還需要指定資源的訪問方式.REST架構風格是由HTTP協議驅動的，通過HTTP協議定義GET、POST、PUT及DELETE四種方法對資源進行操作.例如對上述的URI http://[DOMAIN]/realtime/nodes/{id}/進行這四種方法的操作：

1) GET方法：獲取實時數據，對不帶id的URI，獲取到的是整個實時數據集合，帶有id的URI則獲取到了該id對應的特定的某條實時數據.

2) POST方法：該方法只適合http://[DOMAIN]/realtime/nodes/，表示傳感器采集了新的實時數據，向集合中添加實時數據.

3) PUT方法：該方法只適合http://[DOMAIN]/realtime/nodes/id/，表示修改指定的實時數據.

4) DELETE方法：該方法表示刪除需要的實時數據，不帶id則表示刪除所有的數據(是一種比較危險的行為，一般不推薦實現)，帶有id則表示刪除指定的某條實時數據.

同時接口可以攜帶查詢參數，如節點實時數據，根據車間篩選，可以攜帶workshop_id的查詢參數：http://[DOMAIN]/realtime/nodes/?workshop_id=1，之所以采用查詢參數的方式，而不是增加接口目錄的深度，是因為增加接口目錄深度會給整個接口的實現帶來巨大的工作量，同時接口設計復雜度增加，不易維護，靈活度會較差.在需要根據多個條件篩選時，接口的意義會變得模糊.基于這些原因，在后面實現上，將篩選功能放到查詢參數中處理.

3系統實現

電機制造是一個典型的離散制造行業.下面將以浙江迪貝公司物聯網系統的開發部署為例介紹系統的具體實現.

如圖2所示，生產決策者可以根據公司接收到訂單情況安排各個車間的車間生產計劃，每個車間又可以根據車間計劃的制定相應班組計劃，然后車間根據這些班組計劃進行生產.對每個車間的生產的數據進行采集，對這些數據進行統計分析，輸出到看板反饋給生產決策者，決策者可以根據這些反饋，對生產過程與計劃進行掌控，必要時可以進行調整，以對生產資源優化.

圖2　電機生產計劃流程Fig.2　Process for plan of motor manufacture

3.1路由與數據處理模塊

整個平臺架構利用了Python下Django框架進行了實現，Django是一個采用了MVC模式并有著強大路由功能的高效Web開發框架，也包含了類似緩存模塊與日志管理模塊等常見模塊；并采用了Django REST Framework框架作為補充，在Django的基礎上能夠高效方便的搭建REST API同時提供了各種數據格式的序列化，提高開發效率.

在整個平臺的實現中，各個功能是由一個個的Django app(應用)進行積木式搭建而成的，一般每個app中都包含了這三個文件：models.py、views.py與urls.py，分別對應于數據表的映射模型、視圖顯示控制(在API中用來處理API的具體實現)以及路由配置.系統項目組織結構如圖3所示.

圖3　項目組織結構Fig.3　Project organization structure

將整個平臺取名為miot(Motor things of internet)，由于系統僅用于內網，這里將平臺對應的域名為一級域名dibei.com/，這是所有程序的對應入口，也是資源URI根目錄.之后對應的app分為兩類.

一類是專門用來處理不同物聯網web應用的，對應于上圖的apps以及之后的分支.如制造執行系統對應于上圖名為MES的app，其訪問地址是mes.dibei.com這個二級域名開頭的部分.另一類是專門提供對外的統一接口的，對應于圖3的apis以及之后的分支.其訪問方式都是www.dibei.com/api/為前綴，之后的分支則表示資源的具體描述.如realtime app表示實時數據的目錄，用以存儲實時數據這一類型的資源，如節點信息nodes/.

3.1.1通過路由配置資源接口的訪問路徑

每個app的路由會根據api路徑來處理.若當前目錄不是路徑的終點，則將訪問轉到下一目錄，當到達api路徑的終點，則將該api的訪問引導到接口的具體實現中(及對應的Views中).

http://www.dibei.com/api/realtime/nodes/{id}/接口的訪問顯示在miot app中將訪問轉到apis app中url(r'^api/', include('apis.urls'))，在apis中又將訪問轉到realtime app中url(r'^realtime/', include('realtime.urls'))，在realtime app中，到達了api路徑的終點，調用views.py中接口的具體實現url(r'', include(routerRealTime.urls))，routerRealTime.register(r'^nodes', NodedataViewSet).路由的訪問流程如圖4所示.

圖4　路由訪問流程Fig.4　Process of route access

3.1.2實現接口功能完成數據處理

在views中實現接口的具體操作，利用Django REST Framework快速的實現了接口的四個操作動作，并為接口的輸出數據做了序列化.如果需要應付復雜的業務，也可以很方便在ViewSet類中覆寫GET、POST、PUT與DELETE四個操作動作來完成復雜的業務.接口快速實現的代碼片段如下：

#文件realtime/views的接口具體實現

#利用Django REST Framework快速的序列化與反序列化節點信息數據

class NodedataSerializer(serializers.ModelSerializer):

class Meta:

model=Nodedata #引入數據表映射模型

fields=('id', 'workshop_id', 'gateway_id',

'node_id', 'node_type', 'data_value',

'upload_date', 'status', 'feedback')

#利用Django REST Framework快速的實現

#api/realtime/nodes/[id]接口GET、POST、PUT及DELETE四個動作

class NodedataViewSet(viewsets.ModelViewSet):

queryset=Nodedata.objects.all()

serializer_class=NodedataSerializer

#將最后的nodes/[id]路徑與具體實現注冊到路由

routerRealTime=routers.DefaultRouter()

routerRealTime.register(r'^nodes', NodedataViewSet)

部分API的訪問方式如圖5所示.

圖5　接口訪問方式Fig.5　Access methods of interface

3.2設備管理模塊

由于智能設備的發展普及，以及Arduino與Raspberry Pi等開源硬件的發展，網關或節點的功能越發的強大，可以在網關或者直接在節點中布置一個小型的Web服務，這樣便可以使用統一的REST接口通過網關管理節點或者直接管理節點，同時實現了關注點分離，將節點的配合方式從服務平臺中轉移到節點自身，避免了由于節點種類的增加，導致設備管理模塊的復雜度的增長.

在節點連接上物聯網平臺時，會向http://www.dibei.com/api/realtime/sensers/[id]/發送POST請求，并將自己的信息注冊到管理平臺，該信息必須包括節點自身的id與ip地址.

當要修改某個節點的配置時，可以根據該節點的id，向http://www.dibei.com/api/realtime/sensers/id/發送PUT請求，此時在該接口PUT請求對應的實現中，需要進行一個轉發機制，根據該節點注冊到服務平臺的ip，將新的配置信息轉發給該節點.服務平臺實現節點配置信息轉發功能的代碼片段如下：

#文件realtime/views

#對Sensers的PUT請求進行轉發處理

#…

url='http://'+ipAddress+'/api/senser/config/

req=urllib.request.Request(url,data)

response=urllib.request.urlopen(req)

#…

同樣的道理，對節點進行注銷，也只需要發送DELETE請求到對應的http://www.dibei.com/api/realtime/sensers/id/接口，并在服務平臺上對應的轉發該請求即可，設備管理方式如圖6所示.

圖6　設備管理方式Fig.6　Method of equipment management

動態的設備管理方式可以對節點進行重復利用，以適生產線的重組.

3.3結果展示

REST架構風格的物聯網平臺能夠為應用提供服務數據.通過統一接口，應用能夠快速方便地獲取所需的數據，不必考慮平臺的限制，從而為跨平臺的應用實現提供了簡便的基礎.下面以電機生產中高沖這個工序為例：

在每次高沖動作完成時，設備的繼電器會產生一個脈沖信號，表示動作完成.采用Arduino UNO R3作為傳感節點處理單元，傳感節點到智能網關之間采用ZigBee作為傳輸協議，傳感節點傳輸模塊采用了Digi公司XBee模塊.而智能網關架構在Tiny4412開發板上，采用Android操作系統.傳感節點采集每一次的高沖動作，按照節點設定的比例轉化成對應的產品數，數據從傳感節點經智能網關通過統一接口上傳至服務平臺，車間看板程序通過統一接口向服務平臺請求整合過的生產數據，展示了生產的實時數據.圖7的車間看板Android應用展示了高沖工序的實時生產數據.

圖7　車間看板android應用Fig.7　Android app for workshop board

4結論

提出了基于REST架構風格的離散制造業物聯網平臺，將REST架構風格應用到了離散制造業的物聯網系統中，構建一個松耦合，復雜度低且高效的物聯網平臺，可以將各種不同的應用以積木的方式搭建，同時提供的統一接口為各種行業應用的跨平臺開發提供了便捷的基礎，更好的為離散制造業的生產提供信息化支持.但目前平臺的研發還處于探索實驗階段，應用中，對于生產線的節點部署并未對所有的生產過程進行部署.服務平臺所有的緩存模塊是Django自帶的模塊，而日志管理模塊使用了Apache HTTP Server與Django的自帶模塊，還未在這些基礎上進行優化.這些問題有待進一步的研究和解決.

參考文獻：

[1]秦海平,王美清.離散制造企業應用集成開發研究[J].制造業自動化,2010(7):29-33.

[2]FIELDING R T. Architectural styles and the design of network-based software architectures[D]. California：University of California at Irvine,2000.

[3]毛力銳,蔡鴻明,徐博藝,等.基于REST面向資源的企業集成平臺框架[J].計算機工程,2010,36(2):254-256.

[4]馮新揚,沈建京.REST和RPC:兩種Web服務架構風格比較分析[J].小型微型計算機系統,2010(7):1393-1395.

[5]陳海明,崔莉,謝開斌.物聯網體系結構與實現方法的比較研究[J].計算機學報,2013,36(1):168-188.

[6]PAUTASSO C, ZIMMERMANN O, LEYMANN F. Restful web services vs. big'web services: making the right architectural decision[C]//WWW '08: Proceedings of the 17th International Conference on World Wide Web. New York: ACM,2008:805-814.

[7]CHRISTENSEN J H. Using RESTful web-services and cloud computing to create next generation mobile applications[C]//OOPSLA '09: Proceedings of the 24th ACM SIGPLAN Conference Companion on Object Oriented Programming Systems Languages and Applications. New York: ACM,2009:627-634.

[8]GUINARD D, FLOERKEMEIER C, SARMA S. Cloud computing, REST and mashups to simplify RFID application development and deployment[C]//WOT '11: Proceedings of the Second International Workshop on Web of Things. New York:ACM,2011:9-15.

[9]KOVATSCH M, LANTER M, DUQUENNOY S. Actinium: a RESTful runtime container for scriptable internet of things applications[J]. International Conference on Internet of Things,2012,567(1):135-142.

[10]ZHANG Xinshuang, WEN Zhigang, WU Yuexin, et al. The implementation and application of the internet of things platform. based on the rest architecture[J]. Business Management & Electronic Information International Conference on,2011(2):43-45.

[11]程冬梅,王瑞聰,劉燕,等.基于REST架構風格的物聯網服務平臺研發[J].計算機工程與應用,2012,48(14):74-78.

[12]LAINE M. RESTful web services for the Internet of things[EB/OL]. [2015-05-09]. http://media. tkk. fi/webservices/personnel/markku_laine/restful_web_services_for _the_internet_of_things. pdf.

[13]SIVAMANI S, KWAK K, CHO Y. A design of Web-based services using RESTful API for vertical farm[J]. Life Science Journal,2014,11(7):763-767.

[14]CHENG Bo, CHENG Xin, CHEN Junliang. Lightweight monitoring and control system for coal mine safety using REST style[J]. Isa Transactions,2015,54(1):229-239.

(責任編輯：陳石平)

Research on the internet of things platform of discrete manufacturing

enterprises based on REST architecture

YAO Minghai, CHEN Zhansheng, GU Qinlong

(College of Computer Science and Technology, Zhejiang University of Technology, Hangzhou 310023, China)

Abstract:For the problems of bloated design, poor scalability, high complexity and tight coupling between application systems in the internet of things of traditional discrete manufacturing, the import and integration of new applications requires a lot of work, It is difficult to meet the growing business needs of enterprises. An internet of things platform for discrete manufacturing enterprises based on REST-style architecture is presented. The sensor and their status are abstracted as resources. The REST architecture is used to construct block system in order to facilitate the integration of applications and shield heterogeneity of devices. Finally, specific implementation details of the system are described and the platform will be applied in the enterprises for verification.

Keywords:REST; internet of things; discrete manufacturing

文章編號：1006-4303(2015)04-0425-06

中圖分類號：TP393

文獻標志碼：A

作者簡介：姚明海(1963—)，男，浙江嘉興人，教授，研究方向為模式識別與智能控制，E-mail：ymh@zjut.edu.cn.

基金項目：國家自然科學基金資助項目(61070113)；浙江省科技廳重大科技專項(2012C01035-8)

收稿日期：2013-02-08