Software Architectures and Embedded Systems Nenad Medvidovic with

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

What Are Software Architectures?

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?

SA 4 SE vs. SA 4 ES • 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/cs 589_2003/ – Research project • Prism – “Programming in the Small and Many” • http: //sunset. usc. edu/~softarch/Prism/

Topics of Interest • Architectural modeling • Architectural analysis • Architectural styles • Reference architectures • Implementation support • Deployment support • Dynamic adaptability Ø Probably many others…

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, x. ADL, Acme Ø Do we model SA 4 ES using components, connectors, and configurations?

Architectural Modeling – Examples • Meta. H – 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

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

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, resourceconstrained domains • E. g. , Prism-SF

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

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 Arch. Java – 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

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. , Software. Dock) • E. g. , Prism-DE

Deployment with Prism-DE

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)

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