This document proposes a model-driven development framework for developing Sense-Compute-Control (SCC) applications. SCC applications involve sensors collecting data from the environment, computational services processing the data, and actuators controlling the environment. The framework aims to enable development of SCC applications with minimal effort from stakeholders by integrating modeling languages, addressing SCC characteristics, and automation techniques. It includes vocabulary, architecture, and deployment modeling languages as well as frameworks to generate code for different platforms from the models.

1. A Model-driven Development Framework for
Developing Sense-Compute-Control
Applications
Pankesh Patel*, Brice Morin**, Sanjay Chaudhary*
*Institute of ICT, Ahmedabad University, India
**SINTEF ICT, Oslo, Norway
ICSE 2014 Workshop - Modern Software Engineering Methods for
Industrial Automation (MoSEMInA)
Hyderabad, May 31, 2014

2. 2
Environment
(or Domain)
Sensor(s)
Actuator(s)
Computational
service
calculating avg. temp,
setting temp-level
sense
control
Sense-Compute-Control (SCC)
Slide credit: Damien Cassou - http://www.slideshare.net/DamienCassou/phd-thesis-
defense

3. SCC: application domains
3
 Cover various application domains
 Industrial control
 Robotics
 Smart cities
 Building automation
 Physical-Cyber-Social
image credit to organizations, who own copyrights of used
images

4. 4
 Involves a large number of heterogeneous devices,
processing elements
 Composes multiple activities
 Interacts with users whenever necessary
Characteristics: SCC application

5. Illustrative example: building system
5
Large numbers of heterogeneous devices
Smoke
detector
User interfaces
(e.g., display,
mobile phones)
Fire
alarm
Badge
reader
User with
badge
Data
storage
Light
Temperature
sensor
Heater
An application - compose multiple
activities (e.g., detect user’s entry ,
query, set threshold)

6. Our goal
6
“Enable development** of SCC applications
with minimal effort by various stakeholders*
involved in development process”
**Development -- “a set of related activities that leads to a production of a software product.’’ [Ian
Sommerville, Software Engineering (9th edition) , 2010]
*Stakeholders in software engineering to mean – people, who are involved in the application
development. Examples of stakeholders defined in [Taylor et al., Software Architecture, 2009] are
software designer, developer, domain expert, technologist, etc.

7. Application development challenges
7
 Heterogeneity
 Types of devices (e.g., sensor,
actuator, storage, processing
elements, user interfaces)
 Interaction modes (e.g.,
publish/subscribe,
request/response, command)
 Platforms (e.g., Android,
JavaSE)
Spreads into the application code,
Makes the portability of code
difficult
image credit to organizations, who own copyrights of used
images

8. Application development challenges
8
 Heterogeneity
 Large number
 Application logic in terms of
a set of distributed tasks for
hundreds to thousands of
devices
To reason at such levels of
scale is impractical in general
image credit to organizations, who own copyrights of used
images

9. Application development challenges
9
 Heterogeneity
 Large number
 Multiple expertise
 Knowledge from multiple
concerns intersect
Application domain
Software design
Algorithm design,
programming languages
Platform-specific
knowledge
Clear conflict with skill possessed
by the individual developer
Deployment
area
image credit to organizations, who own copyrights of used
images

10. Application development challenges
10
 Heterogeneity
 Large number
 Multiple expertise
 Different life-cycle
phases
Development Deployment
Evolution
Tasks has to be
decomposed
in a large number of
devices
Application -
designed/implemented
into a set of distributed tasks for
heterogeneous devices
Changes in application
requirements
Changes in deployed devices
Software development life cycle phases -- requirement analysis, design, implementation, testing,
evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010]

11. Existing approaches
11
 Node-centric programming
 Think in terms of activities of
individual device & encode
interactions
 Encode node interaction with other
nodes explicitly addressed by
Id/location
 Large number – not useful
Olympus with Gaia [Ranganathan et al., Percom, 2005], Context Toolkit
[Dey et al., HCI, 2001], TinyOS [Levis et al., MDM, 2006], Physical virtual
mashup [Guinard et al., NSS, 2010]

12. Existing approaches
12
 Node-centric programming
 Macro-programming
 Abstractions for high-level
collaborative behaviors
 Lack of software engineering
methodology to support life
cycle phases – results in
difficult to maintain, reuse,
and platform-dependent
design
Regiment [Newton et al., IPSN, 2007], MacroLab [Hnat et
al. , SenSys, 2008]

13. Existing approaches
13
 Node-centric programming
 Macro-programming
 Model-driven development
 Vertical SoC – reduce app.
development complexity
separating PIM and PSM
 Horizontal SoC – reduce app.
development complexity by
separating different aspects of
a system
Transformation and
code generators
PIM
PSM
E.g., J2SE E.g., .Net
PSM…
C1 C2 Cn…
Horizontal
Separation of
Concerns (SoC)
Vertical
separation of
concerns
ATaG [Pathak et al., DCSN, 2011], RuleCaster [Bischoff
et al., EuroSSC, 2006], DiaSuite [Cassou et al., TSE,
2012], PervML [Serral et al., Journal of Pervasive and
Mobile computing, 2010], Pantagruel [Drey et al., Percom,
2010]

14. Early Contributions
14
 A comprehensive approach that utilizes advantages
of existing MDD and macro-programming
approaches, while focusing on ease of IoT
application development
 Development framework* to integrates modeling
languages, addressing SCC application characteristics,
and automation techniques
*It includes support programs, code libraries, high-level languages or other software that help
stakeholders to develop and glue together different components of a software product [Ian
Sommerville, Software Engineering (9th edition) , 2010].

15. Commonality
at various levels
15
Functionality
(e.g., home
fire detection
Domain
(e.g., building
HVAC)
(e.g., Inria
Office)
(e.g., Google
Office)
Deployment
Room
temperature
(e.g. building
automation)
Building fire
state
“Reusability
across concerns”
image credit to organizations, who own copyrights of used
images
“Entities of Interest (EoI) is an object,
including the attributes that describes it, and
its state that is relevant from a user or an
application perspective.”
[Stephan Haller, Internet of Things, 2010]

16. 16
Domain
Room
temperature
(e.g. building
automation)
Actuator
Sensor
Domain
Storage
Concepts that are responsible
for interacting with EoI of a
domain
- Sensor, actuator, storage
Building fire
state
image credit to organizations, who own copyrights of used
images

17. 17
Domain
Room
temperature
(e.g. building
automation)
Functionality
Functionality
Home fire
detection
Building
HVAC
Computational
service
StorageSensor
Computational
service
responserequest
publish/
subscribe
Concepts that are responsible for
- processing data and taking
decisions
Building fire
state
command
Actuator
image credit to organizations, who own copyrights of used
images

18. 18
Domain
Room
temperature
(e.g. building
automation)
Deployment
Functionality
Inria
office
Google
office
Deployment
Device
Device
Device
Device Device
Building fire
state
Concepts to describe various
properties of devices
Sensor Storage
Computational
service
Computational
service
responserequest
publish/
subscribe
Home fire
detection
Building
HVAC
Actuator
image credit to organizations, who own copyrights of used
images

19. Actuator
19
Domain
(e.g. building
automation)
Modeling
languages
Functionality
Inria
office
Google
office
Deployment
Device
Device
Device
Device
Sensor Storage
Computational
service
Computational
service
Home fire
detection
Building
HVAC
Vocabulary
Language (VL)
Architecture
Language
(AL)
Deployment
Language
(DL)

20. Our
approach
20
Domai
n
expert
Vocabulary
spec.
Compilation
of vocabulary
Device
develope
r
Device
driver
Vocabulary
framework
Architectur
e
spec.
Compilation
of architecture
Deployment
spec.
Mapper
Application
developer
Application
logic
Architectur
e
frameworkSoftware designer
Network
manager
Linker
Android
devices
PC
PC
Mapping
files
Generated code
For Device X
Middleware

21. Domain &
Functional concern
21
Domai
n
expert
Vocabulary
spec.
Compilation
of vocabulary
Architectur
e
spec.
Software designer
Computational
service
Computational
service
Software designer –
understands software
architecture concepts
StorageSensor
retrievalsensor
measurement
Actuator
action
Domain expert (e.g. biologist,
medical system designer)
understands domain
concepts.

22. 22
Domai
n
expert
Vocabulary
spec.
Compilation
of vocabulary
Architectur
e
spec.
Compilation
of architecture
Application
developer
Architectur
e
frameworkSoftware designer
Functional
concern
Application
logic
Application developer – skilled in algorithm
design & use of programming lang.
Architecture framework (in object-oriented
GPL)
- Contains abstract classes
- Concrete methods
- Abstract methods

23. 23
RoomAvgTemp
consume tempMeasurement from hops:0:Room;
generate roomAvgTemp:TempStruct;
in-region:Room; Compiler
generat
es
private String partitionAttribute = "Room";
public void subscribeTempMeasurement() {
PubSubMiddleware.subscribe(this, “tempMeasurement",
subscriptionCondition);
}
public void notifiedReceived (String event Name, Object arg,
Device deviceInfo) {
if (eventName.equals(“tempMeasurement”) {
onNewTempMeasurement((TempStruct) arg) ;
}
}
public abstract void onNewTempMeasurement(TempStruct arg);
Implementing
application logic
Concrete
method for
Subscriptio
n
request
Concrete
method for
Receiving
notification
s

24. 24
public abstract void onNewTempMeasurement(TempStruct arg);
Implementing
application logic
public void onNewtempMeasurement(TempStruct arg) {
// Write here Application Logic of Calculating
Average Temperature
}
Application
developer
Implement abstract method
to write application logic

25. 25
Domai
n
expert
Vocabulary
spec.
Compilation
of vocabulary
Deployment
spec.
Mapper
Network
manager
Mapper – decides device where each
computational service will be executing
Deployment
concern
Mapping
files
Architectur
e
spec.
Compilation
of architecture
Application
developer
Application
logic
Architectur
e
frameworkSoftware designer

26. 26
Domai
n
expert
Vocabulary
spec.
Compilation
of vocabulary
Device
develope
r
Device
driver
Vocabulary
framework
Deployment
spec.
Mapper
Network
manager
Mapping
files
Platform
concern
Architectur
e
spec.
Compilation
of architecture
Application
developer
Application
logic
Architectur
e
frameworkSoftware designer
• Device developer – understands
inputs/outputs, protocols of
device platform
Vocabulary Framework
• Abstract classes with
concrete methods,
interfaces

27. Implementing
device driver
27
public interface ITemperatureSensor {
public TempStruct getTempMeasurement();
public void getTempMeasurement(ListenerTempMeasurement handler);
}
Compiler
generates
TemperatureSensor
generate tempMeasurement:TempStruct;

28. Implementing
device driver
28
Device
developer
implements
interfaces
public class JavaSETemperatureSensor
implements ITemperatureSensor {
@Override
public TempStruct gettempMeasurement() {
// TODO: Write Device Driver
}
@Override
public void gettempMeasurement(ListenertempMeasurement handler) {
// TODO: Write Device Driver
}
}

29. 29
Domai
n
expert
Vocabulary
spec.
Compilation
of vocabulary
Device
develope
r
Device
driver
Vocabulary
framework
Architectur
e
spec.
Compilation
of architecture
Deployment
spec.
Mapper
Application
developer
Application
logic
Architectur
e
frameworkSoftware designer
Network
manager
Linker
Android
devices
PC
PC
Mapping
files
Linking
Generated code
For Device X
Middleware

30. Summary and Ongoing work
30
 Application development challenges:
 a large number of heterogeneous devices, multiple expertise,
different life cycle phases
 Existing approaches
 Node-centric programming, database, WSN
macroprogramming, model-driven development
 Our approach
 Separation of concerns, modeling languages, automation,
development framework
 Ongoing work
 Evaluation – development effort, reusability, generated code
metrics
 Mapping Algorithm addressing heterogeneity of devices

31. 31
Thanks for listening me 
Email: pankesh.patel@ahduni.edu.in
Implementation of this work with
documentations, running on both Android
and JavaSE device and MQTT middleware
https://github.com/pankeshlinux/IoTSuite/wiki