1. Software Architectures and Embedded Systems Nenad Medvidovic with Sam Malek and Marija Mikic-Rakic Computer Science Department University of Southern California Los Angeles, CA 90089 {neno,malek,marija}@usc.edu

2. What Are Software Architectures?

3. Software Architecture Research An active research area –Architectural description and analysis –Architectural styles –Domain-specific architectures –Application family architectures –Architecture-based dynamic system adaptation Applied primarily in “traditional” SE domains –Few examples in the ES domain  What are architecturally-relevant issues in the ES domain?

4. SA4SE vs. SA4ES S/W architecture is all about abstraction –Hide implementation details as much as possible This is not always reasonable in the ES domain –Implementation and deployment issues may be critical Inspiration –Literature see accompanying paper –Graduate course Software Engineering for Embedded Systems http://sunset.usc.edu/~neno/cs589_2003/ –Research project Prism – “Programming in the Small and Many” http://sunset.usc.edu/~softarch/Prism/

5. Topics of Interest Architectural modeling Architectural analysis Architectural styles Reference architectures Implementation support Deployment support Dynamic adaptability  Probably many others…

6. Architectural Modeling Existing ADLs focus on (functional) S/W concerns –Interfaces –Behaviors (static and dynamic) –Interaction protocols S/W system resources typically ignored –OS, runtime libraries, threads, etc. H/W system resources typically ignored –Processor speed, memory, network, etc.  Is formal specification a must for ES? –Counter-example: JPL’s use of PPT, UML, xADL, Acme  Do we model SA4ES using components, connectors, and configurations?

7. Architectural Modeling – Examples MetaH –ADL for the GN&C domain –Considers schedulability, reliability, safety issues –Models availability and properties of S/W and H/W resources Weaves –Real-time processing of satellite data ROOM –Real-time computation –Message-sequence charts and state charts Relevant on-going effort –AADL

8. Architectural Analysis ADLs focus on formal analysis of (functional) system properties –E.g., Wright’s deadlock analysis –E.g., Mae’s static behavioral analysis Analysis fidelity –Considering H/W platform properties –Transferring architectural decisions into code –E.g., analysis of real-time properties Simulation –Executable architectural models –Faithful models of S/W and H/W environments –E.g., Darwin’s “what if” scenarios via Conic

9. Architectural Styles Styles are key S/W design idioms –Define rules (or heuristics) to guide system design –Guarantee (or promise) desired system properties –E.g., layered, pipe-and-filter, client-server, etc. What styles are applicable in the ES domain? –Weaves’ use of dataflow architectures –ADAGE’s use of layered architectures –Ptolemy’s definition of a “style” for hybrid systems –Some examples from mobile robotics and multimedia –Studies of styles in mobile, distributed, resource- constrained domains E.g., Prism-SF

10. Reference Architectures Generic architectural “blueprints” –Domain-specific or product-line approaches –Instantiated into application-specific architectures –Leverage successful architectural patterns Reference architectures in the ES domain –Phillips’ Koala – consumer electronics Adapts Darwin for architectural modeling –IBM’s ADAGE – avionics “Overlays” specific architectural patterns onto the layered style

11. Implementation Support Directly impacts effectiveness of architectural models –Lack of effective support worsens architectural drift Particularly so in the ES domain –Distributed, decentralized, mobile –Resource constrained, long-lived, heterogeneous Typically supported via PL extensions and M/W –E.g., PL extensions in ArchJava –E.g., M/W facilities in ACE/TAO, LIME, Ptolemy, XMiddle M/W solutions must be tailored to architectural abstractions –“Architectural” M/W –E.g., Ptolemy, Prism-MW

12. Deployment Support ES are typically developed and tested in simulated environments –Target platform may not yet exist –Target platform may be too expensive –Target platform may not be easily accessible Knowledge about the target environment is critical –Performance characteristics and idiosyncrasies –Current deployment architecture Existing deployment solutions are inappropriate –Centralized solutions –Large patches (e.g., Windows update wizards) –Sophisticated, but resource demanding deployment agents (e.g., SoftwareDock) E.g., Prism-DE

13. Deployment with Prism-DE

14. Dynamic Adaptability An ES may need to (continuously) evolve –Downtime of may be unacceptable Ensuring system integrity is critical –Design-time analysis of the modified models –Run-time analysis of the modified implementations Challenges in supporting dynamic adaptability –Dynamic adaptation may impact the ES’s properties Availability, safety, security –Distribution of systems and of dynamic changes –Decentralization Who “owns” (or can “see”) the entire system’s model? E.g., Prism-MW’s API (+ PL + OS + analysis)

15. Summary SA is primarily about abstraction ES is frequently about details What is SA4ES about? –Appropriate abstractions –Appropriate levels of detail –Appropriate analyses –Appropriate implementation- and run-time support