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 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 • 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 • 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 • Requirements for MIDAS: 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 • 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 • 11 key requirements for MIDAS: 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 • 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 • 11 key requirements for MIDAS: 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. Requirements • 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 • 11 key requirements for MIDAS: 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 • 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 • 11 key requirements for MIDAS: 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 Comp B Admin Comp A Comp A Monitor Effector Admin Comp C SD Engine SD Engine 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-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