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