Research Article Performance Evaluation of DDS-Based Middleware …downloads.hindawi.com/journals/ijdsn/2015/863123.pdf · 2015-11-24 · Research Article Performance Evaluation of

Research ArticlePerformance Evaluation of DDS-Based Middleware overWireless Channel for Reconfigurable Manufacturing Systems

Basem Almadani,1 Muhammad Naseer Bajwa,1 Shuang-Hua Yang,2

and Abdul-Wahid A. Saif3

1Department of Computer Engineering, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia2Department of Computer Science, Loughborough University, Leicestershire LE11 3TU, UK3Department of Systems Engineering, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia

Correspondence should be addressed to Muhammad Naseer Bajwa; [email protected]

Received 9 February 2015; Revised 3 July 2015; Accepted 7 July 2015

Academic Editor: Rob Brennan

Copyright © 2015 Basem Almadani et al. This is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properlycited.

Reconfigurable manufacturing systems (RMS) are rapidly becoming choice of production andmanufacturing industry due to theirquick adaptability to the ever-changing market demands while maintaining the quality and cost of the products. Such systemsare usually decentralized in their monitoring and control and consist of heterogeneous components. Therefore, need arises foran interface that can mask the heterogeneity and provide smooth communication among these dissimilar components. DataDistribution Service (DDS) is a data-centric middleware standard based on Real-Time Publish/Subscribe (RTPS) protocol thatfulfills the job of such interface in distributed systems. In this work, we present the idea of using DDS-based middleware overcommonly used wireless channels like Bluetooth and Industrial WiFi to facilitate data communication in distributed controlsystems. A simulation model is developed to quantify various performance measures like latency, jitter, and throughput andto examine the suitability of aforementioned wireless channels in distributed monitoring and control environments. The modelexplores various communication scenarios based upon a practical case study.Obtained results serve as an empirical proof of conceptthat DDS can ensure reliable and timely data communication in firm real-time distributed control systems using common wirelesschannels and offer extensive control over various aspects of data transmission through its rich set of QoS policies.

1. Introduction

Use of distributed control systems (DCS) has become quiteubiquitous in a variety of industries like oil refining, petro-chemical, food processing, cement production, pharmaceuti-cal, and so forth. Modern controllers have become powerfulenough to collect data, make decisions, and issue commandson their own instead of routing the data to a master controlunit as in centralized control systems. The most prominentadvantages of DCS are their flexibility, agility, adaptability,and no single-point-of-failure. However, this distributedcontrol paradigm raises its own challenges that need to beaddressed before optimum benefits could be harvested.

One of these challenges is that DCS not only require I/Ocommunication for every controller but also need horizontal(with other controllers on the same hierarchical level) and

vertical (with other devices on different hierarchical levels)communication [1]. Another challenge is the heterogeneity[2] in various components used to constitute the DCS.These components, normally provided by different vendors,vary in their capabilities, data formats, mapping schemes,and I/O interfaces and, therefore, present a rather complexheterogeneous system to deal with.

To facilitate the industrial control communication inDCSand mask the heterogeneity amongst the subsystems, variousmiddleware technologies have been proposed over the lastcouple of decades. Among these are Web Services, CORBA(Common Object Request Broker Architecture), Java RMIand OPC (OLE for Process Control), and so forth. Thesetechnologies can simplify the design significantly and inte-grate control devices despite their heterogeneity. However,these solutions lose their value in real-time environments

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2015, Article ID 863123, 11 pageshttp://dx.doi.org/10.1155/2015/863123

2 International Journal of Distributed Sensor Networks

because of their inability to adapt to certain characteristicsof real-time process data [1] like periodic messages with datasampled values. Furthermore, they are nondeterministic anddo not usually respect strict timelines.

Object Management Group (OMG) developed DataDistribution Service (DDS) as an open and platform-independent middleware standard that uses Real-TimePublish/Subscribe (RTPS) protocol. DDS-based middlewaredeploys many-to-many communication model and offersextensive control over a large spectrum of Quality of Services(QoS) policies [3]. Although DDS is a relatively new mid-dleware specification, it is gaining substantial attention fromresearchers as a suitable solution inmission critical industrialautomation applications [4–6].

Wireless channel seems to be the natural choice as a com-munication medium in such reconfigurable environmentsbecause wired media will severely limit physical reconfigura-tion of the system components. Assuming that reconfigurablemanufacturing systems normally span a smaller area (theassumptions is generally true for small-scale enterprise), ashort-range limited-bandwidth wireless channel like Blue-tooth, Zigbee, or WiFi could be a suitable option. For thiswork Bluetooth and Industrial WiFi have been selected asthe communication channels and we intend to measure theperformance of DDS over these channels for the controldata. The choice of these two channels is inspired by the factthat they are more ubiquitous and mature technologies thancontenders. They have relatively higher data rates than othercommonly used RF based technologies like Zigbee and areable to support UDP/IP and TCP/IP on transport layer. Thislater ability is particularly important when integrating themwith RTPS protocol of DDS-based middleware.

The rest of the paper is organized as follows. Section 2briefly explains the fundamentals of DDS and Section 3 out-lines some of the recent related works to show the popularityof DDS in distributed industrial control applications and therelevance of this work to published literature. In Section 4,application of Industrial WiFi and Bluetooth in distributedcontrol will be discussed. A mathematical model of RTPSparadigm presented in Sections 5 and 6 discusses a case studyfor experimentation along with performance measures toanalyze the performance of DDS. In Section 7 we will explainthe experimental setup and QoS values used to evaluate theproposed approach. The results analysed in Sections 8 and 9conclude the discussion with a hint of potential future work.

2. Fundamentals of DDS

Middleware technology has been in use for the last fourdecades or so [8], at first explicitly as stand-alone componentsand later implicitly as built-in modules, in various roles andshapes. Most of the early models like CORBA [9], OPC [10],Java RMI [11], and Web Services [12] use either client-servicecommunication model or message passing communicationparadigm and hence prove somewhat ineffective in real-timeenvironment. They are also platform-dependent. To makemiddleware more acceptable in real-time and heterogeneousapplications, OMG released Data Distribution Service [13]

Topic 1

Topic 2

Data Writer

Data Writer

Data Writer

Data Reader

Data Reader

Data Reader

Data Reader

Data Writer

Publisher

PublisherSubscriber

Publisher/subscriber

Domain

Global data space

Figure 1: DDS core entities and their relationship in DCPS.

as a platform-independent real-time publish/subscribe mid-dleware standard capable of implementing a broad set ofmechanisms to define and manage QoS requirements. Basedon these exhaustively elaborative specifications, many imple-mentations are developed that enable various programminglanguage to be combined with commonly used general pur-pose operating systems. Some open source implementationsof DDS includeOpenDDS andOpenSplice whereas Connextis a proprietary implementation by Real Time Innovation Inc.

DDS employs two levels interfaces which are as follows:

(i) DCPS: Data-Centric Publish Subscribe is the lowerlevel of the two interfaces and is responsible forefficient delivery of proper data to the concernedreceiver.

(ii) DLRL: Data Local Reconstruction Layer is an opti-onal higher-lever interface, which allows integrationof the middleware and the application layer.

DCPS ensures predictability and high performance of themiddleware and the efficient use of the system resources.DLRL automatically reconstructs the data based upon theupdated values and gives the application an impression as ifthe data were local. In this way, the middleware becomes ableto transmit the data to all participating subscribers as well asupdate a local copy of the information. DDS offers a greatdeal of flexibility and scalability to the distributed systemsby effectively decoupling the publishers and subscribers fromeach other. Conceptual Outline and the basic constructs usedby DCPS in the information flow are shown in Figure 1. Briefdescription of each of them is given in the appendix.

3. Related Work

This section highlights some of the works involving mid-dleware for real-time distributed environment and discussesthe suitability of DDS standard in industrial automationscenarios.

International Journal of Distributed Sensor Networks 3

The importance of the middleware technology in dis-tributed systems has been greatly emphasized in [8]. Theauthors have presented brief and comprehensive historyof the middleware and have narrated the evolution of thetechnology right since its inception in the early 1970s. Itwas regarded as an inevitable component of any large-scale distributed system. In their words, “trying to build adistributed application without middleware is like trying towrite a simple application on a personal computerwithout theoperating system.” The authors foresee that the technologywill become even more indispensable for distributed hetero-geneous system as the systems will tend to grow more andmore complex in the days to come.

A comprehensive study of trends and developments inwireless manufacturing industry is conducted by Huang etal. in [14]. It has been established that wireless technologyin reconfigurablemanufacturing can facilitate collecting real-time plant data, improving inventory control and planning,and scheduling and executing the production adaptively asa response to changing customer demands. Their survey hasfound the application of wireless manufacturing in a broadarray of roles like part fabrication, product assembly, Just-in-Time (JIT)manufacturing, and reconfigurable productionlines among others.

Realizing that the next generation real-time distributedsystems will be highly complex high-performance environ-ments consisting of large number of nodes with hetero-geneous characteristics, the authors in [15] proposed anapproach to reduce the complexity by using iLand whichis an enhanced version of middleware for real-time con-figuration of service-oriented distributed systems [16]. Ithas been recognized that future real-time reconfigurabledistributed systems are expected to offer data-intensivecapabilities by means of assimilating the processing powerof large number of nodes. The systems are projected tohave increased dynamic behaviour as a result of recurrentreconfigurations, for instance.The approach presented in thiswork involves modelling the reconfiguration of the system asgraphs containing all tentative solutions and finding a newvalid solution from the complete graph every time the systemundergoes reconfiguration. The results show that solutionprovides phenomenal decrease in the computation timeof thereconfiguration process.

Zhang et al. [17] discussed the possibility of an RFIDenabled real-time manufacturing with reconfigurable prop-erties. They proposed a framework of reconfigurable infor-mation infrastructure for manufacturing companies. Thegoal is to enable the manufacturer to implement real-timeand smooth dual-way connectivity between RFID enableddevices and the application system at enterprise and shopfloor level. They modelled a production process as a work-flow network with nodes representing the work and edgescorresponding to the data and flow of control. The authorsclaim that their framework can allow wireless manufacturingdata collection and reconfiguration in real time. However, thelimited range of RFID technology may pose severe limitationon the span and topology of shop floor.

AlthoughDDS is a very powerful and flexible technology,it may prove to be rather complex to fully comprehend

particularly for novice users. This issue was spotted anddealt with in [4]. The authors floated the idea of a softwarecomponent encapsulating the functionality of commonlyused industrial automation controllers like PLCs, IPCs, andRobots which can then be used to create any automationapplication. The role of DDS in this case can simply beas a communication backbone. The paper shows how tomap different traffic patterns using DDS entities taking fulladvantage of DDS QoS policies.

In [18] Al-Madani et al. conducted performance enhance-ment of limited-bandwidth wireless industrial control sys-tem. They carried out experiments to study various per-formance measures of control data communication usingDDS over Bluetooth and LAN. However, there was noexperimental or software model provided in this work. Soit cannot be determined how the obtained results will beaffected by spatial or topological variations in the physicalsystem.

Large-scale mobile networks find their applications ina variety of areas like emergency response, logistics, trans-portation management, environmental monitoring, and soforth. These systems normally require real-time tracking ofall the nodes and some means of interaction among them.The use of DDS-basedmiddleware in such large-scale mobilenetworks has been studied by the authors in [19] in whichthey have customized middleware, termed as Scalable DataDistribution Layer (SDDL), derived from DDS specificationsfor online tracking and monitoring of large-scale mobilevehicle fleet spread over vast geographical area. SDDL usestwo communication protocols: RTPS protocol for commu-nication with SDDL core network over wired media andMobile Reliable UDP for wireless communication betweencore network and mobile nodes. The results confirm that theproposed middleware supports mobile nodes handover andmulticast and broadcast communication models in real timewith acceptable round trip time delays.

Finally, the suitability of short-range limited-bandwidthcommunication channels, like Zigbee and Bluetooth, inindustrial applications has been studied in [20]. The authordiscussed various merits and demerits of both technologieson different grounds. It is established that because of relativelygreater data rate and faster active slave channel access,Bluetooth is better than Zigbee for machine-to-machinecommunication and for ad hoc connectivity between thefixed equipment and mobile devices.

4. Distributed Control over Wireless Channel

Ethernet is widely used in distributed industrial controlas the communication channel due to its high-bandwidthand minimal packet loss. However, wired media are notan option when considering RMS. To avoid unnecessarywiring and make the system more tidy, Industrial WiFi canbe used as a wireless substitute for Ethernet; however, it isprone to packet drop with the increase in traffic becauseit relies upon an access point to transmit the data betweencommunicating nodes. Bluetooth, on the other hand, usesmesh topology that eliminates need of any such device and


User application

DCPS

RTPS

Zlib

UDP/IP

QoS

L2CAP

Radio link

LMP

Blue

toot

h pr

otoc

ol

stac

k

RTI C

onne

xtm

iddl

ewar

e

Figure 2: Layered architecture of DDS over Bluetooth.

offers better reliability in terms of data delivery.Though it hascomparatively narrower bandwidth, it can still work prettyfine in the given area of application knowing that data-raterequirements in industrial sensing and control applicationsare often low to intermediate [20].

The RTPS protocol is specifically designed to run inmulticast mode over connectionless best-effort transportslikeUDP/IP; it can also run over connection-oriented reliabletransports like TCP/IP. Therefore, integrating DDS withWiFi does not require any tethering or protocol interfacebetween RTPS and WiFi. RTPS runs like “plug and play”over WiFi. With Bluetooth, however, it requires IP to runover Bluetooth so that RTPS can be integrated with UDP/IPor TCP/IP transport protocol [21]. Figure 2 illustrates thelayered architecture of DDS over Bluetooth. In the transportlayer of DDS, UDP/IP provides the middleware with fine-grained control over data transmission and allows it to decidewhether the transmission should be reliable or best effort,depending upon the application requirement and underlyingnetwork type.

Above UDP/IP layer is Zlib which is a software librarythat performs data compression. It is an example whereRTI DDS developers can implement their very own datacompression algorithms to suit their application specificneeds. RTPS wire protocol uses a packet header size of 56bytes which includes timestamps and submessage headers[13]. This metadata, or transmission overhead, can further bereduced by the governing application, though this area hasnot been greatly explored yet, especially for low bandwidthchannels.

The purpose of this work is to empirically show thatDDS-based middleware can meet real-time reliable and efficientdata transmission requirements in RMS environment overabovementioned wireless channels and sustain practical QoSsupport in majority of applications. In the remaining partof this section, we present a test case setting corrospondingto distributed real-time control where judicious selection ofQoS policies can lead to smooth, reliable, and on-time datatransmission amongst various components of the system.

5. Mathematical Model of RTPS Paradigm

In this subsection, we will briefly discuss the mathematicalmodel of simple publish/subscribe (PS) communication,which is at the heart of DDS standard. Zhai et al. [22] haveelaborated the interaction of various entities in PSmodel withone another using SetTheory. Let we have three actors partic-ipating in PS system: publisher, subscriber, and InformationRepository. Publishers and subscribers are already explainedearlier. Information Repository is responsible for definingacknowledgements.There are three types of objects: notifica-tion, subscription, and acknowledgements. Publisher issuesnotification about its publication and subscriber defines itsrequirements for subscription. If the notification about acertain publication matches any of the subscription requests,that publication is delivered to the requesting subscriber.

Let 𝐵 be a 6-tuple defined as

𝐵 = (𝑃, 𝑆, 𝐼,𝑁,𝑈, 𝐴) , (1)

where 𝑃 is a set of publishers, 𝑆 is a set of subscribers, 𝐼 is aset of Information Repositories,𝑁 is a set of notifications, 𝑈is a set of subscriptions, and 𝐴 is a set of acknowledgements.𝐵 sketches the structure of publish/subscribe system and

marks the boundaries of system’s state space. The threeentities present in the system interact with one anotherby performing certain action. We define an event as anaction that changes system’s state. Naturally, PS systembehaves as discrete event systems. Therefore, we let 𝐸 ={𝑒1, 𝑒2, 𝑒3, . . . , 𝑒

𝑖, . . .} be a set of, possibly, infinite events that

may occur. Every event 𝑒𝑖occurs at a discrete point in time

represented by 𝑡(𝑒𝑖). No two events can occur simultaneously;

that is, if 𝑡(𝑒𝑖) = 𝑡(𝑒

𝑗), then 𝑒

𝑖= 𝑒𝑗. Hence, we can only have

an ordered sequence of events in which 𝑒𝑖always precedes 𝑒

𝑗

if and only if 𝑡(𝑒𝑖) < 𝑡(𝑒

𝑗) given that 𝑖 < 𝑗.

In very primitivemodel of a PS system the following typesof events can occur.

Publish. A notification is published by publisher.

Notify. Subscriber is notified about publication.

Subscribe. Subscriber activates a subscription.

Unsubscribe. Subscriber revokes an existing subscription.

Acknowledge. Information Repository issues acknowledge-ment.

Having laid down the bases for nomenclature, now wecan mathematically define a publish/subscribe as 𝑃𝑆 =(𝐵, 𝐸), where 𝐵 describes the structure of the system and𝐸 determines its behaviour. PS system behaviour can nowbe modeled as ordered sequence of events which resultsin change of system states. System state changes when, asan effect of certain event, any of the individual publisher,subscriber, and Information Repository changes its state. Forexample, when a publisher, 𝑃

𝑖, issues a new notification, it

changes set of notifications associated with this publisher,𝑁(𝑃𝑖), triggering a transition in𝑃

𝑖’s state.This change in𝑁(𝑃

𝑖)


Workstation 2

Workstation 1

Input Output

Type 1

Type 2

Position 1

Position 2

Si

S3

So

Ai

S1 S2

A1A2

A3

M1 M2

M3

Figure 3: An automated reconfigurable manufacturing system (reproduced with permission from [7]).

ultimately causes change in𝑁(𝑃) which is super set of𝑁(𝑃𝑖)

and represents set of all notifications issued by all publishersin the system. In the same way the state of a subscriber𝑆𝑗changes as a result of changes in 𝑁(𝑆

𝑗) and 𝑈(𝑆

𝑗); and

any change in 𝑅(𝑃𝑖) causes change of state of Information

Repository 𝐼𝑠.

6. An Automated RMS

To evaluate the performance of DDS-based middleware inRMS, consider the automated manufacturing system shownin Figure 3. The system is adapted from [7] and consistsof three machines represented by 𝑀

1, 𝑀2, and 𝑀

3; it has

five sensors (𝑆1, 𝑆2, 𝑆3, 𝑆𝑖, and 𝑆

𝑜) and four actuators (𝐴

1,

𝐴2, 𝐴3, and 𝐴

𝑖) for blocking. The manufacturing system is

constructed using PLCs. Two types of pallets, Type 1 andType2, are input to the system randomly. The route which thesepalletsmay take is decided by a three-position stop,𝐴

𝑖, whose

selection depends upon the routing information provided by𝑆1and 𝑆3sensors.

All three machines publish a set of values pertaining totheir operation. These values include state of the machineand various physical quantities like motor speed, pressure,temperature, and so forth. Machines can be instructed tophysically reposition themselves using configuration com-mands sent by the control panel (not shown in the diagram).Besides issuing configuration commands, control panel alsomonitors machines’ data by subscribing to their respectiveTopics.

Sensors 1, 2, and 3 look for the availability of theirrespective machines. If a machine is currently operating

on some pallet, then these sensors publish FALSE Booleanvalue to indicate that the machine is currently busy and nomore input may be dispatched on this route. Otherwise, theytransmit TRUE as soon as the machine is ready for the nextinput. Input sensor (𝑆

𝑖) keeps an eye on input availability to

the system. Output sensor (𝑆𝑜) monitors whether a finished

product by either workstation has left the system. It helpsavoid product collision over the conveyor belt.

Actuators 1, 2, and 3 are stop points and remain close aslong as corresponding machines are working. They are opento let the finished product pass and let new input get into theworkstation. Dispatcher 𝐴

𝑖is responsible for forwarding the

input (if available) to either of the two routes or hold until oneof them is available.

The motors, actuators, and sensors can physically moveacross the workbench (shown in grey strip) enabling thewhole system to transform into a single-, double-, or triple-workstation system, thus facilitating configurability of thesystem in both physical and functional sense. As it is assumedthat the whole setup covers a relatively smaller space (upto few tens of meters), therefore use of limited-bandwidthwireless channel seems proper in this scenario.

6.1. Performance Measures. Before moving on to the exper-imentation, it is better to first discuss the performancemeasures that will determine whether Bluetooth and WiFican fulfil real-time data communication requirements of thesystem.

(i) Latency: latency is the time a data packet takes toreach the receiver side. It includes propagation delayplus queuing delay at the receiver side. It can be


MD3MD1

MD2MA1

MA2

MA3

CFG IPA

AS1

AS2

AS3

RLS

MD1 writer

CFG reader

AS1 reader

MD2 writer

CFG reader

AS2 reader

MD3 writer

CFG reader

AS3 reader

MA1 writer

MA2 writer

MA3 writer

CFG writer

MD1 reader

MD2 reader

MD3 reader

MD1. reader

AS1 writer

MA2 reader

MD2. reader

AS2 writer

RLS reader

MD3. reader

AS3 writer

RLS reader

MA3 reader

IPA reader

MA1 reader

IPA writer

RLS writer

Control panel

Si SoA3 AiA2A1

S3S2S1M1 M2 M3

Figure 4: DCPS model of system shown in Figure 3. MDx = Machine Data x, CFG = configuration command, MAx = Machine Availabilityx, ASx = Actuator Status x, RLS = Relay Status, IPA = input availability, MDx. = Machine Data x. Status (status member of data structureMDx).

calculated by dividing round trip time (RTT) by 2 asgiven in

Latency = 𝑅𝑇𝑇2. (2)

In firm real-time systems, deadlines are relativelyrelaxed as compared to hard real-time systems.Although a packet arriving after the deadline maynot be of any value, occasional longer delays or evenpacket loss does not cause the system to fail [23, 24].In this experimentation, every data packet is sentwith a time stamp according to publisher’s clock.The publisher upon receiving the acknowledgementfor the packet calculates the time difference betweensending the packet and receiving the acknowledge-ment andmarks the duration as RTT.Oneway latencyis therefore taken as half of RTT.

(ii) Jitter: jitter is the variation in latency. Smaller valuesof jitter mean that the data will, most of the time,experience almost the same amount of delay duringits voyage from sender to receiver. Mathematically, itcan be represented as given in

Jitter = √ 1𝑁

𝑁

∑

𝑖=1(𝑥𝑖− 𝑥)2

. (3)

Here, 𝑁 is the total number of delay samples and𝑥 is the mean value of 𝑁 delay samples. Jitter issignificant in determining the precision of the system.If a channel shows sufficiently small average latencyduring a transmission session but exhibits large jittervalues, it signifies that some packets take unusually

long time to reach the subscriber and any givenupdate cannot be reliably sent within average latencyduration.

(iii) Throughput: throughput denotes average rate of suc-cessful data transmission over a channel. This datarate does not take only payload into consideration butalso includes any protocol overhead. We used (4) tocalculate the throughput:

Throughput = Packet Size × number of PacketsTotal Time

. (4)

Throughput is important in observing channel uti-lization. High throughput implies that bandwidthresources are property utilized. However, increasingthroughput beyond a certain point may cause con-gestion and subsequently result in packet loss.This inturn may cause longer delays. Therefore, monitoringthroughput is pivotal in real-time mission criticalapplications. Bluetooth offers several frame formatswith varying header and payload sizes. The mostcommon format has 126 bits of metadata and up to2744 bits of payload. However for a single time slot of625 𝜇s (there are 1600 frequency hops per second inBluetooth) the frame carries only 240 bits as payload,while frame metadata remains the same [25, 26].

7. Experimental Setup

Simulation model corresponding to the scenario depictedin Figure 3 is shown in Figure 4. As can be seen from thefigure, the model incorporates one-to-many and many-to-many communication requirements. Each rectangle and eachsquare represent a domain participant (we are assuming that


Table 1: QoS used in experimentation.

QoS Policy ValuePublisher Subscriber

DURABILITY TRANSIENT TRANSIENTLATENCY BUDGET 40ms 40msLIVELINESS AUTOMATIC AUTOMATICmax lease duration 120 sec 120 secRELIABILITY BEST EFFORT BEST EFFORTHISTORY KEEP ALL KEEP LASTRESOURCE LIMITS LENGTH UNLIMITED 1max samples per instance

all the participants are in a single domain).TheseDDS entitiescorrespond to various types of hardware devices like sensors,actuators, and motors as shown in Figure 3. The QoS used inexperimentation are given in Table 1.

The rtiddsgen utility provided by RTI Connext 5.0.0 isused to generate C++ code. Visual Studio 2010 is used tobuild the code and Wireshark 1.2.3 is employed for trafficmonitoring over wireless channels.

7.1. QoS Policies Used in Experimentation. Below, we presenta short description of the QoS used for the experimentationand their interdependence on one another.

(i) DURABILITY : durability QoS decides if data shouldoutlive their writing time, that is to say, whether ornot data samples should be archived in middlewareservice after they are written. A VOLATILE type doesnot care to save any sent data samples on behalf ofData Writers; however, TRANSIENT type maintainsrecord of sent updates in memory and the data isnot tied to the lifecycle of Data Writer. It means thatdata will still be available even if the correspondingDataWriter goes offline.These achieved samples maybe delivered to late-joining subscribers who want toknow what they missed.

(ii) LATENCY BUDGET: this QoS policy describes max-imum acceptable delay between sending and receiv-ing of the data. This is not something carved in thestone, but rather just a guideline to the service. If anupdate fails to meet this acceptable delay, the servicewill not raise any flags or discard the packet.

(iii) LIVELINESS: it indicates the mechanism by whichthe middleware knows if any participating entity isactive or has gone offline. Every Data Writer peri-odically signals its liveliness to all the Data Read-ers. The signalling period must not exceed live-liness lease duration; otherwise Data Reader assumesthat the Data Writer is no more alive.

(iv) RELIABILITY : the RELIABILITY QoS policy speci-fies the level of reliability that a subscriber can offer ora publisher can request. It has two values, RELIABLEand BEST EFFORT. In RELIABLE mode, the DataReader must acknowledge the receiving of each and

every packet that arrives.DataWriter does not discardany data value that has been transmitted but not yetacknowledged. This approach has slightly negativeeffect on the latency because the receiving entity mustcheck the integrity and order of the received packetbefore acknowledging. It also consumes some of thechannel bandwidth for acknowledgements. On theother hand, if a packet drop, every once in a while,does not greatly affect the system and the applicationcares little about the order of the data received, it isbetter to use BEST EFFORT mode which does notrequire sending or receiving acknowledgements.

(v) HISTORY : this QoS defines the behaviour of mid-dleware service in case the value of the data changesbefore it is successfully transferred to the receiver.On sender side, it controls the number of samplesthat will be kept with Data Writer on behalf of DataReader. On receiver side, it indicates the numberof samples maintained by Data Reader until thesubscriber application reads the data.

(vi) RESOURCE LIMIT: it indicates how much resourcesthemiddlewaremay consume to complywith theQoSrequirements. Configuration of this QoS must be inaccordance with other QoS settings. For example, ifRELIABILITY is set to RELIABLE, then DataWritersneed some memory space to store the data samplesthat have been sent but not yet acknowledged. If we setmax samples per instance to, say, 1, then Data Writerwill not be able to cache enough unacknowledgedpacket to implement RELIABLE communication.Therefore, to implement RELIABILITY QoS suc-cessfully, enough resources must be allocated usingRESOURCE LIMIT.

8. Results and Analysis

The simulationmodel mimics the behaviour of communicat-ing devices; it generates random data values periodically andpublishes them. It also plays role of subscribing components.This simulation model runs on different computer machinesconnected via Bluetooth or WiFi. The generated values aretransmitted over physical channel and actual measurementsare taken and recorded for analysis.


Table 2: Latency and jitter for one-to-many scenario.

SetupMin. Max. Average Jitter(m sec) (m sec) (m sec) (m sec)

BT WiFi BT WiFi BT WiFi BT WiFi1-1 7.94 1.28 50.30 63.51 9.11 2.41 4.60 2.351-2 11.00 1.38 71.08 57.29 12.62 2.47 5.46 1.961-4 17.31 1.77 64.08 112.44 19.42 4.00 6.71 4.681-6 23.54 2.06 72.50 454.14 26.16 4.23 7.67 5.161-8 29.79 2.22 99.56 707.40 33.45 5.95 8.84 7.63

0 1 2 3 4 5 6 7 8 905

10152025303540

Number of subscribers

BluetoothWiFi

(ms)

Figure 5: Average latency against various number of subscribers.

8.1. Experiments for Latency and Jitter. For the latency andjitter test, we used payload of 1024 bytes (which is themaximum payload size in the given scenario). First onepublisher and multiple subscriber scenario is examined andlatency and jitter are calculated. In each run 10,000 to 50,000packets are sent; the tests are repeated up to 10 times andaverage is taken to make the results more precise. Table 2shows the obtained results.

Based upon the collected data, jitter is calculated using(3). We can see that both latency and jitter increase linearlyas the number of subscribers grow. Due to higher bandwidth,WiFi latency is significantly lower than Bluetooth latency,despite the fact that WiFi packets from one node must go toan access point before being routed to the destination node.However, the values of average latency for Bluetooth, even forthe worst case, are well within acceptable range for firm real-time requirements (around 40msec).

Figures 5 and 6 show the graphs of latency and jittercorresponding to Table 2, respectively. We also observe thatwhile WiFi jitter is far smaller than Bluetooth jitter for fewersubscribers, the gap between the two tends to shrink as moreandmore subscribers (and consequently network traffic) joinin and packet drop increases. This is because of the fact thatWiFi performance at a certain instance depends greatly onthe amount of traffic at that given point in time.

Latency and jitter are calculated for many-to-many com-munication scenario as well. Tests are run to examine theeffect of multiple publishers and multiple subscribers on thelatency and jitter. As expected, both performance measureshave higher values whenmultiple participants try to transmit

Table 3: Latency and jitter for many-to-many model.

SetupMin. Max. Average Jitter(m sec) (m sec) (m sec) (m sec)

BT WiFi BT WiFi BT WiFi BT WiFi2-2 8.62 1.42 167.90 131.93 18.34 2.69 8.94 2.952-4 11.10 1.64 210.58 237.24 19.31 3.43 7.54 3.364-4 15.94 1.55 251.02 106.48 23.71 3.40 12.31 3.394-8 22.15 2.43 259.27 291.53 37.05 6.32 9.88 4.28

0123456789

10


BluetoothWiFi

(ms)

0 1 2 3 4 5 6 7 8 9

Figure 6: Jitter against various number of subscribers.

0

10

20

30

40

50

BT latencyWiFi latency

BT jitterWiFi jitter

(ms)

Setup

2P-2S 2P-4S 4P-4S 4P-8S

Figure 7: Average latency and jitter for various many-to-manyscenarios.

the data over a single channel. These results are tabulated inTable 3. Figure 7 shows the results in graphical format. Hereagain we can see that DDS ensures small enough latencyand jitter over both communication channels to accomodatefirm real-time requirements of most RMS. However, WiFiprecedes Bluetooth in terms of better latency and jitter inevery scenario.

In these experiments, the maximum number of sub-scribers is limited to 8. This is for two reasons: firstly, ourcase study does not require more than 8 subscribers forany control data and secondly the trend in the performancemeasures can be easily deducedwith thesemany participants.It is anticipated that with the increase in the number of


Table 4: Throughput for one-to-many model.

SetupTotal packets Total time Throughput

(×1000) (sec) (Mbps)BT WiFi BT WiFi BT WiFi

1-1 3137 4585 1107 5515 23.22 6.811-2 3091 2794 1125 3288 22.50 6.961-4 3156 3330 1110 3805 23.28 7.171-6 3560 3780 1235 3985 23.61 7.771-8 3786 5040 1311 5505 23.66 7.50

0 1 2 3 4 5 6 7 8 90

5

10

15

20

25


(Mbp

s)

BluetoothWiFi

Figure 8: Throughput graph for single publisher and multiplesubscribers.

subscribers latency, jitter, and throughput will follow thesame course as obtained in these experiments.

8.2. Experiments for Throughput. Throughput depends uponthe size of the data packets sent and the frequency of thetransmission. Most of the data size used in the case studyis less than 150 bytes. Only configuration commands mayextend up to 1 KB. We used this maximum packet size tocalculate the throughput of the Bluetooth channel. This time,100,000 to 160,000 samples of data packets are sent fromthe publisher side and received on the subscriber side ineach iteration. Total time for this communication is notedand throughput is calculated using (4). The experiments areconducted at least 10 times to get more precise results.

We notice from Table 4 and Figure 8 that the throughputfor the given packet size is not quite affected by the number ofparticipants currently active.There is very small and randomdifference in the throughput against various number ofsubscribers. Bluetooth provides extremely high throughputfor 24Mbps channel (for Bluetooth 3.0 + HS). Though thethroughput of WiFi is significantly low, it provides betterlatency values for the low data-rate communication.

Like many-to-many latency and jitter experiments, wealso conducted tests to measure average throughput overBluetooth and Industrial WiFi in many-to-many mode.Various configurations of publishers and subscribers areexamined. Table 5 summarizes the results obtained for bothchannels. We can observe from Figure 9 that throughput isnot significantly affected by the number of participants inmany-to-many scenarios as well and once again Bluetooth

Table 5: Throughput for many-to-many model.

SetupTotal packets Total time Throughput

(×1000) (sec) (Mbps)BT WiFi BT WiFi BT WiFi

2-2 3368 3560 1238 3706 22.28 7.872-4 4082 4032 1399 4360 23.90 7.674-4 4178 4032 1445 2767 23.69 12.374-8 4208 4032 1445 2730 23.86 12.59

05

10152025303540

Setup(M

bps)

BluetoothWiFi

2P-2S 2P-4S 4P-4S 4P-8S

Figure 9: Throughput graph for multiple publishers and multiplesubscribers.

surpasses WiFi in terms of higher average throughput. Itshould be noted, however, that tests on WiFi require a verycontrolled environment to avoid any unnecessary traffic andensure that only DDS applications are using the channel.Thisis not the case with Bluetooth because of its point-to-pointconnection.

9. Conclusion and Future Work

This work is a first attempt to investigate the suitability ofBluetooth and Industrial WiFi in RMS applications takingfull advantage of DDS-based middleware. It is establishedthatmost of the distributed industrial control systems involveexchange of simple control parameters and system statesand therefore require relatively low data rates. DDS-basedmiddleware can mediate among heterogeneous devices in atypical small-area RMS by offering a data-centric commu-nication paradigm for abstracting their peculiar data repre-sentations. The results show that DDS over these wirelesschannels fulfil real-time data communication requirementsof most of the limited-bandwidth small-area control systems.They offer high throughput for small data packets and lowlatency which is suitable for firm real-time systems. Theseperformance measures in conjunction with inherent securityand reliability of these channels make them a safe and reliablechoice for most RMS applications.

Literature survey reveals that not enough attention hasbeen granted to wireless RMS applications and the role ofDDS-based middleware. Results obtained in this work areencouraging and call for further focused research to study


the proposed concept in greater depth. For future researchwork, use of DDS over Zigbee in DCS environment can be aninteresting area to investigate. InjectingRTPS data over ratherlow-bandwidth Zigbee network can be challenging. Researchin this area can present proof of concept of Zigbee’s suitabilityin mission critical real-time applications using DDS-basedmiddleware. It is, however, expected that latency and jittermay increase significantly given narrower bandwidth of thechannel. The work in this area is currently underway.

Appendix

Figure 1 shows the fundamental construct of DDS. Below, wepresent brief account of each of them for readers not familiarwith DDS architecture.

(i) Topic: a Topic is an information unit that is exchangedacross the distributed system. EveryTopic is identifiedby a unique name within a domain and has anexclusive data type.

(ii) Domain: a domain is a communication context. It isa distributed concept that links all those applicationsthat can communicate with each other. In otherwords, all the participants belonging to a certaindomain can interact only to each other and not to theparticipants in another domain.

(iii) Domain Participants: participants are the entitiesinvolved in data communication in any application.They represent the local membership of the applica-tion in a certain domain.

(iv) Publisher: a publisher is an object responsible for datadistribution. It can publish various types of data usingData Writers. Domain participants create publishersto manage a group of Data Writers.

(v) Subscriber: a subscriber is an object responsible forreceiving the published data and making it availablefor the application that the data are supposed toreach. It can receive different types of data using DataReaders. Domain participants create subscribers tomanage a group of Data Readers.

(vi) DataWriters: DataWriter is a typed-based object thatthe middleware uses to communicate the existenceand the value of the data object of a certain type.Typed-based means that each Data Writer objectis associated to only one data type or Topic. If apublisher wants to publish more types of data it musthave dedicated Data Writers for each of the Topics.

(vii) Data Readers: Data Readers are typed-based objectsthat a subscriber must use to access subscribed data.Each Data Reader can read only a single Topic anddifferent Data Readers need to be attached to asubscriber in order to receive multiple data types.Therefore, a subscription may be defined as an corre-spondence between a Data Reader and a subscriber.

Every time an application wants to publish data it mustcreate a publisher, or use an existing one, and connect it

with a Data Writer that matches the characteristics of thedesired publication. Similarly, when an application wants tostart receiving updates on a particular Topic it must createa Subscriber, or reuse an existing one, and link it to anappropriate Data Reader.

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper.

Acknowledgments

The authors would like to extend their gratitude to Real TimeInnovation Inc. for very generously providing RTI Connextlicense for this project. Computer Engineering Departmentof KFUPM also deserves special thanks for arranging hard-ware equipment and lab setup for the experimentation.

References

[1] I. Calvo, F. Perez, I. Etxeberria, and G. Moran, “Controlcommunications with DDS using IEC61499 service interfacefunction blocks,” in Proceedings of the 15th IEEE InternationalConference on Emerging Technologies and Factory Automation(ETFA ’10), pp. 1–4, IEEE, September 2010.

[2] B. Almadani, S. Khan, M. N. Bajwa, T. R. Sheltami, and E.Shakshuki, “AVL and monitoring for massive traffic controlsystem over DDS,”Mobile Information Systems. In press.

[3] B. Almadani, A. Al-Roubaiey, and R. Ahmed, “Manufacturingsystems integration using real time QoS-aware middleware,”Advanced Materials Research, vol. 711, pp. 629–635, 2013.

[4] I. Calvo, F. Perez, I. Etxeberria-Agiriano, and O. G. De Albeniz,“Designing high performance factory automation applicationson top ofDDS: regular paper,” International Journal of AdvancedRobotic Systems, vol. 10, article 205, 2013.

[5] I. Etxeberria-Agiriano, I. Calvo, F. Perez, and G. de Albeniz,“Mapping different communication traffic over DDS in indus-trial environments,” in Proceedings of the 6th Iberian Conferenceon Information Systems and Technologies (CISTI ’11), pp. 1–6,IEEE, Chaves, Portugal, June 2011.

[6] J. L. Poza, J. L. Posadas, and J. E. Simo, “QoS-based middlewarearchitecture for distributed control systems,” in InternationalSymposium on Distributed Computing and Artificial Intelligence2008 (DCAI 2008), vol. 50 of Advances in Soft Computing, pp.587–595, Springer, Berlin, Germany, 2009.

[7] M. Nourelfath, D. Ait-kadi, and W. I. Soro, “Availability model-ing and optimization of reconfigurablemanufacturing systems,”Journal of Quality in Maintenance Engineering, vol. 9, no. 3, pp.284–302, 2003.

[8] J. Al-Jaroodi and N. Mohamed, “Middleware is STILL every-where!!!,” Concurrency and Computation: Practice and Experi-ence, vol. 24, no. 16, pp. 1919–1926, 2012.

[9] Object Management Group, “CORBA Specifications, version3.3,” 2012, http://www.omg.org/spec/CORBA/3.3/.

[10] OPC Foundation, 2013, https://opcfoundation.org/.[11] Oracle Corporation, “Java Platform Standard Edition 8 Doc-

umentation,” 2014, http://docs.oracle.com/javase/8/docs/index.html.


[12] The World Wide Web Consortium, Web Service Architecture,W3C, 2004, http://www.w3.org/TR/ws-arch/.

[13] Object Management Group, “DDS for Real-time Systems,Version 1.2,” 2007, http://www.omg.org/spec/DDS/1.2/.

[14] G. Q. Huang, P. K. Wright, and S. T. Newman, “Wirelessmanufacturing: a literature review, recent developments, andcase studies,” International Journal of Computer IntegratedManufacturing, vol. 22, no. 7, pp. 579–594, 2009.

[15] M. Garcıa-Valls, P. Uriol-Resuela, F. Ibanez-Vazquez, and P.Basanta-Val, “Low complexity reconfiguration for real-timedata-intensive service-oriented applications,”FutureGenerationComputer Systems, vol. 37, pp. 191–200, 2014.

[16] M. G. Valls, I. R. Lopez, and L. F. Villar, “ILAND: an enhancedmiddleware for real-time reconfiguration of service orienteddistributed real-time systems,” IEEE Transactions on IndustrialInformatics, vol. 9, no. 1, pp. 228–236, 2013.

[17] Y. Zhang, G. Q. Huang, T. Qu, and O. Ho, “Agent-based work-flow management for RFID-enabled real-time reconfigurablemanufacturing,” International Journal of Computer IntegratedManufacturing, vol. 23, no. 2, pp. 101–112, 2010.

[18] B. Al-Madani, A. Al-Roubaiey, and M. F. Al-Hammouri,“Performance enhancement of limited-bandwidth industrialcontrol systems,” Advanced Materials Research, vol. 739, pp.608–615, 2013.

[19] L. David, R. Vasconcelos, L. Alves, R. Andre, and M. Endler, “ADDS-based middleware for scalable tracking, communicationand collaboration of mobile nodes,” Journal of Internet Servicesand Applications, vol. 4, no. 1, pp. 1–15, 2013.

[20] N. Baker, “ZigBee and Bluetooth strengths and weaknessesfor industrial applications,” Computing & Control EngineeringJournal, vol. 16, no. 2, pp. 20–25, 2005.

[21] U. F. Khan, S. Hameed, and T. Macintyre, “TCP/IP overbluetooth,” in Advances in Computer and Information Sciencesand Engineering, pp. 479–484, Springer, Dordrecht,TheNether-lands, 2008.

[22] L. Zhai, L. Sun, and Y. Liu, “Modeling and evaluation of high-performance publish-subscribe system,” in Proceedings of theInternational Symposium on Computational Intelligence andDesign (ISCID ’08), vol. 1, pp. 457–460, IEEE, 2008.

[23] T. T. H. Le, L. Palopoli, R. Passerone, Y. Ramadian, and A.Cimatti, “Parametric analysis of distributed firm real-time sys-tems: a case study,” in Proceedings of the 15th IEEE InternationalConference on Emerging Technologies and Factory Automation(ETFA ’10), pp. 1–8, September 2010.

[24] T. T. H. Le, L. Palopoli, R. Passerone, and Y. Ramadian, “Timed-automata based schedulability analysis for distributed firm real-time systems: a case study,” International Journal on SoftwareTools for Technology Transfer, vol. 15, no. 3, pp. 211–228, 2013.

[25] A. S. Tanenbaum and D. J. Wetherall, Computer Networks,Prentice Hall, 5th edition, 2012.

[26] Bluetooth Special Interest Group, “Bluetooth SpecificationsVersion 4.1,” 2013, https://www.bluetooth.org/en-us/specificat-ion/adopted-specifications.

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation http://www.hindawi.com

Journal ofEngineeringVolume 2014

Submit your manuscripts athttp://www.hindawi.com

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation http://www.hindawi.com

Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014

SensorsJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks


Documents

Research Article Performance Evaluation of DDS-Based Middleware …downloads.hindawi.com/journals/ijdsn/2015/863123.pdf · 2015-11-24 · Research Article Performance Evaluation of