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?
Cl ock :
Cl ock
8: request
Cl ockConn
9: notification
Warehouse
10: notification
Del iveryPort
Vehicle
7: request
4: request
1: request
3: request
RouterConn
2: notification
CargoRouter
5: request
GraphicsConn
6: notification
GraphicsBinding :
GraphicsBinding
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 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, 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, 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 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