A knowledge-based resource discovery for Internet of Things

ContentslistsavailableatScienceDirect

Knowle dge-Base d Systems

journalhomepage:www.elsevier.com/locate/knosys

A knowle dge-base d resource discovery for Internet of Things ^R

Charith Perera

^a,∗

, Athanasios V. Vasilakos

^b

aCentre for Research in Computing, The Open University, Milton Keynes, UK

bDept of Computer Science, Electrical and Space Engineering, Lulea University of Technology, Lulea, Sweden

a rt i c l e i nf o

Article history:

Received 22 January 2016 Revised 23 June 2016 Accepted 26 June 2016 Available online 29 June 2016 Keywords:

Internet of Things Middleware Semantic knowledge IoT resource composition

a b s t ra c t

Inthesensingasaserviceparadigm,InternetofThings(IoT)Middlewareplatformsallowdataconsumers toretrievethedatatheywantwithoutknowingtheunderlyingtechnicaldetailsofIoTresources(i.e.sen- sorsanddataprocessingcomponents).However,configuringanIoTmiddlewareplatformandretrieving dataisasignificantchallengefordataconsumersas itrequiresbothtechnicalknowledgeand domain expertise.Inthispaper,weproposeaknowledgedrivenapproachcalledContextAwareSensorConfig- urationModel (CASCOM)tosimplify theprocess ofconfiguringIoTmiddleware platforms,sothe data consumers, specificallynon-technical personnel,can easilyretrieve the datathey required.Inthispa- per, wedemonstratehowIoTresourcescanbe describedusingsemanticsinsuchawaythattheycan laterbeused tocompose servicework-flows.Suchautomated semantic-knowledge-basedIoTresource compositionapproachadvances thecurrentresearch.We demonstratethe feasibilityand the usability ofourapproachthroughaprototypeimplementationbasedonanIoTmiddlewarecalled GlobalSensor Networks(GSN),thoughourmodelcanbegeneralizedtoanyothermiddlewareplatform.

© 2016ElsevierB.V.Allrightsreserved.

1. Introduction

TheInternetofThings(IoT)[2]envisionsconnectingbillionsof smartdevicesto theInternet. Itprovides anetworkedinfrastruc- turethat enablesthings tobe connected anytime,anyplace, with anythingandanyone,ideallyusinganypath,anynetworkandany service[31]. These smart devices should be smoothly integrated withinFutureInternet(FI)servicedeliverymodelssuchassensing asaservice. Thethings¹ inIoTareaccompaniedwithsensorsand actuators.It isestimatedthatthereareabout1.5billionInternet- enabledPCsandover1billionInternet-enabledmobilephonesto- day.By2020,therewillbe50to100billiondevicesconnectedto theInternet[31].Sincethesesmartdevicescomprisesensors,itis evidentthatthere wouldbe manysensorsdeployedaroundusin thefuture.Eventoday,sensorsareusedinmanydomainssuchas agriculture,environmentalmonitoring,andmanufacturing[25].

In order to analyse and understand a given phenomenon extensively, data generated from appropriate sensors needs to be fed into more sophisticated data analysis applications. These

R An earlier version of this work has been published in the Proceedings of the 9th International Conference on Semantics, Knowledge & Grids (SKG).

∗ Corresponding author.

E-mail addresses: charith.perera@ieee.org , ngcharithperera@gmail.com (C. Perera), vasilako@ath.forthnet.gr (A.V. Vasilakos).

1We use terms objects, things, smart objects, devices, nodes to give the same meaning as they are frequently used in IoT literature interchangeably.

applicationsaredesignedtoproducecertain resultsoncethey are given required sensor data as inputs. IoT middleware solutions simplify the retrieval ofdata from sensors forthese applications by acting as a mediator between the hardware layer and the applicationlayer. Inorderto performthesebindings, middleware solutions need to be configured depending on the context in- formation and user requirements. Our objective is to automate and simplify the configuration of IoT middleware platforms and improvetheir usabilitysoboth ITexpertsandnon-ITexpertscan usethemefficientlyandeffectively.

There are several characteristics we haveidentified asimpor- tant for developing a model for IoT that provisions sensingas a servicebyformulatingandcomposingmultipletypesofsensoras well as different filtering, fusing, and reasoning mechanisms to- gether on-demand. The core features ofthe proposed model are asfollows:

• Autonomic: The model should support the dynamic composi- tionof internet-connectedobjects, inresponse to dynamically definedend-users’ requests.Tothisend, wehaveincorporated semanticknowledge [30], along withautomated reasoningal- gorithmsfororchestratingsensors,anddataprocessingmecha- nisms[25],accordingtothedataconsumerrequests.

• Utility based: The proposed model should deliver services ac- cording to a utility computing model [8,22]. It should offer sensingcapabilityasaservice[26]overdynamicallycreatedand http://dx.doi.org/10.1016/j.knosys.2016.06.030

0950-7051/© 2016 Elsevier B.V. All rights reserved.

configuredsolutions² that arecustom generatedforeachcon- sumer request. Sensor data consumers (users) should be al- lowedtomakethe decisionsonthecharacteristicofthesolu- tion(e.g.accuracy,reliability,latencyandsoon).Orchestration ofIoT resources (i.e sensors anddataprocessing components) inthecloud environmentatruntimeisanimportantfunction- ality [5]. The dynamism implies the capability of adapting to resources changesinvolatileenvironments wheresensors and data processing components may be added or removed from the systemover time. This means that new solutions will be abletocomposetogether overtimedueavailabilityofnewre- sources.

• Scalabilityandflexibility:Theproposed solutionshouldbeflex- ible sodataprocessingcomponentsandsensorscan beadded over time [33].Further, theproposed solution should bescal- able so any number of IoT resources can be supported. Such ability increases the types of consumer requests that can be fulfilled.Further,itincreasesthenumberofdifferentsolutions that canbe formulatedto accommodatea singlerequest. Pos- sibilityofcreatingmultipledifferentsolutionswillincreasethe choiceandcontrolconsumerhave.Finally,theproposedmodel and its algorithms should be independent from the data (i.e.

descriptions of IoT resources) so adding a new resource does notrequirechangestobemadeintothesystem.

• Ease of use/reduced learningcurve: One ofthe primary goals ofanIoTmiddlewareistoenableuserstoretrievedataquickly withoutdealingwithcomplexhardwareorsoftwarelevelcon- figurations.Itisimportanttomakealltheprocesssimplifiedso anon-technicalpersonal(e.g,biologist)canusetheseIoTmid- dlewareplatformstocollectthedatatheyneedwithminimum effort.

1.1. Motivation

Over the last few years, we have seen more and more IoT middlewareplatformsmakingtheirwayinthemarketplace.Large number of sensors are expectedto connect to thesemiddleware platforms.Further,varietyofdifferentIoTapplicationsareexpected tobebuiltontopofthesemiddlewareplatforms.TheseIoTappli- cations have differenttypes ofalgorithms that analyse databuilt intothem.Thesealgorithmsarenothingbutsometypeblackboxes thattakespecifictype ofinputsandgeneratespecifictypeofout- puts. Oneof themain responsibilitiesofan IoT middleware isto hide and abstract the connectivity andcommunication details of sensors andsupport the users to retrieve the data streams they requiredtobefedintotheirapplicationeasilyandquickly.

Dataprocessingcomponentscanalsobeusedtobuildthesere- quired data streams aswe later discuss in this paper. Currently, itisdifficult toconfigureIoTmiddlewareplatforms inawaythat theyproducesacertaindatastreamthatisrequiredbyanIoTap- plication. The challengesare discussed in Section 2. Tomake IoT middleware configurationeasier, we propose a knowledge driven approach calledContextAwareSensorConfiguration Model(CAS- COM) tosimplifythe processofconfiguring IoT middlewareplat- forms, so the data consumers, specially non-technical personnel, caneasilyretrievethedatatheyrequired.

1.2. Maincontributions

Thecontributionsofourpaperareasfollows:

• We propose a IoT configuration model called CASCOM to en- richexisting IoT middlewareplatforms.Thismodelhelpsnon-

2Solution is a combination of sensors and data processing components that can be composed together in order to satisfy a user requirement.

ITexpertstoconfiguresensorsanddataprocessingcomponents withlesseffort.

• CASCOM iscompletelydrivenby semanticallyenriched IoT re- source descriptions at the back end. Therefore, new sensors and data processing components can be added at any time.

Nochangesarerequiredintheapplicationfromanalgorithmic perspective.

• CASCOM provides an easy wayto constructthe data streams requiredbythedataconsumersbyselectingquestionsandan- sweringthem.

• CASCOM automatically highlights to users on potential sec- ondary context information that can be derived fromexisting primarycontext.

• Finally, CASCOM informs the users regarding potential sensor anddataprocessingcomponentsthat canbeaddedtothesys- teminordertoenhancetheabilitytoservetheuserrequests.

• CASCOM uses ontologies tomodel semantics wherethree on- tologies capture the relevant knowledge collectively. The us- ageofontologieshelptoautomatedcompositionandreasoning process. More importantly, modelling new knowledge is very easy dueto the adoption of ontology based knowledge mod- elling technique. Specifically, we employ two existing ontolo- gies,namelySCO[9],andSSNontology[10]anddevelopedour ownontologycalledQA+TDO.Newknowledgecanbeaddedto theseexistingmodelseasilyusingtheproposedtool.

We explain all the above mentioned contributions in detail throughoutthepaper. The restofthis paperisstructured as fol- lows.Section2presentsthebackgroundandrelatedwork.First,we brieflyintroduce anIoT referencearchitectureandits characteris- tics.Then,weexplainwhereourproposedmodelfitsinsuchanar- chitecture.Later,wereviewsomerelatedworkandcomparethem withourowntohighlightthesimilaritiesanddifferences.There- searchchallengesarediscussedinSection 3.Wehaveusedareal worlduse-casescenariofromtheagriculturedomaintoexplainthe researchproblemindetail.Ourresearchquestionis‘Howtodevelop a model thatallows data consumers (i.e, non-IT and IT experts) to configureIoTmiddlewareplatformsbydiscoveringandcomposingIoT resources(i.e,sensorsanddataprocessingcomponents)effortlessly?’. Oncetheconfigurationiscompleted,theIoTmiddlewareplatform shouldproducethedatastreamsthatthedataconsumershavere- quested. Data consumers can use these data streams to achieve theirownobjectives.

Subsequently,weexplaintheimportanceofresourcediscovery andcompositioninIoTdomainandwhyitneedtobeknowledge- driven.Architectural designs are presentedin Section 4.We pro- pose our solution, CASCOM, which consists of six phases where eachphaseisexplainedindetailwithrelevantalgorithmsandex- amples. Section6 presentstheimplementation andexperimenta- tiondetails.Weevaluatetheproposedmodelfrombothcomputa- tional (i.e. storage requirements,data model loading time, query time) and usability point of views, presenting our findings in Section7.Weexplainwhyourproposedmodelisfeasibleandhow ithelpsuserstoconfigureIoTmiddlewareplatformseasily.Finally, weconcludethepaperinSection8.

2. Backgroundandrelatedwork 2.1. Background

Inthis section,we review anumber ofrelated work anddis- cuss the problem domain in detail. Broadly, configuration in IoT paradigm can be categorized into two areas: sensor-level config- uration and system-level configuration. Sensor-level configuration [13] focuseson changing a sensor’s behaviour by configuring its embeddedsoftwareparameterssuchassensingschedule,sampling

Fig. 1. Internet of Things reference architecture. Our proposed model, CASCOM, fits within the Reasoning Engine (RE) block of the architecture. The details of this architecture is discussed in detail in [24] .

rate,datacommunicationfrequency, communicationpatternsand protocols. In this paper, we focus on developing a system-level configurationmodel for IoT midddleware platforms. System-level configurationfocusesonchangingthebehaviourofIoTmiddleware systemsbyconfiguringinternalsoftwarecomponents.Specifically, ourproposedmodelidentifies,composes,andconfiguresbothsen- sorsand dataprocessing componentsin orderto createthe data streamsbasedonuserrequirements.

We startby brieflyintroducing areferencearchitectureforIoT middleware.Our reference architecture, a detaileddescription of whichisgivenin[24],is presentedinFig.1.Thedetails are pre- sentedin [24].Eventhoughthe detailsofthisreferencearchitec- tureareoutofscopeofthispaper,wewouldliketobrieflyintro- ducesomeofthemajorresponsibilitiesofan IoTmiddlewareand itsdifferentcomponents.TheobjectiveofanIoTmiddlewarefrom users’perspectiveistocollectsensordatastreamssotheycanin- jectthemintoanapplicationthatiscapableofperforminganaly- sis[4].Adatastreamissimplyasetofdataitemsthatiscaptured andtransferred totheuserssequentiallyandcontinuously atcer- tainintervals(e.g. every5 s,every 2h). Asampledatastream is illustratedinFig.2.Adatastreammayconsistofonetypeofdata (e.g.asillustrated indatastream2inFig.2)ormultipletypesof data(e.g.asillustratedindatastream1inFig.1).

The referencearchitecture illustrated in Fig.1 consistsof four layers:Data,Semantics,andContextDisseminationLayer(DSCDL), ContextProcessing and Reasoning Layer (CPRL), Context and Se- manticDiscoveryLayer (CSDL),andSensorData AcquisitionLayer (SDAL).Data,Semantics,andContextDisseminationLayer(DSCDL) is responsible for user management. The components belong- ing to this layer are data dispatcher, request manager, andpub- lish/subscribe. Typically,users will not know about the technical details of the sensors or data processing components. Theyonly knowabouttheproblemtheyneedtosolve.therefore,usersneed

Fig. 2. Data stream.

tobe provided withthe easy-to-usemechanismsto expresstheir requirementsinhigh-levelwithoutrequiringtechnicalknowledge.

The Processing and Reasoning Layer (CPRL) is responsible for data processing, reasoning, fusing, knowledge generating and storing. In this layer data processing components are organized into work-flowsin such away that they collectivelyproduce the data streams required by the consumers. Context and Semantic Discovery Layer (CSDL) is responsible for managing context and generating secondary context information from primary context information. Sensor Data Acquisition Layer (SDAL) is responsible for acquiring data. This layer communicates with hardware and softwaresensorsandretrievessensordataintoIoTmiddleware.

In this referencearchitecture, data processingcomponents sit withintheDataFusionOperator³(DFO)registry.Similarly,Context Provider Registry(CPR) keepstrackofthedataitemscapturedby

3DFO is also called the data processing component.

thesensors. ReasoningEngine(RE)isresponsible forbuildingthe abovementionedwork-flowsolutionstosatisfyuserrequests.

ThechallengeofconfiguringanIoTmiddlewaresolutionatrun timecanbeunderstoodbyanalysinganexistingmiddlewaresuch asGlobal SensorNetworks(GSN) [1].Some ofthekey challenges areasfollows.

• Users need to know the low-level details such as data types andmeasurementunitsofthesensorsinordertorequestthem manually.

• Itis extremely difficulttomemorise differentcombinationsof sensordatatypesthat can beused tofulfiluserrequirements (e.g.whichsensorsneedtobecomposedtogethertodetectan event?).Inparticular,domainknowledge(e.g.,relatingtoagri- culture)isdifficulttomemorisewhenthereare multipleways ofbuildingagivendatastream.

• Usersneedtoknowtheavailabilityofdataprocessingcompo- nents,theirinput/outputdatatypesandtheircapabilitiestode- velopastrategy.Dataprocessingoperationsneedtobeapplied ondatainthecorrectsequence.

• Thereis nowaytofindout thestrategiestoovercometheis- sues when existing hardware resources (i.e. existing sensors) and software resources (i.e. data processing components) are incapableofproducingtheresultsthatusersrequired.

• Further, the solutions designed by users may not be optimal (e.g.duetothevariabilityofhardwareandsoftwarecosts).

An ideal IoT middleware configuration model should address all the above mentioned challenges. The proposed configuration model, CASCOM, is applicable towards several other emerging paradigms, such assensingasa service[35].Ourproposed solu- tion combines technologiesfromdifferent research areassuch as IoT middleware,semantictechnologies, softwarecomponentcom- position,andcontext-aware computing. We discussmajorrelated researcheffortsintheremainderofthissection.

2.2. Relatedwork

MicrosoftSensorMap[18](sensormap.org)isadatasharingand visualizationframework.Itisapeerproducedsensornetworkthat consists of sensors deployed by contributors around the world.

SensorMap mashes up sensor data on a map interface. Then, it allows to selectively query sensors and visualize data. Our ap- proach completely automatesthe configuration process by elimi- natingtherequirementofhandpickingsensors.LinkedSensorMid- dleware(LSM)[29] (lsm.deri.ie) isaplatform thatprovides wrap- persforrealtimedatacollectionandpublishing.Italsoprovidesa webinterfaceforsensorsearch,linkedstreamdataquery,dataan- notationandvisualisation.LSMmainlyfocusesonlinkeddatapub- lishing.Sensorselectionneedstobedonemanuallyinordertore- trievesensordata.Xively(Xively.com)isaplatformforInternetof Thingsdevices.Xivelyallowsdifferentdatasourcestobeconnected toit.Then,itprovidesfunctionalitiessuchaseventtriggeringand data filtering.Itacts asa mediator betweensensors andapplica- tions whereusersneed tomanually selectandconfiguresensors.

HyperCat (hypercat.io)is an open, lightweight JSON-based hyper- media catalogueformatforexposingcollectionsofURIs.HyperCat hasproposedthenotionofdescribingresourcesinasemanticway.

ThesedescriptionsaredesignedforexposinginformationaboutIoT assetsovertheweb.HyperCat providesa standardmechanismfor developerstopublishlinked-datadescriptionsofresources.

Context-awareness is a critical functionality that needs to be embedded into IoT middleware solutions [25]. Context informa- tion (e.g. accuracy, reliability, cost) plays a significant role in se- lecting sensors and dataprocessing components [23]. Tosupport this, CASCOM provides context discovery functionalities by using semanticknowledgeandfusingrawsensordata.TheSensorMashup

[28] platform offers a visual composer for sensor data streams.

Data sources and intermediate analytical tools are described by referenceto an ontology,enablingan integrateddiscovery mech- anism for such sources. Selection of data sources and analytical tools based on user requirement need to be done manually by users.Khemakhem etal.[14]use multipleontologies to discover andcompose softwarecomponents byfocusingonnon-functional proprieties.Inweb servicecomposition domain,servicecomposi- tionmeanscomposingalargerservicebycombiningmanysmaller services.Thisisthesameprincipleusedwhencomposingalarger softwarecomponentfrommanysmallercomponents.

Webservice(WS) composition usingontologies [17] issimilar to IoT resource composition performed in CASCOM froma func- tional point of view but different from an implementation and execution point of view. Web services composition domain only involvesin combiningmultiplesoftwarecomponents. Incontrast, CASCOMneeds todeal withbothhardwareandsoftwarecompo- nentsinits configurationmodel.We presentacomparisonofWS compositionandIoTresourcecompositioninTable1.

Leitneret al.[16]have proposed a cost-based servicecompo- sitionmodel to support servicelevel agreements (SLA)in manu- facturingdomain.Similar toourapproach,inSLAs,customersare allowedtoexpresstheirrequirementsandexpectations(e.g.mon- etarycosts,timetodeliver,quality).Basedonthecustomerneeds, different serviceproviders will be used to accommodate the re- quest order(e.g. normal shippingor expressshipping). However, these composition are done based on predefined business rules.

Haddadetal.[11]haveaddressedtheissueofselectingandcom- posingWebservicesnotonlyaccordingtotheirfunctionalrequire- ments butalso to their transactionalproperties andQoS charac- teristics.ThoughQoScharacteristicsareimportantinIoT resource compositiondomain,transactionalpropertiesarelessrelevant.The reason is that IoT resource composition does not need to sup- portcompensationsorundoingtransactions.Bronstedetal.[7]has mentionedthat ‘Only10 casesusescenario-basedevaluation,which ismostrealisticbecauseitinvolvesactualusebyusers.So,formany ofthemechanisms,there’sweakempiricalsupportfortheclaimthat theyworkinrealisticsettings’.Thisisoneofthereasonswe evalu- ateourapproachusinguse-caseandalsodescribedtheprocesses and techniques using real-world applications. Kritikos and Plex- ousakis[15] havediscussed quality ofserviceandits importance towardswebservicediscovery.TheyrecognizeQoSasasetofper- formanceanddomain-dependentattributesthat hasasubstantial impacton WSrequesters’expectations.This isalsosimilar inIoT resourcecompositiondomainaswell.

Severalprojects[9]havedesignedanddevelopedontologiesto describesoftwarecomponents.Suchapproacheshavehelpedthem toperform dynamiccomposition ofsoftwarecomponents. Apro- cessof software component matching using ontologies has been explainedin[21].InourworkweemployedtheSoftwareCompo- nentOntology discussedin[9].SemanticSensorOntology (SSNO) [10]also allowed usto modelsensor descriptions. Noguchietal.

[19] have proposed a mechanism that generates connection be- tween different software components in order to process sensor dataanddetectevents.Incontrast,ourobjectiveistoproducethe datastreamsrequiredbytheuserssotheycanbefurtheranalysed extensivelyusingsophisticatedapplications.

3. Researchchallenges

Thissection describesand analyses theresearch challenges in detailwithconcreteexamples andscenarios.Fig. 3illustrates the problemingeneral.Theexplanationsarebasedonagricultureand environmental monitoring domains. The proposed solution helps data consumers to overcome the difficulties listed in Section 2. Ourresearchquestionis‘Howtodevelopamodelthatallowsnon-IT

Table 1

Comparison of web services composition and IoT resource composition Domains. In summary, web services selection is based on virtual capabilities and characteristics where IoT resources selection is based on both physical and virtual capabilities and characteristics. As a result, IoT resources are much complex elements to be selected and composed autonomously than web services.

Web service domain [36] IoT domain

Similarities • Consuming single web service may not create significant value.

Therefore, web services selection and composition is critical to generate value.

• Collecting data from a single sensor may not create significant value.

Therefore, sensor selection and composition is critical to generate value.

• Many alternative web services are available to use • Many alternative sensors will be available to use

• Can be found through directory services • Middleware solutions such as OpenIoT and GSN will play a mediator

roles between sensors and sensor data consumers

• Quality of services matters [34] . • Quality of sensors (and data) matters

• There are free as well as paid services. • There will be free as well as paid sensors

Differences • Web service compose with other web services in to work-flows. • Sensors and data processing components compose together into work-flows.

• Largely guided by standards. • No standards (yet) [12] .

• Largely depend on software. • Largely depend on hardware, firmware, as well as software

• Less uncertainty (unless some hardware sensors are involved. e.g, data from weather stations.)

• More uncertainty.

• Not tangible and more reliable. • Sensors are Tangible, could be mobile and less reliable.

• Some web services accept data as input and produce some data based on them (e.g. data fusion).

• Some sensors may accept queries/conditions/preferences as inputs and produce data based on them. Nevertheless, sensors do not accept raw data with the intention of fusing data.

• Data send to the consumer using web services. • Comparatively, more sensors will be accessible over the Internet by 2020

[31] .

• Comparatively, fewer web services will accessible over the Internet by 2020 [36] .

• Sensors, typically provides less meaningful raw sensor data where they need to be processed by data processing components.

• Typically provide more meaningful processed and refined data.

Fig. 3. The problem definition in general.

Fig. 4. Use cases that illustrates the need of CASCOM.

expertstoconfiguresensorsanddataprocessingmechanismsinanIoT middlewareaccordingtotheirrequirements?’.Thenotationswe use inthissectionare presentedinTable 2.Other notationswe used inthispaperareasfollows:Wrapper(W)andVirtualSensor(VS).

Fig.4illustratestwoscenariosfromtwodifferentdomains.Each ofthemhasdifferentconsumerrequirementsthatleadtotwodif- ferentexecutionflows.Weselectedthesetwoscenariosduetothe factthat,together,theyallowustoshowcasethefullcapabilitiesof Context-AwareSensorConfiguration Model(CASCOM).Inusecase 1, a plant scientist wants to monitor whether the experimental cropscan be infectedby Phytophtora [3]diseaseor not.Phytoph- torais afungaldisease whichcanenter a fieldthrough avariety ofsources.Thedevelopmentandassociatedattackofthecropde- pends strongly on the climatological conditions within the field.

Humidity plays a major role in the development of Phytophtora. Bothtemperatureandwhetherornot theleavesarewetare also important indicators to monitor Phytophtora. The following facts explainPhytophtoramonitoring(simplifiedfordemonstrationpur-

poses).Itisimportanttohighlightthatrule-basedreasoning⁴does notintendedtoreplaceruleengines [32].Theobjectivehereisto createthedataitemsthatarerequiredbytheapplication.

• IF Air Temperature <

α

^{AND Air Humidity} <

β

^{THEN Air}

Stresslevel=lowELSEAirStresslevel=high

• IFAir Stress=highANDLeafWetness>

δ

^THEN Phytophtora Disease=Can-be-infectedELSE=Cannot-be-infected

OneoftheresponsibilitiesofanIoTmiddlewareistocombine different sensors and data processing components autonomously andproduceadatastreamasillustrated inFig.2.Mostly,ourfo- cusisondatastreamsthatconsistsofmultipledatatypes.Adata consumer can feed the data stream into an application for fur- thercomplexprocessingsuch asvisualization andmodelling that allows the data consumers to achieve their objectives. The main challengeisthat theplantscientistmaynotknow(orremember) the domain knowledge listed as rules above. Further, we should not expect aplantscientist towrite XML orJava codeaspartof the configuration. An ideal IoT middleware should help the sci- entist (non-IT expert) toovercome thesechallenges by providing toolsthat areeasy to use.Thescientistshould be abletoconfig- urethemiddlewareaccordingtotheproblems/tasksathandwith minimumeffort.Additionally,advancedcustomizationwillbeuse- fultooptimizethe configurationprocess.Comparatively,usecase 1islesscomplexasthereisonlyonewaytomonitorthedisease (aboverules). Forexample,the sensor typesand dataprocessing componentsneedtobeusedarestraightforward.

• Usecase(1)Solution:((S_AT,S_AH)⇒C₁,S_LW)⇒C₂

As symbolized in the above statement, the IoT resource may need to be composed as follows.First, air temperature(S_AT) and airhumidity(S_AH)needtobefedintoairStressDetectorcomponent (C₁).Then,itproducestheairStressastheoutcome.Thenleafwet- ness (S_LW) and airStress need to be fed into phytophtoraMonitor component(C2).ItproducesthephytophtoraDiseasestatus.TheIoT resourcecompositionisillustratedinFig.5

4we employed rules based reasoning in this disuccions.

Table 2

Common algorithmic notations.

Symbol Definition

S Complete set of sensors described in the data model.

S α S denotes the sensor and subscript αdenotes the types of the sensor. Examples are listed in Table 3 .

M _θ Model represent the complete ontology based semantic data model. The θcan be replaced by either c as (i.e. M c) or s (i.e. M s). c demotes the complete model and s denotes the subset of the complete model.

T Filtered set of tasks described in the data model.

T u Task selected by the user (or sensor data consumer) where IoT middleware needs to be configured accordingly.

β SPARQL query that selects different properties from the data model. βcan be replaced by t tasks, a answers, q questions, and d data streams.

Q Filtered set of questions described in the data model (List of questions).

Q u Single question selected by the user to answer.

A Filtered set of answers described in the data model (List of answers).

A u Single answer selected by the user.

C γ( ): z C denotes the data processing components where γis used an identifier to distinguish each different component. Arguments/ parameters accept by each components are depicted by as set. may accept one or more inputs as denoted by ‘ λ#’. The symbol # denotes the number of the input parameter. The type of each argument is depicted by letters such as x, y (i.e. = {λ1x, λ2y }). The return value is depicted by letter after ‘:’ symbol.

Examples are listed in Table 4 .

H Filtered set of solutions composed by CASCOM which are capable to producing data streams required by the user.

H u A single solution composed by CASCOM which are capable to producing data streams required by the user. Solutions is a composition of sensors and data processing components formulated into a certain order.

D Filtered set of different data-streams that can fulfil user requirements. Data stream is a continuous flow of data which encompasses several data items.

D A single data stream is composed with number of different data items.

Πi This denotes the ith data item of a given data stream.

R Recommendation list that contains information about sensors and data processing components that are not available. Acquire such resources will help to facilitates user requirement in the future.

P List of all the data items that are available to be captured by the IoT middleware either directly through active wrappers or by combining / composing such data iteams with data processing components. Depending in the complexity of retrieving and generating data items, we categorize them into number of categories.

P A single data item that is available to be captured from active wrapper.

M Additional list context information that can be discovered by the users if needed.

σ Matrix that stores the information about input / outputs of data processing components and data items in P .

Table 3 Subset of sensors.

Sensor Explanation S AT Air Temperature S AH Air Humidity S LW Leaf Wetness S CM Carbon Monoxide S CD Carbon Dioxide S MO Molecular Oxygen S ME Methane S ND Nitrogen Dioxide

Table 4 Subset of DPCs.

Sensor Explanation C 1( ): z airStressDetector C 2( ): z phytophtoraMonitor C 3( ): z pollutionDetector C 4( ): z airQualityMonitor

Configurationbecomesacomplextaskintheusecase2.Inthis scenario, an environmental scientist wants to measure the envi- ronmental pollution in Canberra, Australia. In comparison to the use case 1, there are many different ways to measure and visu- alizepollution.Different sensorsanddataprocessingcomponents can be combinedtogether to fulfiltherequirements ofdata con- sumers as listed below. Even the same Data Processing Compo- nents (DPC) may accept different combination of input in order to performthe sametask.DPCis ablack boxthat accept certain typesofinputsandproducescertaintypesofoutputs.Thereason- ing happen withina givenDPCcouldbe variesfrom, rulesbased reasoning,statisticalreasoning,logical inferencingmachine learn- ing, probabilistic reasoningandso on.As an example,we useda rulebasedDPCinthepaperdiscussion.

• Usecase(2)Solution1:(S_CM,S_CD,S_MO,S_ME,S_ND)⇒C₄

Fig. 5. Resource composition in IoT.

• Usecase(2)Solution2:(SCD,SND)⇒C₃

• Usecase(2)Solution3:(S_AT,S_CD,S_ME)⇒C₄

Insuchcircumstances,itisimportanttoconsidercontextinfor- mation(e.g.accuracy, reliability)andcostofdataacquisition (e.g.

datacommunicationtimeandcomputationtime).Theavailability ofmorethanone optionallows adataconsumerstomakethefi- naldecisiononwhich solutiontobe useddependingonthe cost andcontextfactors.Bothhardwareandsoftwarecostsneedtobe considered.Additionally,dataconsumersmayneedtodiscoverad- ditionalcontext information[25].Dependingon therequirements ofthedataconsumersandapplicationrequirements,therequired outputdatastream mayvary.Sampledatastreams,inrelation to usecase1,arelistedbelow.

• Output 1: airTemperature [double], airHumidity [double], airStress[string],

leafWetness[double],PhytophtoraDisease[boolean]

• Output 2:PhytophtoraDisease[boolean], location[string], bat- teryLevel[double]

Previously, we explained that theobjective of IoT middleware isto producedata streams sothe userscan injectthem into ap- plications. We assume that these applications will accept multi- pledifferent datastreams asillustrated in Fig.6.The ideology is

Fig. 6. Each application may accept different data streams and provide outputs at different detail levels.

Fig. 7. The Context-Aware Sensor Configuration Model (CASCoM).

thatwhen theseapplicationsare providedwithmore dataitems, they will perform better or provide additionalfeatured / results.

However, each applicationwill have a minimumnumber of data itemsthatitwouldacceptinordertoperformtheprimarytaskit promisestodeliver.Forexample,iftheapplication2(inFig.6) is providedwithPhytophtoraDiseaseandlocation data,itwillsimply markthe areas which are under risk of getting infectedby Phy- tophtoraDisease. In contrast,if the application2 is provided with moreinformationsuchasbatteryLevel,leafWetness,andairStress,it willproducesmoredetailedandcomprehensivevisualizationthat mayincluderisklevelwithcertainconfidence.Rawdatavaluesof leafWetness, and airStress mayhelp the application 2 to perform theseadditionalcalculationsandpredictions.

In summary, we assume each application would perform one ormore tasks (e.g. PhytophtoraDisease monitoring). Each applica- tion would accept one more different data streams. In such cir- cumstances, each data stream may consist of different types of dataitems.Additionally,differentdevelopers(orcompanies)orthe same developer may develop multiple applications that perform thesametasks. Similarly, we alsoassume that therewould mul- tiple data processing components that would perform the same datafusionoperationsthough theircontext informationmayvar- ied.Duetothelargenumberofpossibilities,IoT middlewareplat- forms require an automated process to optimally serve the user requests.

4. Architecturaldesign

BasedonthechallengesweidentifiedinSection3,wedesigned a model,which issupported by a tool, to overcomethe difficul- ties. Context-Aware Sensor Configuration Model (CASCOM) sim- plifiesthe IoT middlewareconfigurationprocess significantly.Our proposed model allows non-technical personnel to configure IoT middlewareeffortlessly. All the technical configurations are han- dledinternallybehindthescenes withouttheusers’involvement.

Additionally,we offer several advanced features that allow opti- mizationandcustomizations.As depictedinFig.7,CASCOM con- sistsofsixphases.Some phasesmayormaynotbevisibletothe users.Phasesaredifferentfromthestepsneededtobefollowedin theCASCOMTool.

CASCOMExecutionflow:Inphase1,dataconsumers(users)in- teractwitha graphicaluserinterfacethat isbasedona question- answer(QA)approach,tospecifytheirrequirements.Userscanan-

Fig. 8. A part of QA-TDO shows how we developed the QA model. It is important to note the pattern (i.e. Task → Concept → Question ).

swerasmanyquestionsaspossible.CASCOM searchesandfilters thetasksthattheusermaywanttoperform.Fromthefilteredlist, users canselectthe desiredtask.Thedetails of theQA approach are presented later inthis section. In phase 2,CASCOM searches fordifferentprogrammingcomponentsthat allowtogeneratethe datastreamrequired.Inphase3,CASCOMtriestofindthesensors that can be used to produce the inputsrequired by the selected dataprocessingcomponents.IfCASCOMfailsto producethedata streamsrequiredbytheusersduetoinsufficientresources(i.e.un- availability ofthesensors), itwill provideadvice andrecommen- dationson futuresensordeploymentsinphase 4.Phase5 allows theuserstocaptureadditionalcontextinformation.Theadditional context informationthatcan be derivedusing availableresources andknowledgearelistedtobeselected.Inphase6,usersarepro- vided withone or more solutions.⁵ CASCOM calculates thecosts foreachsolution.Bydefault,CASCOMwillselectthesolutionwith lowestcost. However,userscan selectthe costmodels(discussed later inthis section)asthey required.Finally,CASCOM generates alltheconfigurationfilesandprogramcodeswhichtheactual IoT middlewaremayrequires[27].Datastartsstreamingsoonafter.

Phase1:Understanduserrequirements:Theobjectiveofthis phase is to help data consumers to search for a task (e.g. Phy- tophtoraDiseasemonitoring)that theyneedtoperformeasilyfrom a large number ofpossibilities. For example,data consumers are allowedtonarrowdownthepossibilitiesbymentioningfactssuch asdomain(e.g,agriculture),andtypeofthetask(e.g.event, visu- alization).Inordertoincreasetheusability,CASCOMretrievesthe factsfromthedataconsumersthroughaQA model(Sampleques- tions:Do you want tovisualize data?, Do you wantto detect an event?,Do you wanttomonitora diseaseinfection? What isthe domainyourtaskisrelatedto?).Whena useranswera question, theremainingquestionswillbedynamicallyselectedbasedonthe previous answer.An extractof theproposed QuestionandAnswer orientedTaskDescriptionOntology(QA+TDO)ispresentedinFig.8. In QA+TDO, tasks can be explained by any concept as depicted inC1, C2,etc. inFig. 8.Eachconcept should havea ‘hasQuestion’

property which links to a question (i.e. Q1, Q2 and so on). It is expected that new questions will be added to the QA+TDO over time by differentdomain expertsandcontributors aspart ofthe knowledgemodellingprocess sothe non-technicaluserscantake advantage of them. In QA+TDO, C are answers to the questions.

(e.g, If Q1= What is the domain your task is related to?, then C5 is ‘domain’ and an individual of C5 can be ‘agriculture’.). This process is presented in algorithmic perspective in Algorithm 1, which takes the data model as the input and outputs the user preferredtask. The designphilosophy of thisalgorithm is that it repeatedly allow the user to select questions and answer them.

5A solution is a combination of sensors and data processing components that can be composed together in order to satisfy the user requirements.

Algorithm1 Question-answerbasedtaskfiltering.

Require: (M).

1: Output:Tu

2: M←Loaddataintomodel 3: whileTu!=NULLdo 4: Q←executeQuery(^q,M)

5: Qu←AskusertoselectaquestionfromQ 6: AddQuto

7: A←executeQuery(a,M)

8: Au←AskusertoselectaanswerfromA 9: AddAuto

10: T←executeQuery(t,M)

11: Tu←AskusertoselectataskfromT 12: ifTu!=NULLthen

13: return T_u 14: endif 15: endwhile

As a result, thealgorithm will generate a SPAQRLstatement and updateitevery timewhenauserselectsandanswers aquestion.

Every time a user answers a question, the number of possible optionsofferedtotheuserswillgetreducedasthenewQ&Awill alwaysaddmoreconstraintstothequery.

Let us briefly explain the Algorithm 1. CASCOM first allows userstoselectaquestionasdemotedinQu.NextCASCOMusesQu

to query its knowledge-base.The resultsare denoted asA. Next, both questionandanswersis amendedtoa singlequery^.is usedtoquerytheknowledge-baseandresultedtasksaredenoted byT.Thisprocessrepeatsuntilusersfindthetaskstheyarelook- ingforT_u.

Phase 2 and 3: Select sensors and data processing compo- nents:CASCOMrequiresalltheinformationrelatedtosensorsand data processingcomponents tobe storedin a repository.We ex- tended the SoftwareComponent Ontology [9](SCO)aspresented inFig.9inordertomodelinformationaboutdataprocessingcom- ponents. Further,wemodelledsensordescriptionsusingsemantic SensorOntology(SSN)[10].Inthisphase,thesoftwarecomponents areselectedinsuchawaythattheycantogetherproducethedata streamrequiredtoperformthetaskselectedinphase1.Forexam- ple,inordertomonitorPhytophtoraDisease,firstCASCOMsearches for a software component that can be used to produce the re- quireddata.ItfirstfindsPhytophtoraDiseaseDetector.Theinputsit requiresareairstressandleafwetness.Phase3selectsthesensors that producethe output that matches the inputsof the selected component.Leafwetnesscanbemeasureddirectlyusinghardware sensors.However, airstresscannot bedetected usinganyphysical sensor. This requires CASCOM to execute phase 2 againin order to finda softwarecomponentthat produces airstress.Then CAS- COM findsAir Stress Detector which takesairtemperatureand air humidity asinputsandproduces airstress asthe output.Further, air temperature and air humidity can be sensed directly through hardware sensors. The IoT middleware configuration process will becompletedoncetherequiredsensorsanddataprocessingcom- ponentsareidentified.Theremainingphasesareoptional.

CASCOMperformsvalidationasillustratedinFig.10.Duringthe sensorsanddataprocessingcomponentscompositionprocess,dif- ferent criteriaare evaluated (e.g.data types: int, boolean / mea- surementunits:Celsius,Fahrenheit)inordertoverifywhetherthe inputs and outputs are compatible.The above mentioned proce- duresarepresentedinalgorithmicperspectiveinAlgorithm2.

Thisalgorithms takesthedatamodel(demoted byM) andthe datastreamelementsoftheuserpreferredtaskastheinputs(de- motedby Tu). First,it finds outwhat are theoutput datastream required by the user preferred task (denotedby D). Then, it at-

Algorithm2 Resourcescompositionandrecommendation.

Require: (M),(T_u) 1: Output:H,R

2: M←Loaddataintomodel 3: D←executeQuery(d,Tu,M)

4: //D=

{ Π

1,

Π

2,

Π

3...

Π

ⁿ

}

5: forall D∈Ddo 6: forall

Π

i∈Ddo

7: if

Π

i==outputofasensorS_αinthesetSthen 8: addS_α toHu

9: else

10: if

Π

i==outputofacomponentC_γ inthesetCthen 11: addC_γ toHu

12: composeFurther(^Cγ,Hu)

13: else

14: add

λ

# toR

15: endif

16: endif 17: endfor 18: endfor 19:

20: FunctioncomposeFurther(^Cγ,Hu)

21: forall

λ

#∈^ofCγ do

22: if

λ

#==outputofasensorS_αinthesetSthen 23: addS_α toH_u

24: break 25: else

26: if

Π

i==outputofacomponentC_γ inthesetCthen 27: addC_γ toHu

28: composeFurther(^Cγ,Hu)

29: else

30: add

λ

#toR 31: endif 32: endif 33: endfor

tempts to generate that data stream by composing sensors and dataprocessing components(from line 5–18).The design philos- ophy behindthe search andcomposition is that priorityis given topreparetheoutputdatastreamusingdirectsensoroutputs(de- notedby S_α). If thisis not possible(e.g. when acertain data el- ementcannot be directlysensed), thealgorithmwill search fora dataprocessingcomponentwhichmaybe abletoproducethere- quiredoutput (denotedby C_γ). If itsucceeds, then the inputsof the selected data processing component will be searched (using the composeFurther(C_γ, H_u)). As illustrated in Fig. 5, this process willcontinueuntilthe algorithms findswaysto producethe ele- mentsintherequiredoutputdatastream.

Phase 4 (Optional): Provide advice and recommendations:

Through comparing SSN ontology and SCO, this phase identities the resourceinsufficiencies andprovides advice to the data con- sumersregardingfuturesensordeploymentsandsoftwarecompo- nentacquisition.Thisphaseprovidesalternativeadviceifthereare multiple waysto address the insufficiencies (e.g. use case2). As presentedinAlgorithm2,resourceinsufficienciesarealsodetected andidentified during the resource composition process. A list of resourceinsufficienciesispreparedandreturnedasR.

Letsconsiderusecase2.Its objectiveisto determineenviron- mental pollution in a city. As presented in Section 3, there are threedifferentsolutions thatthatcan beusedtoachievethisob- jective.Assume,inourIoTsystem,weonlyhaveaccesstosensors SCD andSME .However,thosetwosensors arenotcapableofpro- ducingdatathatisrequiredbyanyoftheexitingDPCs,namelyC₃ andC₄.Therefore,this phase ofourmodel recommendsusers to

Fig. 9. Extracts of different ontological data models used in CASCOM: QA-TDO, SCO [9] , and SSN ontology [10] . The colour coding refers to different prefixes. Prefixes in abbreviated Internationalized Resource Identifiers (IRIs).

Fig. 10. IoT Resource compositions need to be validated before presented to the users. Semantic meanings as well as syntactic definition (e.g. programming level data types) need to matched and compatible.

deployeithersensors S_NDorS_AT.Suchdeploymentswillfulfil the datarequirementsofabovecomponents.

Phase 5 (Optional): Additional context discovery: With the help of knowledge modelled in ontologies, this phase discovers contextinformationthatcanbederived byusingsensordata.Ad- ditional context information such as sensor location and sensor batterylife may be required by applications in orderto perform complex tasks such as geographical visualization and developing energy-aware sensingschedules.Therefore, discoveringadditional contextisimportant.Eachapplicationmayhaveacompulsoryset ofinputsthat itneeds to perform theprimary task,though they

mayaccept additionalcontextinformationinordertoprovideen- hancedresults.

First,all thedata itemsdirectlyretrievedthrough sensors(we call them parameters and denoted by P) are added to a list of context information denoted by M. Such pieces of context infor- mationare referredto asprimary context[25].Eachwrapperhas set of data items(i.e. parameters) it can produce. Set of param- eterproduce by each active wrapperis notedby

{

P⁰,P¹,P²...Pⁿ

}

^.

Next,theseprimarycontextparametersarecomposedwithallex- isting DPCs (denoted by C) to check whether secondary context [25]canbeproduced.Ifpossible,suchsecondarycontextparame- tersarealsoaddedtothelistofcontextinformationdenotedMas well. The contextdiscovery procedures are presented inalgorith- mic perspective in self-explanatory Algorithm3. Further, We can explainthecontextdiscovery procedureusingtheFig.11.Thisal- gorithm works independently from users’ preferences. Further, it canalsobe preprocessed.Thedesignphilosophybehindthisalgo- rithmisthatitattemptstoidentifyallpossiblesecondarycontext information that can be generated by combining all the possible outputsofsensorsaswellasdataprocessingcomponents.Thisal- gorithm isonly requiredto run whena newsensor ordatapro- cessingcomponentappearsorwhenexistingresourcedisappears.

Phase 6 (Optional): Context-based cost calculation: In CAS- COM,the mainobjectiveis toidentify therequired IoT resources ata conceptual-level.In the first5 phases, we achieve thismain objective.Inphase6,wefocusonidentifyingactualIoTresources.

It is importantto note that there can be multipleDPCs that can performsimilartasks.Further,thereare largenumbersofsensors

Algorithm3 Contextdiscovery.

Require: (ListofActiveWrappers).

1: Output:M 2: P=

{

P⁰,P¹,P²...Pⁿ

}

3: P⁰←Listdataitemsavailablethroughactivewrappers 4: addP⁰toM

5: forall Pⁱ∈Pⁿdo 6: forall C∈Cdo 7: forall

λ

#∈Cdo

8: if

λ

#==anyPinthesetPⁱthen 9: addto

λ

#ofCin

σ

10: endif

11: endfor 12: endfor

13: forall C∈Cdo

14: ifAll

λ

#ofC==then 15: addoutputofCtoPⁱ⁺¹ 16: addto

λ

# ofCin

σ

17: endif 18: endfor 19: endfor

20: forall C∈Cdo

21: ifAll

λ

# ofC==then 22: addoutputofCtoM 23: endif

24: endfor

Fig. 11. Primary and secondary context discovery.

availablewithoverlappingandsometimesredundantfunctionality.

In such situation, data consumers maywant to decide the exact criteriathatIoTresourcesselectionprocessshouldconsider.

CASCOMperformsontologicalreasoningtofindoutallpossible solutions. Each solution may combine differentsensors anddata processingcomponentswheretheircostsmaydifferent.Forexam- ple,differenttypesofsensorscanbeusedtomonitorenvironmen- tal pollutionasillustrated inFig.4.Costdoesnotalways referto financialterms(e.g,sensors:energy,bandwidth,latency;datapro- cessing:memoryrequirement,processingtime).Bydefault,allthe contextparameters aretreatedequally.However,userscan define their priorities for each context property in comparative fashion [23].Ifthe userswantmorereliablesensors,thereliability canbe definedwithmorepriority,butitmayincreasethecost.

5. Descriptiongenerationtool

Inourproposedmodel,thedescriptionofIoTresourcesandre- latedknowledge play asignificant role. Today,eventhough there aresophisticated toolsthat canbeusedto developontologiesand modelinstancessuchasProtege[20],theyareverycomplextouse.

Thelearningcurveofthesetoolsaresignificant.Theuserinterface

ofProtegetool,withCASCOMdata modelopened,ispresentedin Fig.12(a).As it is clearlyvisible,the Protege userinterface looks verycomplextosomeonewhohasneverusedit beforeandhard tounderstandwheretoevenbegin.

In CASCOM, we expect data processing components, sensors, anddomain knowledgetobe collectivelydescribedandmodelled by developers, domainexperts, andnon-technical personnel (e.g.

capabilities,inputs,output,etc.).However,not evenall developers arefamiliarwithsemanticmodellingtoolssuchasProtege.There- fore, we built a very simple form-based tool where anyone can learn and use it with very limited effort. They can fill the form andthetoolwillmodeltheaccordingtoCASCOMontologybehind thescenes.Moreimportantly,thistoolcanbeusedtoadd IoTre- sourcedescriptionstoexistingknowledgemodels.Ourform-based knowledgemodellingtoolinpresentedinFig.12(b).Thistoolcon- sists ofnumber to separate tabs where each taballows users to modelcertain type of knowledge(e.g. describe adata processing component,describesensors,adddomainknowledge,etc.).

6. Implementationandexperimentation

This section presents implementation details of our proof of conceptdevelopmentandevaluationfrombothcomputationaland usabilityperspectives.

6.1. Testbed

For proof of concept deployment and evaluation, we used a computerwithIntel(R) Corei7CPU and16GBRAM. Weused the Javaprogramminglanguage todeveloptheCASCOMtool andem- ployed theopen source Apache Jena API to manipulate semantic data.WeusedaJenaTDB-backed⁶ approachtostorethedata.The userinterfacehasbeendevelopedusingtheJavaSwingframework.

WemodelledsensordescriptionsaccordingtotheSemanticSensor NetworkOntology(SSN) [10].Further,we modelleddataprocess- ingcomponents(DPC)descriptionsaccordingtotheSoftwareCom- ponentOntologyPlus(SCO+).TheproposedSCO+ isbasedonSCO [9], butadditionally supportsmodellingcontext informationsuch asaccuracyandreliabilityaspresentedinFig.9.

Toevaluatetheproposed model,wedevelopedasoftwaretool that is illustrated in Fig. 13. First, data consumers can select a question that they can answer from the drop down box. Then, theyareallowedtoanswerthequestion.Possibleanswers willbe listed in the next panel. Next, consumers can either answer an- other question by clicking Answer More button.In contrast,they canclickSearchTasksbuttontosearchpossiblesensingtasks.Pos- siblesensingtasks willbelisted atthe bottomofthenext panel.

Data consumers can select the sensing task they want and click SearchSolutionbutton.CASCOMwillautomaticallygeneratediffer- entcompositionsofIoTresourcethatcanperformthesensingtask requestedbytheconsumer.

6.2.Methodology

We evaluated CASCOM using both qualitative and quantita- tive methods. We analysed andcompared our proposed solution withrespecttotheexistingGSNconfigurationmodel[1].First,let uspresentourquantitativeevaluationstrategy(i.e.computational performance).InFig.14a,weexamined thefeasibilityofCASCOM modelin termofhow much datastorage capacityis requiredas theknowledge-basegrows.InFig.14b,weexaminedthefeasibility ofCASCOMbymeasuringthevariabilityofthedatamodelloading timeastheknowledge-basegrows.Next,inFig.14c,weevaluated

6jena.apache.org/documentation/tdb .

Fig. 12. Semantic Data Modelling Tools: (a) Protege and (b) proposed IoT resource description tool.

Fig. 13. User interface of the software tool that supports CASCOM.

(a) (b) (c)

(d)

''&$

(e) (f)

Fig. 14. CASCOM performance evaluations.