WIXLIB

The Importance of Being ThingOr the Trivial Role of Powering Serious IoT ScenariosSumi HelalAhmed KhaledWyatt LindquistSchool of Computing and Comm.Lancaster UniversityInfoLab21, Lancaster LA1 4WA, UKComputer Science Dept.Northeastern Illinois UniversityChicago, Illinois 60625, USASchool of Computing and Comm.Lancaster UniversityInfoLab21, Lancaster LA1 4WA, lancaster.ac.ukAbstract – In this article, we call for a "Walk Before YouRun" adjustment in the Internet-of-Things (IoT) research anddevelopment exercise. Without first settling the quest for whatthing is or could be or do, we run the risk of presumptuousvisions, or hypes, that can only fail the realities and limits ofwhat is actually possible, leading to customers and consumersconfusion as well as market hesitations. Specifically, without acarefully-designed Thing architecture in place, it will be verydifficult to find the “magic” we are so addicted and accustomedto – programming! Programming the IoT, as we onceprogrammed the mainframe, the workstation, the PC and themobile devices, is the natural way to realize a fancy IoTscenario or an application. Without Thing architectures andtheir enablement of new programming models for IoT – we willcontinue to only envision fancy scenarios but unable to unleashthe IoT full potential. This article raises these concerns andprovides a view into the future by first looking back into ourshort history of pervasive computing. The article focuses on thedomain of “Personal” IoT and will address key newrequirements for such Thing architecture. Also, practicing whatwe preach, we present our ongoing efforts on the Atlas ThingArchitecture showing how it supports a variety of thing notions,and how it enables novel models for programmability.Index Terms –Internet of Things, Thing Architectures,Pervasive Computing, IoT Programming Models, Mobile Apps asIoT Things.I. INTRODUCTIONThe success of the Internet of Things (IoT) will largelydepend on how its main ingredient—the thing—is architectedand prepared to match expectations and to fulfill the bigheroic role that will magically make blue-sky visions areality. Unfortunately, it seems we have not focusedadequately or broadly enough on the architectural aspects ofthings in our pervasive computing journey. Explicitarchitectures addressing vision-enabling requirements need tobe arrived at before we can harness the full potential of IoT.The highly abstracted notion of things, intentionallyembedded within the IoT concept to keep a focus on thepotential end-benefits, could perhaps explain the delay inpaying attention to the architectural details of the things andthe complexities inherent in their wide varieties andfragmented nature. Also, advances in low-powercommunications and light-weight networking protocolshelped steer the initial focus to the internetworking aspects ofIoT, leaving things themselves for later. Now seems to be theright time to focus on things themselves.In this article, we present a brief history of thingsevolution and provide an outlook for the critical research anddevelopment needed to enhance and accelerate theirpreparedness to engage in and power the IoT. We use things,devices, and smart objects interchangeably in this article torefer to things in the IoT ecosystem.II. THING EVOLUTION: BACK TO THE FUTUREThings have evolved considerably in the past 20 years,even though under different names, shapes and forms.Instrumenting devices and everyday objects so that theybecome “digital” things utilizable in a pervasive system wasthe first step in this evolution. Devices and objects were“smartened” by connecting them to a variety ofmicrocontroller boards (also known as sensor/actuatorplatforms) such as the TINI Internet interface [26], the Motefamily [4], the Smart-It board [1] and the Atlas platform[2][3], among several others. Simply attaching tags (e.g.,RFID or QR codes) was another approach to create digitalthings even though tagging required the cooperation of othercompanion things—the tag readers or the cameras. Theseearly devices helped wireless sensor networks (WSN)[11][12] to evolve from theory to practice making it easy touse physical nodes to demonstrate application scenarios. Theopposite was also true where WSN research helpedaccelerate the interconnectivity of these early digital thingssupporting peer-to-peer (ad hoc) and infrastructurecommunication modes.Integrating smart objects effortlessly into systems wasone main goal of these early pervasive computingdevelopments. The goal was more about avoiding ad hocsystem integration which was a non-replicable, rigid andinflexible approach to sustain. Operating systems andmiddleware were developed to enable the effortlessintegration of these early digital things. TinyOS was one ofthe first open source operating systems developed for thingsinitially supporting the mote hardware platform. Gaia [27],Pico [28], Aura and Atlas [29] were among the earlymiddleware developed to enable the promise of effortlessintegration [30].Programming things flexibly into applications was asubsequent and complimentary goal towards effortlessintegration which required changing the actors’ roles.Making smart objects programmable empowered ordinarysoftware developers with no hardware or thing knowledge to1

create pervasive and ubiquitous applications using then dejour programming models (object-oriented and serviceoriented models). Below, we zoom in a little on theintegration and programmability aspects in the journey ofthing evolution [16][17][18].A. Effortless Thing IntegrationHuman- and machine-readable descriptive languagessuch as IEEE 1451 [10], SensorML [9], ECHONET [8],IBM’s Device Kit [25] and Atlas’ DDL [13][14] eased thingintegration problems by shifting quite a bit of theresponsibility and role of integration from the traditionalsystem integrator engineers, to the original equipmentmanufacturers (OEM). This approach was similar to, butmuch lighter in weight than, the universal plug and play(UPnP) standard. The main idea was for a thing OEM toprovide a human- and machine-readable description for itsthing that can be used by configuration tools or run-timemiddleware to generate an integration point out of the thingdescription, automatically.Different integration points were developed, includinglanguage-specific APIs, sandbox services (e.g., OpenServices Gateway Initiative (OSGi) service bundles [7]) andweb-based RESTful services. The descriptive approachproved to be productive and continues to live on to date.Google’s recent Android Thing development (an IoToperating system based on Android) features a similardeclarative core service called Weave which ingfunctional and semantic descriptions of devices and things.B. Programmable ThingsProgramming models also evolved as systematic thingintegration was eased and facilitated by middleware and tooldevelopments. Several models of overlapping types emerged,but we focus here on two key models: context-based andservice-oriented. The former provided for a first sprogrammatically. A context was defined as an explicitspecific state over a collection of things, or an expression thatyields the state of a collection of devices when evaluated.Developing context-driven applications amounted tomodeling, acquiring and reasoning about/reacting to suchcontexts. Context-driven programming models were a greatsuccess, even though they were limited in their expressivepower, ability to model complex applications and capacity toalter or “actuate” contexts.Service-oriented architecture (SOA) [22][23] modelswere also successful and provided for a more expressivealternative, equally powerful in both context sensing andcontext actuation. In this model, devices are integrateddirectly into services, forcing service composition as themodel for programmability of pervasive applications. Theservice-oriented device architecture (SODA) [24] was asuccessful model developed jointly by IBM and the Atlasproject in which devices were integrated into service bundleswithin OSGi, which is a Java sandbox supporting serviceactivation, discovery, invocation and life cycle management.Things are basic services in this model, whereas applicationsare composed of basic and other composite services. Creatinga SODA service for a thing had the effect of “integrate once,program everywhere.” SODA successfully made it to somecommercial products in the form of personal health devicesthat follow the Continua Alliance reference architecture [34],which was initially based on SODA.SOA has undoubtedly been a powerful programmingmodel for pervasive computing, but as it was put to practicaluse in smart space applications (e.g., smart homes), itbecome gradually evident that it was perhaps too powerful tobe safe. Conflicting or even harmful combinations of basic orcomposite services could yield unsafe applications with thepotential of causing harm to the space user, physical damageto the devices themselves, or both. The unconstrainedactuations that could result from direct service invocationswere lacking numerous safeguards. For example, there wasnothing to restrain a buggy application code that erroneouslyinvokes an automatic door opener 50,000 times per second inan infinite loop. The strike mechanism of such a door openerwould jam up and its circuit eventually damaged. SODA alsooverpromised and supplied “fake convenience” to theprogrammers by providing the same kind of interface oftenused for services hosted on powerful servers, to anything,including unreliable pinhead devices. Presenting ants aselephants was a major overpromise with safety, reliabilityand availability concerns. Initial promising solutions toaddress these concerns have recently been proposedincluding virtual things [35] in which multiple identical orequivalent things are utilized into a single virtual thing withsuperior safety, reliability, and availability.The SOA approach also proved to be very productiveand continues to live on to date. In fact, lighter weightversions of SODA exist today such as RESTful web services,often referred to simply as device API’s. The ARM Mbedecosystem, for instance, allows embedded application code,developed and loaded into an ARM Mbed board runningMbed OS, to be externalized and “API’ed” as a “clouddevice service” which is an HTTP-REST service hosted inthe Mbed cloud [31][32].Service architectures like Service Oriented Architecture(SOA), Resource Oriented Architecture (ROA) [6] and EventDriven Architecture (EDA) [5] are considered as frameworksto program the smart space through the explicit trigger of theavailable services provided by the devices and theirappropriate APIs. The social IoT (SIoT), on the other side, isconsidered as a different way of organizing the servicesprovided by the things and discover opportunities for smartspace programmability. The recently proposed ideas onsocial IoT are to logically link the things according to theiridentification attributes (e.g., things collocated in same smartspace, things from same vendor) and to exploit the servicelevel relationships that logically and functionally tie theoffered services to the smart space (e.g., the weather forecastreadings can drive the home thermostat, different coffeemakers offer similar services that compete with each other).2