Software Architecturesand

Embedded Systems

Nenad Medvidovicwith 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?

VehicleDel iveryPort

CargoRouter

RouterConn

GraphicsBinding : GraphicsBinding

GraphicsConn

Warehouse

ClockConn

Clock : Clock

10: notification9: notification

5: request

3: request4: request

2: notification

1: request

7: request

6: notification

8: request

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?

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/

Topics of Interest

• Architectural modeling• Architectural analysis• Architectural styles • Reference architectures• Implementation support• Deployment support• Dynamic adaptabilityProbably 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, xADL, Acme

Do we model SA4ES using components, connectors, and configurations?

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

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, resource-

constrained 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 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

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

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 SA4ES about?– Appropriate abstractions– Appropriate levels of detail– Appropriate analyses– Appropriate implementation- and run-time

support