Software Architectures and Embedded Systems

1. Software ArchitecturesandEmbedded 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. Events Connectors Components 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’sAPI (+ 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