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 Malek
• George Mason University
• Coauthors Chiyoung Seo Sharmila Ravula
• Nenad Medvidovic Brad Petrus
• Univ. of Southern California Bosch Rsrch.
  Tech. Center
• International Conference on Software Engineering
  2007
• May, 23, 2007

2
Outline

• Motivation
• MIDAS
• Architectural Middleware
• Experience
• Coping with Heterogeneity
• Managing Resource Consumption
• System 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

• 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 systems
  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

• Motivation
• MIDAS
• Architectural Middleware
• Experience
• Coping with Heterogeneity
• Managing Resource Consumption
• System Development Support
• Conclusion

8
MIDAS

• Boschs 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

• Motivation
• MIDAS
• Architectural Middleware
• Experience
• Coping with Heterogeneity
• Managing Resource Consumption
• System Development Support
• 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

12
Prism-MW Extensibility Mechanism

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

13
Outline

• Motivation
• MIDAS
• Architectural Middleware
• Experience
• Coping with Heterogeneity
• Managing Resource Consumption
• System Development Support
• Conclusion

14
Requirements

• 11 key 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
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

16
Requirements

• 11 key 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
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

19
Heterogeneity of Computational Substrate

• Ported Prism-MW on top of MVM
• Extensive separation of concerns ? Prism-MW
  remained intact

20
Domain Specific Heterogeneity

• Domain specific heterogeneity is not abstracted
  away by a virtual machine layer
• An architectural middlewares extensibility and
  flexibility are essential to cope with these
  kinds of heterogeneity

21
Heterogeneity Support
22
Requirements

• 11 key 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
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

24
Requirements

• 11 key 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
25
Advanced Facilities
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 systems
  software architecture

27
Deployment, Analysis, and Adaptation
Architecture 2
Repository
DeSi Adapter Arch.
Architecture 1
DLL
DLL
DLL
Unicast Connector
Repository
Byte Array
Connector D
Repository
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

29
Outline

• Motivation
• MIDAS
• Architectural Middleware
• Experience
• Coping with Heterogeneity
• Managing Resource Consumption
• System Development Support
• 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-MWs 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 systems 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

35

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

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