Modeling Actuation Constraints for IoT Applications

Bharathan Balaji, Brad Campbell, Amit Levy, Xiaozhou Li,Addison Mayberry, Nirupam Roy, Vasuki Narasimha Swamy, Longqi Yang,

Victor Bahl, Ranveer Chandra, Ratul Mahajan

Microsoft Research Student Summit – Internet of Things Working Group

ABSTRACTInternet of Things (IoT) promise to bring ease of monitor-ing, better efficiency and innovative services across manydomains with connected devices around us. With informa-tion from critical parts of infrastructure and powerful cloudbased data analytics, many applications can be developed togain insights about IoT systems as well as transform theircapabilities. Actuation applications form an essential part ofthese IoT systems, as they enable automation as well as fastlow level decision making. However, modern IoT systemsare designed for data acquisition, and actuation applicationsare implemented in an adhoc manner. We identify modelingconstraints in a systematic manner as indispensable to sup-port actuation applications because constraints encompasshigh level policies dictated by laws of physics, legal policies,user preferences. We explore data models for constraints inIoT system with the example of a home heating system, andillustrate the challenges in enforcing these constraints in theIoT system architecture.

1. INTRODUCTIONInternet of Things (IoT) promises to expand connectivity

beyond computers and phones to physical entities embeddedacross various sectors: infrastructure, health, transporta-tion, agriculture [6]. Ubiquitous connectivity will provide uswith a holistic view of the entire system, and insights can bedrawn at various levels of decision making. Device to devicecommunication can lead to unprecedented automation, andinitial innovation from such connectivity can already be seenwith Vehicle to Vehicle communication [8] and multi-robotcoordination [2].

Figure 1 shows a typical pipeline in modern IoT systems.Significant progress has been made in each layer, from lowpower sensors to data analytics in the cloud. To processthe data generated by IoT, however, we need a commondata model across different sources. Standardized APIs ex-posed using RESTful web services have been proposed forabstracting away different communication protocols used byIoT vendors [4]. Domain specific schema and ontologies havebeen proposed to map the IoT data to a standard represen-tation [1, 3].

The data models proposed thus far can map metadataassociated with the IoT device, such as measurement prove-nance, its accuracy, and domain specific attributes. Witha semantic ontology, it is possible to represent relationshipbetween system entities and incorporate these dependenciesin the data analysis. However, much of the data modelinghas been focused on representing information for data analy-

“Thing” Gateway Cloud App User

Figure 1: Typical Data Flow Architecture in IoTSystems

sis. The data models provide little support for applicationsthat can make actuation decisions within the IoT system,and mechanisms for control are implemented in an adhocmanner by application developers.

Control applications form an essential part of the IoTecosystem as they enable automation and implementationof high level policies with little oversight. Examples in-clude autonomous mining, irrigation systems, drone deliverysystem, public transportation. Each of these control appli-cations need to operate within constraints dictated by thedomain. For example, an irrigation system needs to waterthe plantation based on soil type, plant type, ground slopeand should not water sidewalks or humans when present.To implement these control applications, a developer is ex-pected to acquire deep domain knowledge and incorporateconstraints that encapsulate laws of physics, user preferencesinto the application.

Just as modern computer operating systems provide mem-ory protection, fair network sharing and CPU sharing to ap-plications, we need to alleviate developer burden in IoT ap-plications using equivalent mechanisms that provides safetyguarantees and enables policy specification. Many aspectsof control systems are common across and within domains– feedback loops, multiple dependencies, safety regulations,and mechanisms once developed can be reused across thesesystems. We explore methods to model such constraints andbring out challenges in enforcing these constraints.

2. HOME HEATING APPLICATIONConsider an example of a simple home heating system

to illustrate the challenges in implementing a control ap-plication. Figure 2 depicts the essential components in theheating system. The heater controls the temperature of airsupplied to the house and the fan controls the volume andspeed of air flow. The thermostat measures the ambienttemperature, and provides feedback to the heating controlsystem. The thermostat also provides feedback to the usersand captures their temperature preferences. In addition,

arX

iv:1

701.

0189

4v1

[cs

.SY

] 7

Jan

201

7

Heater

Fan

Thermostat Users

Room

SolarPanel ElectricVehicle Weather PowerUtility

Figure 2: Home heating system with a heater forcontrolling air temperature and a fan for modulatingair flow

the heating control system has external influences such asweather, solar power availability and utility events such asdemand response.

Although there are only two control knobs present in thissystem, the control decision has to take many constraintsinto consideration. User preferences dictate that tempera-ture be within a narrow range when the house is occupied.In addition, the air supplied needs to ensure the humidity,air quality and air flow remain within a comfortable range.Equipment constraints include control within available ca-pacity and operating points which causes minimal wear andtear. As the control system in an IoT system has informa-tion from external sources, it can optimize the operation toimprove efficiency by considering outside weather conditionsand availability of solar power or energy storage. Moreover,an intelligent control system needs to respond to demandresponse events from the utility by reducing power demandand sacrificing comfort. Thus, even the simple house heatingsystem application needs to model constraints across manydomains to make control decisions effectively. In a real sys-tem, the decision space may be further constrained by waterheating system, multi-room control and user activities likecooking.

3. MODELING CONSTRAINTSA first step towards reasoning about constraints would

be to model them in a principled manner irrespective ofdomain specifics. We build upon existing data modelingmethods and illustrate a few modeling strategies based onthe heating system example.

3.1 Graph of DependenciesSemantic ontologies provide a systematic way to model re-

lationship between different entities of interest in a domainand has been successfully used to represent domain knowl-edge in a wide variety of applications [3]. Figure 3 showsthe dependencies in the home heating system. Building onthis representation, we also need to quantify the relationshipbetween two entities. For example, we need an equation rep-resenting the relationship between the outdoor temperature

Temperature

SolarOutput

Humidity AirQuality PowerConsumption

Weather:Temperature,Humidity

Regulations:Temperature>45F

Utility:ToUPricing,Demand

Response

ElectricStorage

User:Preferences,Occupancy

Heater:AirTemperature

Fan:AirFlow

HeatingSystem

InputstoHeatingSystem

HeatingSystemCharacteristics

EffectsofHeatingSystem

Figure 3: Model of dependencies between differentmodules in the home heating system

66F 20%70%72F

Setting Fan

Temp Heater

74F 99%99%72F

Setting Fan

Temp Heater

70F 40%80%72F

Setting Fan

Temp HeaterLegal

Illegal65F 70%0%45F

Setting Fan

Temp Heater

Uncomfortable

Comfortable

Figure 4: Example state space model capturing con-straints specified by legal and health policies

and the heating requirements of the house. We also needto capture the feedback loops present in the system (notshown) such as those between the temperature preferencesand the measured temperature.

3.2 State Space ModelThe dependency graph provides a mapping of entities in

the application domain. However, constraints in a systemdepend not only on the entity relationships, but also thereal-time value of these entities. A model of the systemstate space is needed to precisely define the constraints inthe system. Figure 4 shows a simple example of a statespace model, with four essential entities in the home heatingsystem example. The current operating point of system canbe changed in multiple ways, each of which may violate thespecified constraints. The state space model can representthe constraints in the system for each transition as shown inthe figure.

With such a state space model, we can analyze the systemconstraints (legal vs. illegal) and design tradeoffs (energyvs comfort) between different actuation decisions. A graphbased representation also makes the model modular, andconstraints from domains such as solar and power utility canbe added as needed for each instantiation. The challenge isto represent the system state space efficiently, and reducequestions of interest to tractable problems.

4. ENFORCING CONSTRAINTSModeling and enforcing constraints for IoT actuation has

ramifications on many aspects of the system design. Many ofthe design tradeoffs need to be revisited to support actuationapplications and incorporate constraints as an essential partof the system.

4.1 Access RightsIn modern IoT systems, access control is specified at a sin-

gle sensor or actuator level [5]. Such an access control mech-anism no longer suffices for an actuation based system. Eachconstraint in the system can have a large impact on the sys-tem behavior, and users/apps that specify constraints needto be access controlled. The access rights need to representthe different stakeholders in the system operation. For ex-ample, the constraints for safety policies should be specifiedby a health app and equipment operation constraints shouldbe specified by a vendor app. The access control mechanismalso needs to ensure actuation applications do not exceedtheir specified constraints, and the constraints may changewith each application. For example, an emergency evacua-tion app will have a different set of policies governing themcompared to a personalization app.

4.2 Data Model ArchitectureThe cloud provides a convenient, reliable system which

can house the data models and constraint policies. Thecloud also can act as a single point of contact for speci-fying policies across various sectors: legal, health, etc., andthe constraints can be disseminated to each IoT system asthe policies are updated. However, as some actuation deci-sions are latency sensitive, enforcement of constraints mayneed to be local, either using gateways or embedded actua-tor controllers. Thus, the communication protocol betweencloud and local controllers need to be designed with care toensure consistency and reliability.

4.3 Policy TranslationLow level constraints such as safe temperature settings

need to be translated from high level policies. We needto develop appropriate abstractions for policy specificationsso that the constraints align with expected system behav-ior. It is natural that conflicts may occur between policies,and mechanisms are needed for resolving conflicts both stat-ically and dynamically. We can build upon existing applica-tion level conflict resolution strategies such as priority andmanifest checks, and adopt them to constraints implemen-tation [7]. We also need to provide feedback so that thedeveloper can verify that the policies are implemented cor-rectly. For a large system, emulation tools may be necessaryto verify complex interactions between different policies.

5. CONCLUSIONModern IoT systems are designed for data acquisition and

analytics, with little support for actuation based applica-tions. A critical part of actuation decisions is analysis ofconstraints in the system as dictated by laws of physics, userpreferences and local laws. We explore data models that canbe used for modeling constraints in an IoT system, buildingon top of semantic ontology models. With the example ofa home heating system, we show that data models need toencapsulate the relationship between entities in an IoT sys-tem and the decision state space of the system to precisely

specify constraints. Many challenges need to be addressedto enforce these constraints in an IoT system. We eluci-date some of these challenges with a focus on access controlmechanisms, data model architecture and policy translation.

6. REFERENCES[1] P. Barnaghi, W. Wang, C. Henson, and K. Taylor.

Semantics for the Internet of Things: early progressand back to the future. International Journal onSemantic Web and Information Systems (IJSWIS),8(1):1–21, 2012.

[2] W. Burgard, M. Moors, C. Stachniss, and F. E.Schneider. Coordinated multi-robot exploration.Robotics, IEEE Transactions on, 21(3):376–386, 2005.

[3] M. Compton, P. Barnaghi, L. Bermudez,R. GarcıA-Castro, O. Corcho, S. Cox, J. Graybeal,M. Hauswirth, C. Henson, A. Herzog, et al. The SSNontology of the W3C semantic sensor networkincubator group. Web Semantics: Science, Services andAgents on the World Wide Web, 17:25–32, 2012.

[4] S. Dawson-Haggerty, X. Jiang, G. Tolle, J. Ortiz, andD. Culler. sMAP: a simple measurement and actuationprofile for physical information. In Proceedings of the8th ACM Conference on Embedded Networked SensorSystems, pages 197–210. ACM, 2010.

[5] C. Dixon, R. Mahajan, S. Agarwal, A. Brush, B. Lee,S. Saroiu, and P. Bahl. An operating system for thehome. In Presented as part of the 9th USENIXSymposium on Networked Systems Design andImplementation (NSDI 12), pages 337–352, 2012.

[6] D. Evans. The internet of things: How the nextevolution of the internet is changing everything. CISCOwhite paper, 1:1–11, 2011.

[7] S. Munir and J. A. Stankovic. Depsys: Dependencyaware integration of cyber-physical systems for smarthomes. In Cyber-Physical Systems (ICCPS), 2014ACM/IEEE International Conference on, pages127–138. IEEE, 2014.

[8] D. Reichardt, M. Miglietta, L. Moretti, P. Morsink, andW. Schulz. CarTALK 2000: Safe and comfortabledriving based upon inter-vehicle-communication. InIntelligent Vehicle Symposium, 2002. IEEE, volume 2,pages 545–550. IEEE, 2002.