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_at_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 JPLs use of PPT, UML, xADL,
  Acme
• Do we model SA4ES using components, connectors,
  and configurations?

7
Architectural Modeling Examples

• MetaH
• ADL for the GNC 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., Wrights deadlock analysis
• E.g., Maes 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., Darwins 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
• ADAGEs use of layered architectures
• Ptolemys 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
• IBMs 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 ESs properties
• Availability, safety, security
• Distribution of systems and of dynamic changes
• Decentralization
• Who owns (or can see) the entire systems
  model?
• E.g., Prism-MWs 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