1 reconceptualizing a family of heterogeneous embedded systems via explicit architectural support...

1

Reconceptualizing a Family of Heterogeneous Embedded Systems via

Explicit Architectural Support

Presenter: Sam MalekGeorge Mason University

Coauthors: Chiyoung Seo Sharmila RavulaNenad Medvidovic Brad PetrusUniv. of Southern California Bosch Rsrch. & Tech. Center

International Conference on Software Engineering 2007May, 23, 2007

2

Outline

Motivation MIDAS Architectural Middleware Experience

Coping with HeterogeneityManaging Resource ConsumptionSystem Development Support

Conclusion

3

Software Engineering for Embedded Systems

Proliferation of distributed embedded devices E.g., Wireless Sensor Networks (WSN) Widely used across many domains

Many organizations are developing families of embedded applications intended to execute on WSN

Software engineering for WSN is challenging Requirements: fault-tolerant, efficient,

scalable, etc. Constraints: limited battery power, memory,

processor, etc. Therefore, software intended for WSN is

often very complex!

4

Software Architecture

NodeInfoSvc

SDEngine

SessionAdministrator

SessionOperator

SensorProcessor

GwToHubProcessor

GwToGwProcessor

Gateway Architecture Hub Architecture

SDEngine

Hub Operator

EventNotificationSvc

TroubleLogSvc

PDA Architecture

EventDisplay

DeployerAdmin

Admin

SDEngine

To

oth

er gatew

ays

To

oth

er PD

As

Service-OrientedSub-Architecture

Publish-SubscribeSub-Architecture

FileInputSvc

Peer-to-Peer Sub-Architecture

To

senso

rs

To

oth

er gatew

ays

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Un

icast C

on

n

TopologyCalculator

Software Architecture A high-level model of a system Represents system organization

– Components– Connectors– Events– Architectural Style

5

From Architectures to Implementation There is a gap between architectural diagrams and low-level PL

constructs

Existing middleware technologies do not support important architectural concepts E.g., architectural styles, explicit connectors

End result Architectural erosion: architecture does not match the implementation

Architecture-based software development has been shown to work Using the architectural constructs as the basis of implementation, deployment,

and evolution

Practitioners have concerns on its applicability to embedded systems Another layer of abstraction Not efficient enough Lack of fine-grain control over system’s resources Not predictable enough

6

Motivating Questions

Is architecture-based development a viable option for embedded systems? Is it efficient? Does it scale?

What are the characteristics of an infrastructure that provides support for architecture-based development in embedded domains? What are the required facilities? What are the dependencies and relationships?

7

Outline



Conclusion

8

MIDAS

Bosch’s family of sensor network applications Sensors

– Monitor the environment around them

Gateways– Aggregate and fuse the data received

from the sensors

– Manage the sensors

Hubs– Visualize the data received from the

gateways

– Provide administrative services for managing the gateways and sensors

PDAs– Events could be forwarded to the

PDAs used by the mobile operators

9

Requirements Requirements for MIDAS:

1. Heterogeneity

2. Performance

3. Scalability

4. Manage Resource Consumption

5. Fault-Tolerance

6. System Modeling and Analysis

7. Component-Based Deployment

8. Service Discovery

9. Monitoring System and Software Properties

10. Architecture-Based Development

11. Multiple Architectural Styles

Non-functional

System development

Software architecture support

Can we do 10 & 11, while achieving 1-9?

10

Outline



Conclusion

11

Prism-MW

A middleware intended for architecture-based development Provides PL-level constructs for architectural concepts One-to-one mapping of architectural concepts and their implementation

Full-featured version of Prism-MW was developed in Java

IConnector

Abstract Monitor

Scaffold

Abstract Dispatcher

Round Robin Dispatcher

Abstract Scheduler

Fifo Scheduler

Abstract Scaffold

Brick

Architecture

Component Connector

Event

Port

IComponent

IPort

java.io.Serializable

IArchitecture

#mutualPort

Extensible Component

AbstractServiceDiscovery

AbstractDeployment

AdminDeployer

ExtensiblePort

AbstractDistribution

SocketDistribution

IRDistribution

NetworkReliabilityMonitor EvtFrequency

Monitor

Extensible Event

SDEngine

12

Prism-MW Extensibility Mechanism

Core constructs are subclassed via specialized classes (e.g., ExtensibleComponent, ExtensiblePort) each of which reference a number of AbstractClasses

IConnector

Abstract Monitor

Scaffold

Abstract Dispatcher


Abstract Scheduler

Fifo Scheduler

Abstract Scaffold

Brick

Architecture

Component Connector

Event

Port

IComponent

IPort


IArchitecture

#mutualPort



AbstractDeployment

AdminDeployer

ExtensiblePort


SocketDistribution

IRDistribution


Monitor

Extensible Event

SDEngine

Extension 1,m

Abstract Extension 2

Extensible Class

Core class (subclass of Brick)

Extension 1,1

Abstract Extension 1 ...

Abstract Extension n

...

Extension 2,k

Extension 2,1

...

Extension n,p

Extension n,1

...

13

Outline



Conclusion

14

Requirements 11 key requirements for MIDAS:

1. Heterogeneity

2. Performance

3. Scalability


5. Fault-Tolerance







Non-functional

System development


Prism-MW natively supports requirements 10 and 11, but can it support requirements 1-9?

15

Approach

Separate the core architectural facilities from both System level facilities Domain specific facilities

DomainSpecificFacilities

Prism-MW’s Architectural

Support

SystemLevel

Facilities

Scheduler Dispatcher Scaffold

Component Connector Architecture

Style Constraints Handler

PortEvent

Extends

Uses

Uses

Uses

Extends

Extends

16


1. Heterogeneity

2. Performance

3. Scalability


5. Fault-Tolerance







Non-functional

System development


17

Coping with Heterogeneity

Wide spectrum of devices with different capabilities

Types of heterogeneity in MIDAS Hardware Platform

– ARM-based, Compaq iPAQ, KwyikByte, Intel-based, proprietary sensor platforms

System software– Windows CE, XP, Linux, eCos

Programming Language– C++ and Java

Network– Wireless network cards with TCP/IP, infrared or serial port with IPC

18

Modular Virtual Machine (MVM) A configurable family of utilities that provide an abstraction layer on top of

the computational substrate Resource abstractions Implementations Factories

The pluggable nature of MVM can be used to customize it An executable image of MVM is created by building the source code with the

appropriate implementation files included

ThreadAbstraction

MutexAbstraction

SemaphoreAbstraction

Device Abstraction

SocketAbstraction

Thread Factory

MutexFactory

Semaphore Factory

EventFactory

File Factory

Modular Virtual

Machine

19

Heterogeneity of Computational Substrate

Ported Prism-MW on top of MVM

Extensive separation of concerns Prism-MW remained intact

IConnector

Abstract Monitor

Scaffold

Abstract Dispatcher


Abstract Scheduler

Fifo Scheduler

Abstract Scaffold

Brick

Architecture

Component Connector

Event

Port

IComponent

IPort


IArchitecture

#mutualPort



AbstractDeployment

AdminDeployer

ExtensiblePort


SocketDistribution

IRDistribution


Monitor

Extensible Event

SDEngine

20

IConnector

Abstract Monitor

Scaffold

Abstract Dispatcher


Abstract Scheduler

Fifo Scheduler

Abstract Scaffold

Brick

Architecture

Component Connector

Event

Port

IComponent

IPort


IArchitecture

#mutualPort



AbstractDeployment

AdminDeployer

ExtensiblePort


SocketDistribution

IPCDistribution


Monitor

Extensible Event

AbstractConversion

JavaToC++Interop

SDEngine

Domain Specific Heterogeneity

Domain specific heterogeneity is not abstracted away by a virtual machine layer

An architectural middleware’s extensibility and flexibility are essential to cope with these kinds of heterogeneity

21

Heterogeneity Support

Support for Domain Specific

Heterogeneity


Support

Support for Heterogeneity of Computing

Substrate ThreadAbstraction

MutexAbstraction

SemaphoreAbstraction

Device Abstraction

SocketAbstraction




Port Event

Extends

Uses U

ses

IPCDistribution

SocketDistribution

JavaToC++Interop

Extends



Support

SystemLevel

Facilities




PortEvent

Extends

Uses

Uses

Uses

Extends

Extends

22


1. Heterogeneity

2. Performance

3. Scalability


5. Fault-Tolerance







Non-functional

System development


23

Managing Resource Consumption Why?

Performance– Minimize the runtime

overhead associated with (de)allocation of resources

Predictability– Ability to estimate the

resources required by a given application

Resource pools Pre-allocate system-level as

well as architectural-level objects

Factory facilities Export an API used by

application developers for accessing instances of objects



Support

SystemLevel

Facilities




PortEvent

Extends

Uses

Uses

Uses

Extends

Extends


Support

Modular Virtual

Machine Thread Factory

MutexFactory

Semaphore Factory

EventFactory

File Factory




PortEvent

24


1. Heterogeneity

2. Performance

3. Scalability


5. Fault-Tolerance







Non-functional

System development


25

Advanced Facilities



Support

SystemLevel

Facilities




PortEvent

Extend

sU

ses

Uses

Uses

Extend

s

Extend

s

Advanced Domain Specific Facilities


Support




PortEvent

Resource Discovery

Deployment Fault Tolerance

Runtime Adaptation

26

Meta-Level Components

A meta-level component is an ExtensibleComponent with the appropriate implementation of an extension installed on it

ExtensibleComponent can change the system’s software architecture

IConnector

Abstract Monitor

Scaffold

Abstract Dispatcher


Abstract Scheduler

Fifo Scheduler

Abstract Scaffold

Brick

Architecture

Component Connector

Event

Port

IComponent

IPort


IArchitecture

#mutualPort



AbstractDeployment

AdminDeployer

ExtensiblePort


SocketDistribution

IPCDistribution


Monitor

Extensible Event

AbstractConversion

JavaToC++Interop

SDEngine

27Architecture 1

SD Engine

DeSi Adapter Arch.

Architecture 2

Deployment, Analysis, and Adaptation

Admin

Admin

Monitor

Effector

Repository

Repository

Repository

Comp B

Comp A

Comp C

Connector D

Un

ica

st C

on

ne

cto

r

DLL DLL

DLL

ByteArray

Comp A

SD Engine

28

Advanced Facilities

Advanced facilities on top of architectural layer has two advantages keeps the core small reaps the benefits of architectural middleware for these facilities as well

NodeInfoSvc

SDEngine


SessionOperator

SensorProcessor

GwToHubProcessor

GwToGwProcessor


SDEngine

Hub Operator


TroubleLogSvc

PDA Architecture

EventDisplay

DeployerAdmin

Admin

SDEngine

To

oth

er gatew

ays

To

oth

er PD

As



FileInputSvc


To

senso

rs

To

oth

er gatew

ays

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Un

icast C

on

n

TopologyCalculator

29

Outline



Conclusion

30

Conclusion

Architecture-based development can be achieved effectively in the embedded domain

The MIDAS experience has increased our understanding of architectural middleware

Prism-MW’s design helped us to clearly separate system, architectural, and domain specific facilities from one another

31

Questions

32

DeSi

DeSi is a visual environment that supports specification, analysis, and manipulation of a distributed software system’s deployment architecture

33

Efficiency vs. Configuration Complexity

Pro: more efficiency and control Con: much harder to configure

Size of event queue Number of pre-allocated system resources: thread, mutexes, sempahores,

etc. Number of pre-allocated architectural constructs: components, ports,

connectors, etc. Size of network sockets

There is a clear trade-off between resource utilization control and configuration complexity of a middleware solution

34

MIDAS Architecture

Advanced facilities implemented as meta-level components are shown in gray

NodeInfoSvc

SDEngine


SessionOperator

SensorProcessor

GwToHubProcessor

GwToGwProcessor


SDEngine

Hub Operator


TroubleLogSvc

PDA Architecture

EventDisplay

DeployerAdmin

Admin

Effector

Monitor

DeSi Adapter Architecture

SDEngine

To

oth

er gatew

ays

To

oth

er PD

As



FileInputSvc


To

senso

rs

To

oth

er gatew

ays

DeSi

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Un

icast Co

nn

Un

icast C

on

n

TopologyCalculator

35

Advanced facilities implemented as meta-level components are shown in gray

Legend:

NodeInfoSvc

SDEngine


SessionOperator

Component

Request Port Reply PortDistribution Request Port

Distribution Reply Port

SensorProcessor

GwToHubProcessor

GwToGwProcessor


SDEngine

Hub Operator


TroubleLogSvc

ServiceMeta-level Comp

PDA Architecture

EventDisplay

DeployerAdmin

Admin

SDEngine

To

oth

er gatew

ays

To

oth

er PD

As



FileInputSvc


To

senso

rs

To

oth

er gatew

ays

Prism-MW Architecture

Pointer

Connector

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Pu

b-S

ub

Co

nn

Un

icast C

on

n

TopologyCalculator

36

Conclusion

The results demonstrate that it is feasible to apply principles of software architecture in an embedded setting

The MIDAS experience has increased our understanding of architectural middlewares It helped us to clearly separate system,

architectural, and domain-specific facilities from one another

MIDAS is an ongoing project

1 reconceptualizing a family of heterogeneous embedded systems via explicit architectural support...

Documents

embedded domains

architectural styles

architectural diagrams

architectural constructs

systems resources

wsnsoftware engineering

efficient enoughlack

grain control