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. 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? Deployment Domain Model Interaction Domain Model Resource Access Domain Model t s Concurrency Domain Model Component Middleware OS / Network Low-Level Middleware High-Level Middleware

4. Illustrative Example 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) 1 thread pending upcalls ORB 2 wait strategy Component B Component Cfacet u facet v facet w 2 threads pending upcalls ORB 1 wait strategy Component A facet s facet t

5. Example Continued 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) z y x t s uv w 2 1 3 7 6 4 5

6. 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? Deployment Domain Model Interaction Domain Model Resource Access Domain Model t s Concurrency Domain Model Component Middleware OS / Network Low-Level Middleware High-Level Middleware Synthesis Composition & Weaving Projection

7. 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 Deployment Domain Model Interaction Domain Model Resource Access Domain Model t s Concurrency Domain Model 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 Contracts threadstimers queues sockets OS / Network Low-Level Middleware High-Level Middleware Crosscutting System Aspects

9. Component Middleware 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 OS / Network Low-Level Middleware High-Level Middleware Component Middleware ContainersComponents Composition Specification Weaving Specification

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