1. International Conference on Software Engineering 2007
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
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 Motivation MIDAS Architectural Middleware Experience
Coping with Heterogeneity
Managing Resource Consumption
System Development Support
Conclusion

8. MIDAS Bosch’s family of sensor network applications Sensors Gateways
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. Software architecture support
Requirements
Requirements for MIDAS:
Heterogeneity
Performance
Scalability
Manage Resource Consumption
Fault-Tolerance
System Modeling and Analysis
Component-Based Deployment
Service Discovery
Monitoring System and Software Properties
Architecture-Based Development
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. Software architecture support
Requirements
11 key requirements for MIDAS:
Heterogeneity
Performance
Scalability
Manage Resource Consumption
Fault-Tolerance
System Modeling and Analysis
Component-Based Deployment
Service Discovery
Monitoring System and Software Properties
Architecture-Based Development
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. Software architecture support
Requirements
11 key requirements for MIDAS:
Heterogeneity
Performance
Scalability
Manage Resource Consumption
Fault-Tolerance
System Modeling and Analysis
Component-Based Deployment
Service Discovery
Monitoring System and Software Properties
Architecture-Based Development
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 middleware’s extensibility and flexibility are essential to cope with these kinds of heterogeneity

21. Heterogeneity Support

22. Software architecture support
Requirements
11 key requirements for MIDAS:
Heterogeneity
Performance
Scalability
Manage Resource Consumption
Fault-Tolerance
System Modeling and Analysis
Component-Based Deployment
Service Discovery
Monitoring System and Software Properties
Architecture-Based Development
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. Software architecture support
Requirements
11 key requirements for MIDAS:
Heterogeneity
Performance
Scalability
Manage Resource Consumption
Fault-Tolerance
System Modeling and Analysis
Component-Based Deployment
Service Discovery
Monitoring System and Software Properties
Architecture-Based Development
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 system’s software architecture

27. Deployment, Analysis, and Adaptation
Architecture 2
SD Engine
Comp A
Comp B
Repository
Admin
DeSi Adapter Arch.
Architecture 1
Comp A
Monitor
DLL
DLL
DLL
Unicast Connector
Repository
Effector
Byte
Array
Connector D
Admin
Comp C
SD Engine
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-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

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