DAQ-Middleware: Data Acquisition Middleware based on Internet of Things

Transcription

1 DAQ-Mddleware: Data Acquston Mddleware based on Internet of Thngs Zhjn Qu, Zhongwen Guo, Shua Guo, Yngjan Lu and Yu Wang Ocean Unversty of Chna, Qngdao, Shandong, Chna Unversty of North Carolna at Charlotte, Charlotte, North Carolna, USA Tayuan Unversty of Technology, Tayuan, Shanx, Chna Emal: Abstract Wth envsoned Industry 4.0, the Internet of Thngs (IoT) has been wdely used n many felds. Unfortunately, the format, type, and access methods of data sources n dfferent areas are dverse, and ths makes upper development complex and low effcency of data acquston. To address ths ssue, a novel scalable data acquston mddleware (DAQ-Mddleware) s proposed n ths paper. Through the desgn of the archtecture model, and the standardzaton of access methods and nterfaces, DAQ-Mddleware mplements fast access to heterogeneous data sources and provdes standardzed formatted sensng data for IoT applcatons. Furthermore, n order to mprove the rate of sensor data acquston, we also propose a parallel data acquston algorthm and an acquston effcency optmzaton heurstc method. Va the development and applcaton of proposed DAQ- Mddleware, ths mddleware has been valdated n the aspect of the ratonalty, feasblty, development effcency and data acquston effcency. Our results confrm that DAQ-Mddleware can acheve the logcal solaton between the data sources and the IoT applcaton systems, satsfy the automatc fast access to the heterogeneous data sources, reduce development cost, and enhance data acquston effcency. I. INTRODUCTION Wth the development of pervasve computng, RFID, and sensor networks, the applcaton and development of IoT technologes have been promoted. In dfferent areas, IoT through the connecton of ntellgent devces acheves the global sensng data acquston, storage, analyss, and dsplay. A typcal IoT system s a large, dynamc, and scalable sensor network that enables data dentfcaton and acquston from ntellgent devces, RFID tags, computers, and moble devces [1]. These devces generate large amounts of real-tme-seralzed data accessng to the IoT through a hgh-speed network. At the same tme, the data sources also nclude the exstng databases and data fles, whch can realze the data ntegraton of the exstng IoT systems. Therefore, the IoT data sources nclude two parts: 1) the data obtaned by the sensng devces; 2) the exstng databases and data fles. At present, no matter what knd of data sources, there are always dversty ssues, such as dfferent data acquston unts, data types, communcaton protocols, access methods, and so on are used by dfferent companes. The developers have to develop varous data acquston systems for dfferent combnatons of accessng sensor devces, and ths ssue makes the development of IoT systems complcated. Meanwhle, dfferent data acquston systems are desgned to be used n dfferent scenaros, so they cannot smultaneously obtan data for multple data sources. Performng data acquston sequentally results n lower effcency. Obvously, t s alway challengng to make dfferent nstrument manufacturers and exstng databases and data fles to use a unfed communcaton protocol and data format. In terms of IoT system desgn, many related studes have been conducted. Most of them manly focus on the overall archtecture desgn [2] [4] and data dsplay method [5] [8] n IoT systems. There s no much study about the dversty of the data sources format. In the research area of dstrbuted systems, the relevant scholars have desgned dfferent archtectures or algorthms for data acquston system. Kovac [9] propose the use of vrtual nstrument technology and GPIB nterface to acheve the acquston of sensor data, whch ncreases the convenence of access to the sensor devces to a certan extent. Qu et al. [10] propose a hgh performance data acquston algorthm based on the analyss of dynamc delay characterstcs of data acquston. But ths algorthm s only sutable for specfc sensng devces, and does not apply to multple data sources. Untl recently, Qu et al. [11] and Hu et al. [12] propose the concept of Complex Vrtual Instrument System to handle multple data sources. However, ther archtectures and applcaton areas are stll restrcted. The Open GIS Consortum (OGC) [13] proposes to use Programmable Underwater Connector wth Knowledge (PUCK) protocol to ntegrate the physcal devces automatcally. The system uses a computer to put the confguraton nformaton nto PUCK model, and connects ths model to the physcal ocean observng nstruments, whch can realze automatc nstruments access. Although ths has solved lots of problems n system ntegraton and development, t must modfy the ocean observng nstruments and add PUCK model. Dong so ncreases the cost of nstrument manufactures as well. In summary, none of the solutons above can settle comprehensvely all the mentoned problems n data acquston of IoT systems. Though the requrements of data analyss and dsplay are very dfferent n dfferent IoT systems, ther data acquston methods are not vary greatly dependng on the applcaton doman. In ths paper, accordng to the experences of partcpaton n the development of IEEE 1851 and IEEE 2402 nternatonal standard, we propose a data acquston mddleware based on IoT: DAQ-Mddleware. DAQ-Mddleware

2 Response Request D A Q Acquston Layer Sensng Layer Data source Sensors Applcaton Layer Navgaton Applcaton system Management Layer Curve Lst Statstc Prnt Input Confg Acquston module Interfaces wth applcaton systems Acquston man program Acquston module DSDF DSDF DSDF DSDF Communcaton nterfaces(rs485/rs232/ethernet...) Web Servce/MQ/FTP Data Storage Standard Interface Commands Communcaton protocol ASCII Bnary Code Fg. 1: Herarchy model of IoT. Communcaton nterfaces(rs485/rs232/ethernet...) Sensng nstrument Sensng nstrument Web Servce MQ FTP Sensor S1 Sensor S2 Sensor S3 Databases or Fles s located between sensng devces and operatng system. DAQ-Mddleware not only can mprove the effcency of data acquston (usng parallel data acquston algorthm and effcency optmzaton method), but also acheve an automatc access to varety of heterogeneous data sources n IoT system. DAQ-Mddleware can provdes sensng data for IoT system of the dfferent areas through the standardzed data nterface. In summary, the major contrbutons of ths paper can be summarzed as follows. We desgn a scalable IoT data acquston mddleware, DAQ-Mddleware, whch supports not only the sensng devce s nterfaces for the seral port, network port, GPIB and USB, but also the nterfaces of varous data type databases and data fles for FTP, Web Servce and MQ. Through the archtecture desgn, DAQ-Mddleware acheves a new data source for automatc access, support for dynamc addton of front-end data sources wthout re-programmng. Meanwhle, a unfed defnton of the data descrpton format hdes semantc descrpton n the hardware level, so that t s easer for developers to development systems. DAQ-Mddleware uses a newly desgned parallel data acquston algorthm and an effcency optmzaton heurstc to mprove the data acquston effcency, system stablty, and data accuracy. The standard back-end nterfaces of DAQ-Mddleware are defned, ncludng the control command nterface, the data request nterface and the data return nterface, whch can facltate IoT ntegraton. The rest of ths artcle s organzed as follows. Secton 2 presents the archtecture model of DAQ-Mddleware. Secton 3 provdes the detaled desgn of DAQ-Mddleware. Secton 4 shows the applcaton development cases wth DAQ- Mddleware and the analyss of ts performance. Fnally, conclusons are proposed together wth an ndcaton of drectons, whch deserve further work, n Secton 5. Fg. 2: Archtecture of DAQ-Mddleware. A. IoT Herarchy Model II. ARCHITECTURE MODEL Standardzed nterface Recently, many scholars put forward the object herarchy model of IoT accordng to the dfferent requrements, n order to facltate the development and mantenance of IoT systems. Even though dfferent herarches of IoT has been proposed, the man functonal modules are smlar. Accordng to [6], the object herarchy model s dvded nto four layers (sensng layer, acquston layer, management layer, and applcaton layer), as shown n Fgure 1. Each layer s ndependent of each other, and only through the data nterfaces to nteract between the adjacent layers. The output of a layer s the nput of next level. Sensng Layer: It s the IoT data sources, generally refers to sensng devces. Acquston Layer: It gets sensng data from sensng layer, and transfers data to management layer accordng to the standard data formats. Management Layer: It mplements the data processng and storage. At the same tme, t provdes standardzed data for other systems va the standardzed data nterfaces. Applcaton Layer: It vsualzes and dsplays the acqured data. Its functons nclude data lst, curve, navgaton, statstcal analyss, prntng, and so on. In some cases, management and applcaton layers are collectvely called applcaton system. B. DAQ-Mddleware Archtecture Model Archtecture model of DAQ-Mddleware s shown n Fgure 2. It s located n the acquston layer of the IoT herarchy model. Its functons nclude recevng control commands from the applcaton system, perodcally obtanng the data of data sources, and transmttng the obtaned data to the applcaton system through the standardzed data nterfaces. DAQ-Mddleware s the mddle part of the computer operatng

3 (a) DSDF Fg. 3: DSDF and CPDF structures n XML schema. (b) CPDF system connected to the data sources. DAQ-Mddleware uses Socket to communcate wth applcaton system. In dfferent crcumstances, DAQ-Mddleware connects to the sensng devces va nterfaces such as RS232, RS485, Ethernet and USB, and connects to the exstng databases and data fles through another nterfaces, such as Web Servce, MQ and FTP. The major works of ths paper are to desgn the mddleware structure model, propose parallel data acquston algorthm and effcency optmzaton heurstc, and realze the automatc access to dfferent data sources, wth goals of reducng the development cost and mprovng the data acquston effcency. III. DAQ-MIDDLEWARE In ths secton, we frst defne the data source descrpton fle, the nterfaces between the applcaton system and DAQ- Mddleware, the nteractve mode between the man program and the acquston modules. Then, we propose the parallel data acquston algorthm and the effcency optmzaton heurstc. Last, we descrbe the overall process of data acquston n DAQ-Mddleware. A. Data Source Descrpton Fle The data source descrpton fle (DSDF) descrbes all the nformaton of the data sources that are accessed. DAQ- Mddleware can obtan Varous nformaton, such as attrbutes, nterfaces and sensor parameters of the data sources by analyzng DSDF. In order to facltate the DSDF analyss, the format of DSDF s defned. DSDF s descrbed n XML format. As show n Fgure 3a, DSDF contans multple data sources, and each data source ncludes nformaton of attrbutes, nterfaces and parameters. The node of attrbutes holds nformaton such as seral number (GlbID), the name of data sources (Name), the name of acquston module (Model), acquston module s storage path (Path), the number of sensor parameters (ParameterNum), and data sources provder (Manufacturer) whch s optonal. DSDF descrbes the ways of access, and the nterface parameter s nformaton of each data source, so that we can acheve the connecton from DAQ-Mddleware to the data sources. Dfferent data sources are connected uses dfferent Fg. 4: Descrpton structure of nterface node. Fg. 5: Descrpton structure of parameter node. nterfaces, and the parameters of dfferent data nterfaces are not the same. As shown n Fgure 4, the nformaton descrpton formats of dfferent nterfaces are defned n DSDF. The descrpton of the nterface nformaton ncludes the RS-485 (or RS-232), Ethernet, GPIB, USB, Web Servce, FTP and MQ. Dfferent types of nterfaces need to descrbe the parameters are dfferent. For example, RS-232 needs to descrbe the nformaton of seral number, baud rate, data bts, stop bts, and checksum, but RS-485 also ncludes the nformaton of sensng devce s address. DSDF also descrbes the sensng parameters, whch contaned n each data source. DAQ-Mddleware obtans the parameter nformaton and realzes the acquston of the sensng parameters by analyzng the descrpton nformaton of sensng parameters n DSDF. As shown n Fgure 5, the node of parameter ncludes sensor parameter name (Name), unt (Unt), relatve ID (RelatveID), precson (Precson) and parameter s type (Type). The sensng parameters n dfferent data sources are numbered separately, so the RelatveID refers to the ID relatve to the data source. DAQ-Mddleware obtans the correspondng sensor parameters by obtan GlbID and RelatveID. Precson refers to the poston of the decmal

4 pont. Type ncludes both analog and bnary types. In summary, DSDF contans all the necessary nformaton for the mddleware to acheve data acquston. Through the standardzaton of DSDF, dfferent data source nformaton s standardzed, and t s easy to parsed by DAQ-Mddleware. B. Interface Standardzaton DAQ-Mddleware s an ndependent system. So f you want to acheve no matter whch the feld of IoT can access to DAQ-Mddleware, we need to standardze the nterfaces between DAQ-Mddleware and the applcaton system. All these nterfaces adoptng Socket, whch nclude three parts: data source descrpton fle transfer nterface, status control nterface, and data acquston nterface. The communcaton parameter descrpton fle (CPDF) s used to descrbe the nterface nformaton of DAQ-Mddleware. By analyzng CPDF, we can realze the conjuncton between the applcaton system and DAQ-Mddleware. In Fgure 3b, CPDF structure n XML schema s descrbed. IPAddress ndcates the IP address of the computer, on whch the DAQ-Mddleware was deployed. The applcaton system establshes a connecton wth DAQ-Mddleware through ths IP address. When the connecton s establshed for the frst tme, DAQ-Mddleware transfers the DSDF to the applcaton system through the FlePort nterface. The applcaton system sends the control commands to DAQ- Mddleware through the ControlPort nterface. Then DAQ- Mddleware executes these commands and returns the settng results to the applcaton system. DataPort s defned as the nterface between the applcaton system and DAQ-Mddleware to request and return sensor data. In partcular, DSDF s transmtted usng TCP/IP through DataPort. In ths paper, the formats of request and the correspondng command are standardzed between the applcaton system and DAQ-Mddleware, n order to acheve control of the mddleware and acqure of sensor data. Applcaton system controls the start and termnaton of DAQ-Mddleware through ControlPort. The format of request commands s shown n Table 1. Ths command conssts of sx parts: 1 command begnnng character; 2 APC* represents ths command as a status control command; 3 the functon of the command, where APStart and APStop represent start and stop data acquston, respectvely; 4 separaton character; 5 check code, whch s the sum of all the characters (n decmal code) of the frst three parts n a 256 modulus; 6 a termnaton symbol $. The format of ControlPort s response command s shown n Table 2. Ths command conssts of nne parts. Many of them are smlar to those n request commands, except for 2 R means that ths command s a status control response command; 6 Result ndcates whether the command was successful (1 ndcates that the operaton has successful, and 0 otherwse). The applcaton system obtans the sensor data, whch acqured by DAQ-Mddleware through data acquston nterfaces. The sensor data conssts of analog value and status varables. Table 3 shows the request command s format for Fg. 6: getdata functon. DataPort, whch conssts of sx parts. 2 DR* ndcates the request command; 3 s the requestng sensor lst, whose format s SensorID, SensorID,. N (sze of the lst n Bytes) s no more than Table 4 shows the format of response command for DataPort, whch conssts of eght parts. 2 D represents that ths command s a data acquston command. 3 Standard data format s yyyy-mm-dd HH:mm:ss.fff, whch ndcates year-month-day hour:mnute:second.mllsecond. 5 DataLst s the sensor data matched wth the sensor ID, n the format of SensorID, value@sensorid, value@, where value s decmal data. If the data s nvald, value would be NULL. C. Acquston Module Fgure 2 shows that DAQ-Mddleware ncludes the acquston man program and the acquston module. DAQ- Mddleware uses communcaton nterfaces to acqure the data from the data sources based on specfc protocol. Dfferent sources nterfaces have dfferent communcaton protocols, so we have developed a unque acquston module for each data source based on dfferent communcaton protocols. The acquston module can be a jar fle or a separate DLL fle. The functons of acquston man program nclude the followng. It accepts control commands and data request commands from the applcaton system and returns DSDF and the processng results. It s responsble for obtanng DSDF correspondng to each acquston module, and synthesznganalyzng the nformaton contaned n DSDF to mplement the loadng of the acquston module. It nstantates the communcaton nterface, whch s descrbed n the DSDF. It nteracts wth the acquston module, organzes the obtaned sensor data n a standard format, and returns the sensor data to the applcaton system. The functons of acquston module nclude the followng. It nteracts wth the acquston man program through the standard nterface, obtans the sensor sequence whch needs to acqure by the acquston man program, and returns the sensor data to the acquston man program. It obtans sensor data from data source va communcaton protocol, and the nformaton of communcaton nterfaces, whch have been nstantated by the acquston man program. The standardzaton of nterface between the acquston man program and the acquston module enables the dynamc modfcaton and deleton of the data source by modfyng DSDF. Ths nterface s mplemented usng the getdata functon, whch s encapsulated n the acquston module. As Fgure 6 shows, the parameters of getdata functon nclude data source descrpton nformaton (datasourceinfo), sensors

5 TABLE I: Format of ControlPort s request command. ID Command # APC* APStart/APStop & Check code $ Sze n Bytes TABLE II: Format of ControlPort s response command. ID Command # R APC* APStart/APStop & Result & Check code $ Sze n Bytes TABLE III: Format of DataPort s request command. ID Command # DR* SensorLst & Check code $ Sze n Bytes 1 3 N TABLE IV: Format of DataPort s response command. ID Command # D yyyy-mm-dd HH:mm:ss.fff & DataLst & Check code $ Sze n Bytes N lst (sensorlst) and nstantated nterface nformaton (nstantatedinterface). The format of data source descrpton nformaton s the same as the defnton n Fgure 3a, but the data source descrpton nformaton passed by the getdata functon only contans the nformaton of a data source that needs to be acqured. The sensorlst s the lst of sensors relatve ID. Multple IDs separated by,. Ths ID s consstent wth the one n the DSDF. To acheve data acquston, acquston module drectly calls the nterface that has been nstantated by the man program. Because the nstantated content are dfferent wth varous communcaton nterfaces, the nstantated descrptons of all supported communcaton nterfaces are standardzed. In the case of seral communcaton, the parameters that need to be passed after nstantaton nclude the port dentfer (portid), port (seralport), the nput stream (nputstream), the output stream (outputstream), and so on. The getdata functon returns a data of Strng tme : content$state. Here, content s the returned sensor data. The formats of tme and content are yyyy-mm-dd HH: mm: ss.fff, and SensorID,Value@SensorID,Value@, respectvely. State s the state of current communcaton (1 s normal, 0 otherwse). By defnng the getdata functon and developng the correspondng data acquston module accordng to each data source communcaton protocol, the acquston man program dynamcally loads data acquston module through the reflecton mechansm base on the data acquston module placement path. By readng the nformaton of path and model n the attrbute node of DSDF, the deployment path of the data acquston module s obtaned. When addng, modfyng and deletng data sources usng the method of man program solate from the acquston module, we do not need to do secondary code development. Ths method mproves the flexblty, scalablty and effcency of DAQ-Mddleware. D. Parallel Data Acquston As Fgure 2 shown, the man program receves data request commands from applcaton system, whch contan the sensor lst of multple sensng parameters for multple data sources. In general, the data acquston mddleware analyzes the sensor lst, obtans the data sources to be acqured, and then performs the data acquston n turn. However, wth the ncreasng number of data sources, ths method leads to long acquston cycle and low effcency. Snce the characterstcs of data acquston module are ndependently desgned n the DAQ- Mddleware, we propose a novel parallel data acquston algorthm, amng to mprove the effcency of data acquston. Accordng to the prncple of computer nterfaces, there s a stuaton n whch the same nterface can access multple data sources. For example, an RS-485 nterface can access multple sensng devces (wth dfferent devce addresses). But n order to accurately analyze the returned sensor data, every tme the data acquston mddleware can only communcate wth a sngle devce on the same nterface. Snce data acquston between dfferent data sources s ndependent of each other, we can perform them n parallel. Let I denote nterface nformaton, where s the ndex of nterface and = 1, 2, m. The data source nformaton s defned as R j and j s the ndex of data source for each nterface connecton. The number of data sources connected to the I nterface s n,.e., j = 1, 2, n. As shown n Fgure 7, we defne a matrx D m n, whch represents the data source nformaton of each accessed nterface, obvously, n = max(n ), = 1, 2, m. Because dfferent data nterfaces are

6 D A Q Interface 1 Interface 2 Interface 3 Interface m D 1,1 D 2,1 D 3,1 D m,1 Round 1 Round 2 Data Source D 1,2 D 1,n D 2,2 D 2,n D 3,2 D 3,n D m,2 Fg. 7: Parallel data acquston. D m,n Round n Algorthm 1: Parallel Data Acquston Algorthm Input: Matrx D m n obtaned from DSDF Output: Acqured sensor data and acquston tme T m n 1 for round j = 1 to n do 2 for nterface = 1 to m do 3 f D,j 0 then 4 Acquston man program sends the sensor lst to the acquston module correspondng to data source D,j ; 5 end 6 end 7 for nterface = 1 to m do 8 f D,j 0 then 9 Acquston modules collect data accordng to the communcaton protocol and record the tme T,j requred for data acquston; 10 end 11 f D,j = 0 then 12 T,j = 0; 13 end 14 end 15 end ndependent of each other, we dvde the data acquston nto n rounds, and each round we collect data from a data source on m nterfaces. Note that there s a possble stuaton where no data source correspondng to the elements of matrx D,j, so we set that value 0. Otherwse, we set the value to the data source s ID. Our parallel data acquston algorthm s descrbed n detal as Algorthm 1. Parallel data acquston algorthm can greatly mprove the effcency of data acquston. Accordng to the obtaned acquston tme T m n, we can calculate the tme requred to complete one round of data acquston. The tme requred for each round of data acquston s the maxmum value of each column of matrx T m n, namely t j = max T,j, where = 1, 2, m. The tme t requred to complete a complete data acquston s t = n j=1 (t j) = n j=1 (max T,j ). If the tradtonal sequental data acquston mode s used, the tme t requred s t = m n =1 j=1 (T,j). Obvously, t t, and the effcency of data acquston s mproved sgnfcantly wth the ncreasng of the number of data sources. E. Acquston Effcency Optmzaton Snce dfferent types of nterfaces have dfferent characterstcs and constrants, there are dfferent allocaton methods when we allocate devces and nterfaces. In order to mprove the effcency of data acquston, we can adjust the matrx D m n to reduce the total acquston tme t, whle satsfyng the constrants of nterface attrbute. Ths optmzaton problem can be descrbed as follows. n n mn t = (t j ) = (max(t,j )) j=1 s.t. I s satsfed j=1 Each data source only belongs to one nterface. We can fnd the optmal dstrbuton usng brute-force method, whch goes through all possble allocatons of data resources. Wth n data resources and m possble nterfaces per data resource, there are m n allocatons. Thus, brute-force method has an exponental tme complexty. Instead, we now propose a heurstc method, whch can obtan a reasonable data resource and nterface matchng effcently. Because the data sources are dvded nto parallel multrounds, and each round of data acquston tme s decded by t j = max(t,j ). The basc dea of heurstc s to put the data sources of dfferent nterfaces wth smlar data acquston tme n the same round to save data acquston tme. The detaled algorthm s gven n Algorthm 2. Frstly, there are often crcumstances that the nterfaces wth dfferent IDs belong to the same nterface type, so we consoldate data sources of the same type of nterface n T m n to obtan G p q. p s the number of nterface types and q s the number of data sources owned by that type nterfaces. Obvously, p m and q n. The data source communcaton tme for each nterface type s then sorted n descendng order to obtan G p q. Next, keep the columns of D,j unchanged, and the rows gradually ncreasng. Accordng to the nterface I and matrx G p q, we assgn data sources to the nterface n turn, and then move to the next column. Repeat ths untl all the data sources are completed. Lastly, the relatonshp matrx D,j s obtaned between the data sources and the nterfaces. After Algorthm 1, based on D,j, the relatonshp s establshed between the data sources and the nterfaces. Data acquston can then be performed accordng to the parallel data acquston algorthm. F. Interacton Process Fgure 8 shows the nteracton process among applcaton system, DAQ-Mddleware (acquston man program and acquston module) and data sources. The nterface defntons between applcaton system and acquston man program and those between acquston man program and acquston module are descrbed n Secton 3.B and 3.C, respectvely.

7 Algorthm 2: Acq-Effcency Optmzaton Heurstc Input: I, T m n Output: D,j 1 Consoldate data sources of the same type nterface and get G p q; 2 for each number of nterface types do 3 Sort data source communcaton tme n descendng order n G p q to get G p q ; 4 end 5 for each round j do 6 for each nterface do 7 f data source wth nterface type of G p q has not been allocated then 8 D,j =ID of the data source; 9 else 10 D,j = 0; 11 end 12 end 13 end Applcaton System Establsh Connecton 5 Transfer DSDF 6 Send Control Commands 7 Return Results 8 Send Data Request Command 9 Return Sensor Data 14 DAM Acquston Acquston Man Program Module Obtan DSDF 1 Return DSDF 2 Invoke Acquston Module 3 Send Data Request Command 10 Return Sensor Data 13 Establsh Connecton 4 Obtan Sensor Data 11 Return Sensor Data 12 Data Source Fg. 8: Interacton process of DAQ-Mddleware Bascally, DAQ-Mddleware provdes a standardzed data nterface, whch can be acheved va applcaton systems docked wth DAQ-Mddleware n any IoT feld. We only need to keep the applcaton system and mddleware n the same LAN, confgure the applcaton system accordng to the CPDF, and then complete the physcal connecton between the system and DAQ-Mddleware. The system then can obtan the DSDF, control the DAQ-Mddleware, and get sensor data accordng to the defned standardzed nterfaces. Ths dockng operaton between applcaton system and DAQ-Mddleware becomes very smple and convenent. IV. IMPLEMENTATION AND EVALUATION In order to analyze the performance of DAQ-Mddleware, several IoT applcaton systems of household applances testng are desgned and developed. The feasblty, development effcency, and data acquston effcency of DAQ-Mddleware are analyzed and verfed. Fg. 9: The testng scenaro of applances. A. Expermental Envronment The feld of household applances testng has a wde range of needs for IoT applcaton systems. In a typcal applcaton scenaro as shown n Fgure 9, a large number of sensors are deployed, and hundreds of operatonal parameters of applances are obtaned. Ths applcaton system obtans realtme runnng nformaton of applances by DAQ-Mddleware. Through analyzng the real-tme stuaton of applances, manufacturers desgn producton strategy to mprove the product qualty. Table 5 summarzes the 9 data sources we used, whch consst of sensng devces, databases and data fles, 40 devces, and 410 parameters. Each data source corresponds to a data acquston module, so we have developed a total of 9 acquston modules, and confgured each DSDF. Each data source s connected to DAQ-Mddleware through a hgh-speed montorng network. DAQ-Mddleware provdes tme-seres data for the collecton to the IoT applcaton system wth nterval of 1s. We have also developed the IoT applcaton system to acheve the data processng, analyss, and vsual dsplay. Through the system development and verfcaton, t proves that the DAQ-Mddleware structure model desgn s feasble, and the standardzaton of the nterface s reasonable and practcal. B. Development Effcency There are many development methods, such as codng, modfcaton and component reusng. Usually, learnng a new object-orented programmng language costs lots of tme. Therefore the confguraton tool of descrpton fle s developed, whch makes the quck confguraton of DSDF easer. Accordng to our model, our confguraton tool can lead the developer to fnsh the confguraton procedures wthout wrtng any code. All operatons are done n the form of a dalog box, so there s no need for the user to understand any programmng language. We take the household applances testng system as an example. Durng the procedure of system development, t s further confrmed that our confguraton tool s superor n the aspect of mprovng development effcency. We compare our confguraton tool wth three other methods, ncludng codng, modfcaton, and component reusng. As shown n Fgure 10, through the development tme statstcs of the

8 TABLE V: Informaton of data sources. Data sources: Sensor Devces (Interface types: RS-232, RS-485, USB, Ethernet) Nmaew Functon Number of Parameters Number of Devces Total of Parameters ID MX100 Acquston Temperature D SR93 Temperature Controller A Power Meter UT35A Indcatng Controller Anemometer Measurng Wnds Data sources: Database and Data Fle (Interface types: Web Servce, FTP, MQ) Nmaew Functon Number of Parameters Number of Devces Total of Parameters ID Flowmeter Measure Lqud Flow Rate Manometer Measure Lqud Pressure Counter Record Swtchng Doors Vbrator Measure Vbraton Total Person-Day Confguraton tool Component reusng Codng Modfcaton Data acquston system Fg. 10: Comparson of development effcency. TABLE VI: Informaton of nterfaces. Type Count ID RS RS USB Ethernet Web Servce 1 11 FTP MQ 1 14 hstorcal developments documents, the effcency comparson estmated results of acquston system development are obtaned based on the content of software engneerng [14] [16]. At the begnnng, t takes lots of tme to develop our DAQ- Mddleware and confguraton tool. However, as the number of the developed systems grow, the effcency of our method s much hgher than others. C. Data Acquston Effcency DAQ-Mddleware adopts the parallel data acquston algorthm and effcency optmzaton heurstc. By comparng wth the seral data acquston algorthm, we found that our methods can greatly mprove the effcency of data acquston. We consder a IoT system where 40 sensng devces (as shown n Table 5) are connected to the proposed mddleware va 14 nterfaces, whch belong to 7 types as shown n Table 6. Both seral and parallel acquston methods are deployed. The seral data acquston algorthm sequentally obtans the data from 40 sensng devces, whle the parallel data acquston algorthm can obtan data n parallel and use the effcency optmzaton heurstc to schedule the acquston. Partcularly, we sort the acquston tme of dfferent data sources to obtan matrx G Accordng to matrx G 7 10, and adoptng the acquston effcency optmzaton heurstc, D 14 5 s obtaned. Then perform the parallel data acquston algorthm based on D 14 5, T 14 5 also s obtaned. G 7 10 = T 14 5 = The tme requred t for our algorthm to complete a data acquston s only t = n j=1 (t j) = n j=1 (max (T,j )) = = 387ms, whle the tme requred for the seral acquston t s t = m n =1 j=1 (T,j) = 1, 979ms. It s obvously that t s only about 1/5 of t. So the proposed parallel data acquston algorthm and acquston effcency optmzaton heurstc can mprove the effcency of data

9 Fg. 11: Acquston effcency n expermental envronment. Tme(ms) Random Heurstc Number Fg. 12: Acquston effcency n random smulatons. acquston. In addton, when the number of access devces and nterfaces ncreases, such enhancment s more obvous. At the same tme, under the condton of satsfyng the nterface attrbute constrants, we compare the proposed acquston effcency optmzaton heurstc wth random allocaton method n the acquston of data sources n the expermental envronment of Secton 4.1. The results of the comparson of the acquston effcency are shown n Fgure 11. The random acquston method s based on the parallel data acquston algorthm but use random schedulng, so ts data acquston tme s lower than the seral data acquston algorthm, but hgher than the acquston effcency optmzaton heurstc. To further valdate the effect of the acquston effcency optmzaton heurstc, we smulated 1000 tmes. Each tme we randomly generate acquston tme of 100 data sources, and compare the effcency of the two methods (proposed method vs random allocaton) n the case where the nterface nformaton has been fxed. The results of the comparson are shown n Fgure 12. The acquston tme of the proposed heurstc s below the one from random acquston method. V. CONCLUSION Ths paper has put forward a data acquston mddleware desgn based on IoT (DAQ-Mddleware), whch can realze fast and flexble access to heterogeneous data sources n dfferent felds. DAQ-Mddleware s located between data sources and hgher-level IoT applcaton systems, makng them more transparent from each other. Through the defnton of the data source descrpton fle, the DAQ-Mddleware structure model and the standardzed nterface nteractve content, we only need to modfy the data source descrpton fle to acheve data sources addton, modfcaton and deleton. At the same tme, based on the characterstcs of DAQ-Mddleware structure model, we also propose a parallel data acquston algorthm and acquston effcency optmzaton heurstc to reduce data acquston tme. Expermental comparsons wth the tradtonal data acquston algorthm confrm that our methods can mprove the effcency of data acquston. Takng nto account a very wde range of factors n the usage of IoT applcatons, n the future, we wll verfy, compare and analyze DAQ- Mddleware s performance n more areas of IoT applcatons. Acknowledgment: Z. Qu and S. Guo are supported by the fellowshp from the Chna Scholarshp Councl (CSC) under Nos and Ths work s also partally supported by the Natonal Natural Scence Foundaton of Chna under Nos , and REFERENCES [1] J. Gubb, R. Buyya, S. Marusc, and M. Palanswam, Internet of Thngs (IoT): A vson, archtectural elements, and future drectons, Future generaton computer systems, vol. 29, no. 7, pp , [2] M. Peng, Y. L, Z. Zhao, and C. Wang, System archtecture and key technologes for 5G heterogeneous cloud rado access networks, IEEE network, vol. 29, no. 2, pp. 6 14, [3] T. Redel, N. Fantana, A. Genad, D. Yordanov, H. R. Schmdtke, and M. Begl, Usng web servce gateways and code generaton for sustanable IoT system development, n Proc. of Internet of Thngs (IOT), IEEE, 2010, pp [4] H. Nng and Z. Wang, Future nternet of thngs archtecture: lke manknd neural system or socal organzaton framework? IEEE Communcatons Letters, vol. 15, no. 4, pp , [5] M. Ggl and S. Koo, Internet of thngs: servces and applcatons categorzaton, Advances n Internet of Thngs, vol.1, no.2, p. 27, [6] Z. Qu, Z. Guo, S. Guo, L. Qu, X. Wang, S. Lu, and C. Lu, IoTI: Internet of thngs nstruments reconstructon model desgn, n Proceedngs of 2016 IEEE Internatonal Instrumentaton and Measurement Technology Conference (I2MTC). IEEE, 2016, pp [7] S. D. T. Kelly, N. K. Suryadevara, and S. C. Mukhopadhyay, Towards the mplementaton of IoT for envronmental condton montorng n homes, IEEE Sensors Journal, vol. 13, no. 10, pp , [8] Z. Qu, N. Hu, Z. Guo, L. Qu, S. Guo, and X. Wang, IoT sensng parameters adaptve matchng algorthm, n Proc. of Internatonal Conf. on Bg Data Computng and Communcatons, 2016, pp [9] V. S.-K. Kovac, Vrtual nstrumentaton and dstrbuted measurement systems, J. Electr. Eng, vol. 55, no. 1-2, pp , [10] Z. Qu, Z. Guo, and C. Lu, Adaptve hgh-speed data acquston algorthm n sensor network nodes, Journal of Southeast Unversty. Natural Scence Edton, vol. 42, [11] Z. Guo, C. Lu, X. Wang, H. Ma, Y. Jang, B. Zheng, and B. He, CVIS: Complex vrtual nstruments system archtecture, n Proc. of 2013 IEEE Internatonal Instrumentaton and Measurement Technology Conf. (I2MTC). IEEE, 2013, pp [12] K. Hu, Z. Guo, et al., Composton model of complex vrtual nstrument for ocean observng. JSW, vol.9, no.5, pp , [13] D. M. Toma, T. O Relly, J. del Ro, K. Headley, A. Manuel, A. Brörng, and D. Edgngton, Smart sensors for nteroperable smart ocean envronment, n Proc. of OCEANS, 2011 IEEE-Span. IEEE, 2011, pp [14] R. L. Jones and A. Rastog, Secure codng: buldng securty nto the software development lfe cycle, Informaton Systems Securty, vol. 13, no. 5, pp , [15] A. Ramaswam, T. Hllman, B. Janson, M. Rener, and G. Thomas, A demand-centered, hybrd lfe-cycle methodology for cty-scale greenhouse gas nventores, Envronmental Scence & Technology, vol. 42, no. 17, pp , [16] B. Boehm, C. Abts, and S. Chulan, Software development cost estmaton approaches: A survey, Annals of software engneerng, vol. 10, no. 1-4, pp , 2000.