Christopher D. Gill cdgill@cse.wustl Department of Computer Science and Engineering

1. A Vision for Integration of Embedded System Properties Via a Model-Component-Aspect System Architecture Christopher D. Gill cdgill@cse.wustl.edu Department of Computer Science and Engineering Washington University St. Louis, MO, USA Research supported in part by the DARPA PCES program, under contracts F33615-00-C-3048 to Boeing, and F33615-03-C-4110 to Washington University

2. Motivation • Embedded systems concerns are increasingly • Complex • Inter-connected • Mission/safety critical • Multiplicity of concerns • Functional • E.g., algorithms, protocols • “Para-functional” (Rajkumar) • E.g., timeliness, security, fault-tolerance, footprint • Correctness • Depends on properties in both categories

3. Resource Access Domain Model s t Interaction Domain Model Concurrency Domain Model Deployment Domain Model Component Middleware High-Level Middleware Low-Level Middleware OS / Network Problem Statement • Concerns in different dimensions may interfere • E.g., real-time, fault-tolerance • Need to address all concerns systematically • Verify and enforce correctness • Solution must scale with complexity of system requirements • Automated development essential • Minimizing feature sets/interactions • Single techniques unlikely to work • Multiple useful decompositions • Several levels of abstraction • Issue for both tools and infrastructure • Can we apply multiple techniques, each to its best use?

4. Illustrative Example Component A facet s facet t • Application components expose interfaces (e.g., “facets” in CCM) • Components aggregate objects • Hide details of server implementation • While still offering infrastructure support • Components depend on infrastructure policies and mechanisms • E.g., ORB strategies, OS threads • A call from one component onto another crosscuts infrastructure • Two main decompositions • Object-oriented (components) • Aspect-oriented (invocation path) wait strategy 2 threads ORB 1 pending upcalls Component B facet u Component C facet w facet v wait strategy 1 thread ORB 2 pending upcalls

5. w u v y x s z t Example Continued 3 • Assume blocking two-way invocations for illustration • Different properties interfere in other cases (E.g., nesting) • A call into an ORB binds a thread (1,2,4,5,6) • A call within an ORB re-uses the caller’s thread (3) • Call return from an ORB unbinds a thread (4, 2) • Deadlock if a stable call chain pattern exhausts the threads in an ORB (1,5,6,7) 2 6 7 4 1 5

6. Resource Access Domain Model s t Interaction Domain Model Concurrency Domain Model Deployment Domain Model Component Middleware High-Level Middleware Low-Level Middleware OS / Network Position Statement • Multiple techniques must be applied together • Model Integrated Computing • Component Middleware • System Software Aspect Frameworks • Integration is essential • Synthesize multiple models • Project models into infrastructure “substrate” • Compose infrastructure • Weave infrastructure aspects • “Model-Component-Aspect” architecture • What parts already exist? • What are the open research questions? Synthesis Projection Composition & Weaving

7. Resource Access Domain Model s t Interaction Domain Model Concurrency Domain Model Deployment Domain Model Model Integrated Computing • Model driven toolsets • Target specific domains • E.g., Cadena (KSU) • QoS-aware CCM • E.g., VEST (UVA) • Infrastructure aspects • Automate infrastructure checking and configuration • Model engineering tools • Model model driven toolsets • E.g., Bogor (KSU) → Cadena • E.g., GME (Vanderbilt) → VEST • Tool interoperation, extension • Synthesis and projection from this level seems appropriate Synthesis

8. System Aspect Frameworks • Provide an additional decomposition • Assumes dominant object/layer/component decomposition • High-level frameworks • Focus on end-to-end and top-to-bottom integration • E.g., QuO (BBN), FCS-nORB (WUSTL) • Low-level frameworks • Focus on internal policy and mechanism integration • E.g., Kokyu (WUSTL), Event Correlation Automata (Stanford, KSU) • Aspects may crosscut high and low levels • “Aspect layering” might be strict, but more likely only partial Crosscutting System Aspects High-Level Middleware Contracts Low-Level Middleware queues OS / Network timers threads sockets

9. Component Middleware Component Middleware Composition Specification • A suitable architectural “meeting point” • Component packaging, assembly and deployment • Driven by specifications (e.g., from the modeling tools) • Supports both composition and weaving of infrastructure • Composition • Follows dominant decomposition • Components → applications → systems • Weaving • Customizes properties within or across composition steps Components Containers High-Level Middleware Weaving Specification Low-Level Middleware OS / Network

10. Open Research Problems • The big question: which tools for which sub-problems? • E.g., do we model “to the metal”? To higher-level abstractions? Both? • Need good metrics • Based in semantics of functional and para-functional correctness • Must compare quality of solutions and complexity/extensibility of techniques • Can distinguish alternatives, guide trade-offs and optimization • Need integrated theories of composition for (para-)functional properties • Polymorphism may be contextually determined (e.g., resource constraints) • Related question: what information can/should each encode? • Models have a wide range of possibilities (analogy to programming languages: from machine language to ML) • Subject to concerns about model complexity and extensibility • We can apply language techniques within infrastructure frameworks • E.g., exploiting/creating type systems, reflection • Need theories of co-design for infrastructure and modeling techniques • Can we define type-safety of infrastructure aspect composition, substitution? • Can target implementations help ↓ complexity and ↑ scalability of models?

11. Open Research Problems, Continued • Next question: how should we build such systems? • Again, automation of system development is essential • Need model synthesis tools, model interchange formats • Need flexible infrastructure substrates • Can be composed, synthesized, customized, pruned down • Need tools to project models into infrastructure substrates • Need tools to compose infrastructure, weave its aspects • Intuitively, model projection tools should employ weavers/composers • One local area of research in this much larger world • How can we apply multiple infrastructure decompositions? • E.g., object-oriented, generic, aspect-oriented infrastructure views • Does this help rationalize choices w/ competing concerns? • E.g., by reducing “accidental” complexity • E.g., by making trade-offs explicit, providing rigorous semantics?

12. Concluding Remarks • Embedded systems are increasingly complex, interconnected, and mission/safety critical • The open problems are important and challenging • Need an increased eye toward co-design and integration rather than one-size-fits-all approaches • Community question: how to avoid fragmentation? • Need forums and support geared toward collaboration • Bring together researchers in modeling, systems, languages, … • Need broad and deep research agendas in this area • Co-design & composition (theories & realization) demand attention