Reconceptualizing a Family of
Heterogeneous Embedded Systems via
Explicit Architectural Support
Presenter:
Sam Malek
George Mason University
Coauthors: Chiyoung Seo
Nenad Medvidovic
Univ. of Southern California
Sharmila Ravula
Brad Petrus
Bosch Rsrch. & Tech. Center
International Conference on Software Engineering 2007
May, 23, 2007
1
Outline




Motivation
MIDAS
Architectural Middleware
Experience
 Coping with Heterogeneity
 Managing Resource Consumption
 System Development Support
 Conclusion
2
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!
3
Software Architecture
 Software Architecture
 A high-level model of a system
 Represents system organization
–
–
–
–
Components
Connectors
Events
Architectural Style
PDA
Architecture
Gateway Architecture
Service-Oriented
Sub-Architecture
FileInput
Svc
Trouble
LogSvc
Topology
Calculator
EventNotificat
ionSvc
Hub
Operator
Pub-Sub Conn
To other PDAs
Unicast
Conn
Admin
Pub-Sub Conn
To other gateways
Admin
EventDisplay
To other gateways
GwToGw
Processor
SDEngine
Pub-Sub Conn
To sensors
Peer-to-Peer
Sub-Architecture
Sensor
Processor
Pub-Sub Conn
Session
Administrator
SDEngine
SDEngine
Pub-Sub Conn
GwToHub
Processor
Session
Operator
Publish-Subscribe
Sub-Architecture
NodeInfo
Svc
Hub Architecture
Deployer
4
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
5
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?
6
Outline




Motivation
MIDAS
Architectural Middleware
Experience
 Coping with Heterogeneity
 Managing Resource Consumption
 System Development Support
 Conclusion
7
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
8
Requirements
 Requirements for MIDAS:
Non-functional
System development
Software architecture
support
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
Can we do 10 & 11, while achieving 1-9?
9
Outline




Motivation
MIDAS
Architectural Middleware
Experience
 Coping with Heterogeneity
 Managing Resource Consumption
 System Development Support
 Conclusion
10
Prism-MW
Round Robin
Dispatcher
Abstract
Dispatcher
Abstract
Scheduler
NetworkReliability
Monitor
Scaffold
Abstract
Monitor
Fifo
Scheduler
Event
java.io.Serializable
Architecture
IPort
#mutualPort
Port
IComponent
ExtensiblePort
IConnector
Component
Connector
Abstract
Distribution
IArchitecture
SDEngine
Extensible
Event
Abstract
Scaffold
Brick
AbstractService
Discovery
EvtFrequency
Monitor
Extensible Component
AbstractDeployment
IRDistribution
SocketDistribution
Deployer
Admin
 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
11
Prism-MW Extensibility Mechanism
Round Robin
Core class
NetworkReliability
Dispatcher
(subclass of Brick)Monitor
Abstract
Dispatcher
Scaffold
Abstract
Monitor
Fifo
Scheduler
Abstract
Scaffold
Extensible
java.io.Serializable
Class
IPort
Brick
Architecture
AbstractService
Discovery
IConnector Abstract
Abstract
IComponent
Extension 1 Component
Extension 2
Extensible Component
Extension 1,m
Extension 1,1
ExtensiblePort
Abstract
Extension
n
Connector
...
Abstract
Distribution
AbstractDeployment
Extension 2,k
Extension 2,1
Extension n,p
Extension
n,1
SocketDistribution
IRDistribution
...
Admin
...
Deployer
#mutualPort
Port
IArchitecture
SDEngine
Extensible
Event
Event
...
Abstract
Scheduler
EvtFrequency
Monitor
 Core constructs are subclassed via specialized classes
(e.g., ExtensibleComponent, ExtensiblePort) each of
which reference a number of AbstractClasses
12
Outline




Motivation
MIDAS
Architectural Middleware
Experience
 Coping with Heterogeneity
 Managing Resource Consumption
 System Development Support
 Conclusion
13
Requirements
 11 key requirements for MIDAS:
Non-functional
System development
Software architecture
support
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
Prism-MW natively supports requirements 10
and 11, but can it support requirements 1-9?
14
Approach
Scheduler
Dispatcher
Architecture
Scaffold
Port
Event
Style
Constraints
Handler
Uses
Uses
Uses
System
Level
Facilities
Connector
Extends
Component
Extends
Prism-MW’s
Architectural
Support
Extends
Domain
Specific
Facilities
 Separate the core architectural facilities from both
 System level facilities
 Domain specific facilities
15
Requirements
 11 key requirements for MIDAS:
Non-functional
System development
Software architecture
support
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
16
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
17
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
Modular
Virtual
Machine
Thread
Factory
Thread
Abstraction
Mutex
Factory
Mutex
Abstraction
Semaphore
Factory
Semaphore
Abstraction
Event
Factory
Device
Abstraction
File
Factory
Socket
Abstraction
18
Heterogeneity of Computational Substrate
 Ported Prism-MW on top of MVM
 Extensive separation of concerns  Prism-MW remained intact
Abstract
Dispatcher
Abstract
Scheduler
Round Robin
Dispatcher
NetworkReliability
Monitor
Abstract
Monitor
Fifo
Scheduler
Event
Abstract
Scaffold
Brick
IPort
#mutualPort
Port
IComponent
ExtensiblePort
IConnector
Component
Connector
Abstract
Distribution
IArchitecture
SDEngine
Extensible
Event
java.io.Serializable
Architecture
AbstractService
Discovery
EvtFrequency
Monitor
Scaffold
Extensible Component
AbstractDeployment
IRDistribution
SocketDistribution
Deployer
Admin
19
Domain Specific Heterogeneity
Abstract
Dispatcher
Abstract
Scheduler
Round Robin
Dispatcher
NetworkReliability
Monitor
Scaffold
Abstract
Monitor
Fifo
Scheduler
java.io.Serializable
Abstract
Scaffold
Architecture
IPort
#mutualPort
Port
IComponent
ExtensiblePort
IConnector
Component
Connector
Abstract
Distribution
IArchitecture
SDEngine
Extensible
Event
Event
Brick
AbstractService
Discovery
EvtFrequency
Monitor
Extensible Component
AbstractCo
nversion
AbstractDeployment
IPCDistribution
Deployer
Admin
SocketDistribution
JavaToC++Interop
 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
20
Heterogeneity Support
Component
Scheduler
Architecture
Port
Event
Style
Constraints
Scaffold
Handler
Uses
Uses
Support for
Domain
Specific
Heterogeneity
Ex
ten
Component
Connector
se
U
Thread
Abstraction
ds
Architecture
Scaffold
E
n
xte
Port
Style
Constraints
ds
Event
Handler
Uses
s
Dispatcher
JavaToC++
Interop
Socket
Distribution
IPC
Distribution
Scheduler
Support for
Heterogeneity
of Computing
Substrate
Dispatcher
Uses
System
Level
Facilities
Prism-MW’s
Architectural
Support
Connector
Extends
Prism-MW’s
Architectural
Support
Extends
Extends
Domain
Specific
Facilities
Mutex
Abstraction
Semaphore
Abstraction
Device
Abstraction
Socket
Abstraction
21
Requirements
 11 key requirements for MIDAS:
Non-functional
System development
Software architecture
support
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
22
Managing Resource Consumption
Prism-MW’s
Architectural
Support
 Predictability
Scheduler
Dispatcher
Architecture
Scaffold
Port
Event
Style
Constraints
Handler
Uses
Uses
System
Level
Facilities
Connector
Uses
– Ability to estimate the
resources required by a
given application
Component
Extends
– Minimize the runtime
overhead associated with
(de)allocation of resources
Extends
 Performance
Domain
Specific
Facilities
Extends
 Why?
 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
Prism-MW’s
Architectural
Support
Component
Scheduler
Modular
Virtual
Machine
Thread
Factory
Connector
Dispatcher
Mutex
Factory
Architecture
Scaffold
Semaphore
Factory
Event
Port
Style
Constraints
Handler
Event
Factory
File
Factory
23
Requirements
 11 key requirements for MIDAS:
Non-functional
System development
Software architecture
support
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
24
Advanced Facilities
Component
Scheduler
Component
Scheduler
Style
Constraints
Scaffold
Deployment
Connector
Dispatcher
Fault
Tolerance
Architecture
Scaffold
Port
Event
Handler
Uses
Prism-MW’s
Architectural
Support
Resource
Discovery
Architecture
Uses
Advanced Domain
Specific Facilities
Dispatcher
Uses
System
Level
Facilities
Connector
Extends
Prism-MW’s
Architectural
Support
Extends
Extends
Domain
Specific
Facilities
Event
Style
Constraints
Runtime
Adaptation
Port
Handler
25
Meta-Level Components
Abstract
Dispatcher
Abstract
Scheduler
Round Robin
Dispatcher
NetworkReliability
Monitor
Scaffold
Abstract
Monitor
Fifo
Scheduler
java.io.Serializable
Abstract
Scaffold
Architecture
IPort
#mutualPort
Port
IComponent
ExtensiblePort
IConnector
Component
Connector
Abstract
Distribution
IArchitecture
SDEngine
Extensible
Event
Event
Brick
AbstractService
Discovery
EvtFrequency
Monitor
Extensible Component
AbstractCo
nversion
AbstractDeployment
IPCDistribution
Deployer
Admin
SocketDistribution
JavaToC++Interop
 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
26
Deployment, Analysis, and Adaptation
SD
Engine
Comp A
Repository
Comp B
Admin
Architecture 2
DLL
Monitor
DLL
Repository
Effector
Unicast Connector
DLL
Comp A
Byte
Array
DeSi Adapter Arch.
Connector D
Admin
Comp C
Repository
SD
Engine
Architecture 1
27
Advanced Facilities
PDA
Architecture
Gateway Architecture
Service-Oriented
Sub-Architecture
FileInput
Svc
Trouble
LogSvc
Topology
Calculator
EventNotificat
ionSvc
Hub
Operator
Pub-Sub Conn
To other PDAs
Unicast
Conn
Admin
Pub-Sub Conn
To other gateways
Admin
EventDisplay
To other gateways
GwToGw
Processor
SDEngine
Pub-Sub Conn
To sensors
Peer-to-Peer
Sub-Architecture
Sensor
Processor
Pub-Sub Conn
Session
Administrator
SDEngine
SDEngine
Pub-Sub Conn
GwToHub
Processor
Session
Operator
Publish-Subscribe
Sub-Architecture
NodeInfo
Svc
Hub Architecture
Deployer
 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
28
Outline




Motivation
MIDAS
Architectural Middleware
Experience
 Coping with Heterogeneity
 Managing Resource Consumption
 System Development Support
 Conclusion
29
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
30
Questions
31
DeSi
 DeSi is a visual environment that supports specification, analysis, and
manipulation of a distributed software system’s deployment architecture
32
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
33
MIDAS Architecture
DeSi
PDA
Architecture
Gateway Architecture
Service-Oriented
Sub-Architecture
FileInput
Svc
Trouble
LogSvc
Topology
Calculator
EventNotificat
ionSvc
Hub
Operator
Pub-Sub Conn
To other PDAs
Deployer
Unicast Conn
Unicast
Conn
Admin
Pub-Sub Conn
To other gateways
Admin
EventDisplay
To other gateways
GwToGw
Processor
SDEngine
Pub-Sub Conn
To sensors
Peer-to-Peer
Sub-Architecture
Sensor
Processor
Pub-Sub Conn
Session
Administrator
SDEngine
SDEngine
Pub-Sub Conn
GwToHub
Processor
Session
Operator
Publish-Subscribe
Sub-Architecture
NodeInfo
Svc
Hub Architecture
DeSi Adapter
Architecture
Monitor
Effector
 Advanced facilities implemented as meta-level components are shown in
gray
34
PDA
Architecture
Gateway Architecture
Service-Oriented
Sub-Architecture
FileInput
Svc
Trouble
LogSvc
Topology
Calculator
EventNotificat
ionSvc
Hub
Operator
Pub-Sub Conn
To other PDAs
Unicast
Conn
Admin
Pub-Sub Conn
Admin
To other gateways
Peer-to-Peer
Sub-Architecture
EventDisplay
To other gateways
GwToGw
Processor
SDEngine
Pub-Sub Conn
To sensors
Sensor
Processor
Pub-Sub Conn
Session
Administrator
SDEngine
SDEngine
Pub-Sub Conn
GwToHub
Processor
Session
Operator
Publish-Subscribe
Sub-Architecture
NodeInfo
Svc
Hub Architecture
Deployer
Legend:
Prism-MW
Architecture
Component
Meta-level Comp
Request Port
Reply Port
Distribution
Request Port
Service
Distribution
Reply Port
Connector
Pointer
 Advanced facilities implemented as meta-level components are
shown in gray
35
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
36