A model driven development framework for developing sense-compute-control applications

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

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

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

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

Large numbers of heterogeneous devices

Smoke detector

User interfaces(e.g., display, mobile phones)

Firealarm

Badge reader

User withbadge

Data storage

Light

Temperature

sensorHeater

An application - compose multiple activities (e.g., detect user’s entry , query, set threshold)

6

Our goal

“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

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


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


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


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 requirementsChanges in deployed devices

Software development life cycle phases -- requirement analysis, design, implementation, testing, evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010]

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

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

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…

HorizontalSeparation of

Concerns (SoC)

Verticalseparation 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 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

Functionality (e.g., home

fire detection

Domain

(e.g., building HVAC)

(e.g., Inria Office)

(e.g., GoogleOffice)

Deployment

Room temperatur

e

(e.g. building automation)

Building fire state

“Reusabilityacross concerns”


“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

Domain

Room temperatur

e


Actuator

Sensor

Domain

Storage

Concepts that are responsible for interacting with EoI of a domain- Sensor, actuator,

storage

Building fire state


17

Domain

Room temperatur

e


Functionality

FunctionalityHome fire detection

Building HVAC

Computationalservice

StorageSensor


response

requestpublish/

subscribeConcepts that are responsible for - processing data and taking decisions

Building fire state

command

Actuator


18

Domain

Room temperatur

e


Deployment

Functionality

Inria office

Googleoffice

Deployment

Device

Device

Device

Device Device

Building fire state

Concepts to describe various

properties of devices

Sensor Storage



response

requestpublish/

subscribe

Home fire detection

Building HVAC

Actuator


19

Actuator

Domain


Modeling languages

Functionality

Inria office

Googleoffice

Deployment

Device

Device

Device

DeviceSensor Storage



Home fire detection

Building HVAC

Vocabulary Language (VL)

Architecture Language

(AL)

Deployment Language

(DL)

20

Our approach

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Device develop

er

Device driver

Vocabulary

framework

Architecture

spec.Compilation

of architecture

Deployment spec.

Mapper

Application developer

Application logic

Architecture

framework

Software designer

Networkmanager

Linker

Android devices

PC

PC

Mapping

files

Generated codeFor Device X

Middleware

21

Domain & Functional concern

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Architecture

spec.

Software designer



Software designer – understands software architecture concepts

StorageSensor

retrievalsensor measurement

Actuator

action

Domain expert (e.g. biologist, medical system designer) understands domain concepts.

22

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Architecture

spec.Compilation

of architecture


Architecture

framework

Software 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

RoomAvgTemp consume tempMeasurement from hops:0:Room; generate roomAvgTemp:TempStruct; in-region:Room; Compiler

generates

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

forSubscripti

onrequest Concrete method

forReceivingnotificatio

ns

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

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Deployment spec.

MapperNetworkmanager

Mapper – decides device where each computational service will be executing

Deployment concern

Mapping

files

Architecture

spec.Compilation

of architecture


Application logic

Architecture

framework

Software designer

26

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Device develop

er

Device driver

Vocabulary

framework

Deployment spec.

MapperNetworkmanager

Mapping

files

Platformconcern

Architecture

spec.Compilation

of architecture


Application logic

Architecture

framework

Software designer

• Device developer – understands inputs/outputs, protocols of device platform

Vocabulary Framework• Abstract classes with

concrete methods, interfaces

27

Implementing device driver

public interface ITemperatureSensor { public TempStruct getTempMeasurement(); public void getTempMeasurement(ListenerTempMeasurement handler);}

Compiler

generates

TemperatureSensor generate tempMeasurement:TempStruct;

28

Implementing device driver

Device develope

r

implements

interfaces

public class JavaSETemperatureSensor implements ITemperatureSensor {

@Overridepublic TempStruct gettempMeasurement() { // TODO: Write Device Driver}

@Overridepublic void gettempMeasurement(ListenertempMeasurement handler) {

// TODO: Write Device Driver }}

29

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Device develop

er

Device driver

Vocabulary

framework

Architecture

spec.Compilation

of architecture

Deployment spec.

Mapper


Application logic

Architecture

framework

Software designer

Networkmanager

Linker

Android devices

PC

PC

Mapping

files

LinkingGenerated code

For Device X

Middleware

30

Summary and Ongoing work 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

Thanks for listening me Email: [email protected]

Implementation of this work with documentations, running on both Android and JavaSE device and MQTT middleware

https://github.com/pankeshlinux/IoTSuite/wiki



A model driven development framework for developing sense-compute-control applications

Engineering

Transcript of A model driven development framework for developing sense-compute-control applications