Dr. Douglas C. Schmidt dschmidt@darpa.mil DARPA/ITO

1. Adaptive and Reflective Middleware Systems Monday, November 3, 2014 Dr. Douglas C. Schmidt dschmidt@darpa.mil DARPA/ITO Approved for Public Release, Distribution Unlimited

2. Middleware, Frameworks, & Components • Distributed systems increasingly must reuse commercial-off-the-shelf (COTS) hardware & software • i.e., COTS is essential to R&D success High-performance, real-time, fault-tolerant, and secure systems Patterns & Pattern Languages Adaptive & reflective autonomous distributed embedded systems Power-aware ad hoc, mobile, distributed, & embedded systems Standards & Open-source Addressing the COTS “Crisis” • However, this trend presents many vexing R&D challenges for mission-critical DoD systems, e.g., • Inflexibility and lack of QoS • Confidence woes & global competition Why DARPA should care: • Despite IT commodization, progress in COTS hardware & software is often not applicable for mission-critical DoD distributed embedded systems • Recent advances in COTS software technology can help to fundamentally reshape distributed embedded system R&D

3. Historically, mission-critical apps were built directly atop hardware & OS The common middleware & domain-specific services layers are where many of the open R&D challenges reside Early COTS middleware lacked: • QoS specification & enforcement • Real-time features & optimizations • Layered resource management • Transparent power management The Evolution of COTS • This was extremely tedious, error-prone, & costly over system life-cycles • Standards-based COTS middleware helps: • Manage distributed resources • Leverage HW/SW technology advances • Evolve to new environments & requirements There are multiple COTS layers & multiple research opportunities Advanced R&D has address some, but by no means all, of these issues

4. Consequences of COTS & IT Commoditization • More emphasis on integration rather than programming • Increased technology convergence & standardization • Mass market economies of scale for technology & personnel • More disruptive technologies & global competition • Lower priced--but often lower quality--hardware & software components • The decline of internally funded R&D • Potential for complexity cap in next-generation complex systems Not all trends bode well for long-term competitiveness of traditional R&D leaders Ultimately, competitiveness will depend upon longer-term R&D efforts on complex distributed & embedded systems

5. The DARPA/ITO Embedded Systems Family of Programs • MoBIES • Design technology & software CAD • SEC • Hybrid, adaptive, control & computation • ARMS • Adaptive & reflective middleware • Quorum • Quality-of-service & translucent layers • PCES • Composable embedded systems • NEST • Deeply networked embedded systems • PCA • Polymorphous computing architecture

6. Example of DARPA ITO Impact:Real-time CORBA Specification Scheduling Service Thread Pools Standard Synchronizers Explicit Binding Portable Priorities Protocol Properties www.cs.wustl.edu/~schmidt/PDF/orc.pdf

7. Key Results • Test flown at China Lake NAWS by Boeing OSAT II ‘98, funded by OS-JTF • Drove Real-time CORBA standardization Limitations • Limited fault tolerance & security support • Used some non-standard COTS features • Static scheduling & validation • Small-scale network topology Example of ITO Impact:COTS in Real-time Avionics Goals Demo applicability of COTS & open systems for mission-critical RT avionics • Key System Characteristics • Deterministic & statistical deadlines • Periodic & aperiodic processing • Complex dependencies • Low latency & jitter • Continuous platform upgrades

8. Key Software Solution Characteristics • Affordable, flexible, & COTS • Embedded Linux (Lem) • Compact PCI bus + Celeron processors • Remote booted by DHCP/TFTP • Real-time CORBA Example of ITO Impact:Real-time Image Processing www.krones.com • Goals • Examine glass bottles for defects in real-time • System Characteristics • Process 20 bottles per sec • i.e., ~50 msec per bottle • Networked configuration • ~10 cameras

9. Key Software Solution Characteristics • Affordable, flexible, & COTS • Product-line architecture • Design guided by patterns & frameworks • Windows NT/2000 (+ VMS!) • Real-time CORBA Example of R&D Impact:Hot Rolling Mill Control Framework • Goals • Control the processing of molten steel moving through a hot rolling mill in real-time • System Characteristics • Hard real-time process automation requirements • i.e., 250 ms real-time cycles • System acquires values representing plant’s current state, tracks material flow, calculates new settings for the rolls & devices, & submits new settings back to plant www.siemens.de

10. WSOA Goals • Detect, identify, track, & destroy time-critical targets Challenges are also relevant to TBMD & NMD Key System Characteristics • Real-time mission-critical sensor-to-shooter needs • Highly dynamic QoS requirements & environmental conditions • Multi-service & asset coordination via Link 16 Key Solution Characteristics • Time-critical targets require immediate response because: • They pose a clear and present danger to friendly forces & • Are highly lucrative, fleeting targets of opportunity • High confidence • Safety critical • Affordable & flexible • COTS-based Example of ITO Impact:WSOA/QuoTE Time-Critical Target Prosecution

11. BSE IOM BSE BSE IOM IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM IOM IOM Key Software Solution Characteristics • High confidence & scalable computing architecture • Networked embedded processors • Distribution middleware • FT & load sharing • Distributed & layered resource management • Affordable, flexible, & COTS Example of ITO Impact:Large-scale Switching Systems • Goal • Switch ATM cells + IP packets at terabit rates • Key System Characteristics • Very high-speed WDM links • 102/103 line cards • Stringent requirements for availability • Multi-layer load balancing, e.g.: • Layer 3+4 • Layer 5 www.arl.wustl.edu

12. Very hard real-time deadlines (>= 100hz) • Very low latency (~10us) • Highly autonomous & re-configurable hybrid & embedded systems • Hard real-time deadlines (~40hz) • Low jitter & latency (~300us) • Broader scope • Hybrid scheduling & RT ARM • Heterogeneous middleware & languages • Large-scale (~5-250 miles) • Integrated QoS properties • Highly dynamic environments • Semi-autonomous & re-configurable distributed systems INTERNETWORKING ARCH VIRTUAL MACHINE ARCH MIDDLEWARE ARCH RTP TFTP FTP HTTP Java Ada C/C++ CORBA APPLICATIONS DNS TELNET Java Bytecode CORBA SERVICES UDP TCP Java VM Interpreter IP CORBA FIBRE CHANNEL PA/RISC PowerPC SOLARIS VXWORKS Ix86 TI DSP 68K ETHERNET ATM FDDI WINNT LINUX LYNXOS Network What Are We Trying to Do? Advance the state-of-the-art in adaptive & reflective middleware to coordinate multiple QoS properties of mission-critical distributed embedded & hybrid systems • Why the “waist” works: • Decouples hardware from software so they can evolve separately • Decouples low-level capabilities from higher-level capabilities to enhance innovation • Decouples fast changing layers from slower changing layers • However, the waist can also restrict choices… Research Goals • Address fundamental QoS properties of distributed embedded & hybrid systems • Devise middleware-centric methods & tools to develop, optimize, &manage systems with multiple QoS properties • Enhance confidence of open-source R&D processes and V&V techniques

13. Radar Control Program Sizing Estimates Estimated data, based on 6 Ph3 & 7 Ph1 design & projections of Block I & Block II NTW requirements TBMD Phases: Required Compute Power AREA 6 Ph 3 AREA 7 Ph 1 NTW BLK 1A NTW BLK 1B NTW BLK 1C NTW BLK 2 SMP Load Scale Limits Required Processing Key Solution Characteristics • Highly dependable & scalable computing architecture • High-speed networked clusters of multi-processor computers • Distribution middleware • Fault tolerance & load sharing • Distributed & layered global resource management • Affordable, flexible, & COTS TBMD Phases New Challenges:Theater Ballistic Missile Defense • Goal • Detect, identify, track, & destroy multiple theater ballistic missiles Key Research Challenges • Meeting hard real-time sensor-to-shooter needs in highly dynamic environment • Providing load-invariant performance • Supporting QoS for distributed weapons coordination

14. Example:Real-time Retargeting of UAVs • Goal • Reconfigure & retarget unmanned air vehicles (UAVs) in real-time • Key System Characteristics • Autonomous behavior • e.g., battlespace loitering of UAVs • Coordinated strikes • e.g., C4ISR integration & UAV swarming for SEAD missions Key Research Challenges • Real-time sensor-to-shooter QoS scheduling of sea/land/air assets • Developing efficient, predictable, & safe adaptive HW/SW systems for autonomous UAV processing • Secure integration to C4ISR infosphere • e.g., proof-carrying code & automated policy-based control • Transition to COTS HW/SW to control costs & leverage technology advances

15. Key Solution Characteristics • Integrate multiple QoS properties simultaneously • e.g., dependability, security, & bandwidth management • Tele-immersion situation monitoring • e.g., QoS-based event fusion • Adaptive & reflective peer-to-peer information system coordination • e.g., power-aware systems • COTS-based to control costs & to leverage rapid technology advances • e.g., wireless tracking & local info New Challenge:Situational Awareness Systems • Goal • Support dispersed & rapidly deployable teams • Key System Characteristics • Mission-critical, sensor-rich • Multi-asset coordination • e.g., UAVs, MEMs, SUOs • Ad hoc wireless/mobile infrastructure • Highly non-linear and dynamic • Non-uniform resource constraints

16. Key Solution Characteristics • Integrate multiple QoS properties simultaneously • e.g., dependability, security, & bandwidth management • Tele-immersion situation monitoring • e.g., QoS-based event fusion • Adaptive & reflective peer-to-peer information system coordination • e.g., power-aware systems • COTS-based to control costs & to leverage rapid technology advances • e.g., wireless tracking & local info Example:Coordinated Disaster Response • Goal • Support rapidly deployable & dis-persed emergency response teams • Key System Characteristics • Mission-critical & time-critical systems • Multi-agency coordination • e.g., police, fire, FBI, medical • Ad hoc wireless/mobile infrastructure • Highly non-linear and dynamic • Non-uniform resource constraints

17. Technology Enablersand Business Drivers

18. Problem Abstraction • Distributed Environment • Heterogeneous hardware/software • Mixed COTS & non-COTS components • Mixed RT and non-RT requirements • Wireline & wireless interconnects • Adaptivity & Reflection Targets • Dynamic component distribution & reconfiguration • Changing interconnection topology • Changing power-levels, CPU/network bandwidth, latency, security, & dependability requirements

19. The Hard Problems • Decoupling functional aspects from QoS aspects • Automatically generating & optimizing multiple QoS properties adaptively & reflectively • Articulating pattern languages & reifying them into QoS-enabled frameworks & components • Leveraging, customizing, enhancing, & validating open-source COTS components

20. Intel x86 & Power PC chipsets • TCP/IP, ATM • POSIX & JVMs • CORBA ORBs & components • Ada, C, C++, RT Java Conventional COTS Limitations Many hardware & software APIs and protocols are now standardized, e.g.: • While COTS standards promote reuse, they limit design choices, e.g.: • Networking protocols • Concurrency & scheduling • Caching • Fault tolerance • Security • Historically, COTS tightly couples functional & QoS aspects • e.g., due to lack of “hooks” Inflexible COTS negatively affects researchers & developers

21. CONTRACT CONTRACT DELEGATE DELEGATE SYS COND SYS COND SYS COND SYS COND MECHANISM/PROPERTY MANAGER LOCAL RESOURCE MANAGERS LOCAL RESOURCE MANAGERS Promising New Solution:Adaptive & Reflective Middleware • Adaptive & reflectivemiddleware is middleware whose functional or QoS-related properties can be modified either • Statically, e.g., to better allocate resources that can optimized a priori or • Dynamically, e.g., in response to changes in environment conditions or requirements Research Challenges • Preserve critical set of application QoS properties end-to-end • e.g., efficiency, predictability, scalability, dependability, & security • Achieve load invariant performance & system stability • Maximize longevity in wireless & mobile environments • e.g., control power-aware hardware via power-aware middleware • Automatically generate & integrate multiple QoS properties

22. The Hard Problems • Decoupling functional aspects from QoS aspects • Automatically generating & optimizing multiple QoS properties adaptively & reflectively • Articulating pattern languages & reifying them into QoS-enabled frameworks & components • Leveraging, customizing, enhancing, & validating open-source COTS components

23. Key Themes of WSOA • Real-time mission replanning & collaboration • e.g., C2 node & F-15 share data imagery & annotations • Shows adaptive QoS behavior is feasible within demanding real-world constraints • Showcase academic & industry synergy Network State-of-the-Art in QoS Demos • Limitations • “Stove-pipe” architectures • Only “opportunistic” integration • Lack of multi-property QoS • integration • Not fully autonomous DARPA, AFRL, & Boeing test flight in ‘01

24. Promising New Solution:Middleware Frameworks for Integrating Multiple QoS Properties • Key Themes • Handle variation translucently • QoS aspect languages • Smart proxies & interceptors • Pluggable protocols & adapters • Middleware gateways/bridges • Ideally, implementations should be generated from higher-level specifications • Research Challenges • Model, compose, analyze, & optimize QoS framework component properties • Leverage configurable & adaptive hardware capabilities • e.g., power management, high-speed QoS-enabled bus & network interconnects

25. C++ Program Ada Program C++ Compiler Ada Compiler Internal Rep. Internal Rep. Ix86 Opt. PPC Opt. 68K Opt. Ix86 Opt. PPC Opt. 68K Opt. Ix86 Opt. PPC Opt. 68K Opt. Ix86 PPC 68K Ix86 PPC 68K Ix86 PPC 68K Applying Reflection as an Optimization Technique To illustrate the benefits of reflection as an optimization technique, consider the evolution of compiler technology: C Program • Early compilers required • Separate internal representations hand-written for each programming language and C Compiler • Separate hand-written optimizers for each target backend Internal Rep. • Developing, verifying, validating, & evolving all these components separately is costly, time-consuming, tedious, & error-prone • The problem only gets worse as more languages & target backends emerge

26. 3. Generate an optimizer that is customized for the particular platform/language 2. Use discrimination network to analyze the optimization rules & opportunities Optimizer Generator Ix86 PPC 68K 1. Read the target machine description Ix86 .md PPC .md 68K .md Applying Reflection as an Optimization Technique • Modern compilers, such as GNU GCC, support • A common internal representation (still hand-written) for each programming language • Based on generalizing the language semantics C/C++/Ada Programs C/C++/Ada Compiler • A generated optimizer that is customized automatically for each target backend • Based on reflective assessment of algebraic target machine description Common Internal Rep. Ix86 Opt. PPC Opt. 68K Opt. • Key Benefit of “Static” Reflection • New targets can be supported by writing a new machine description, rather than writing a new code generator/optimizer

27. Solaris Impl WinNT Impl VxWorks Impl WinNT Solaris VxWorks Java Application COM+ Application Java RMI & Assorted Tools COM+ ORB & Assorted Tools Solaris Impl WinNT Impl Win98 Impl WinNT Impl Linux Impl WinCE Impl WinNT Solaris WinNT Win98 Linux WinCE Applying Reflection to Optimize Middleware Statically Conventional middleware for embedded systems is developed & optimized in a manner similar to early compiler technologies: • Conventional middleware require • Separate tools and interfaces hand-written for each ORB middleware specification • e.g., CORBA, Java RMI, COM+ CORBA Application CORBA ORB & Assorted Tools • Separate hand-written & hand-optimized implementations for each embedded target platform • e.g., various OS/network/HW configurations • Developing, verifying, validating, & evolving all these components separately is costly, time-consuming, tedious, & error-prone • Moreover, it is even harder to hand-configure support for dynamic platform variations & complex application use-cases • The problem only gets worse as more middleware, target platforms, & complex applications emerge

28. Application Requirements 3. Generate middleware that is customized for a particular platform & application use-case 2. Use discrimination network to analyze the optimization rules & opportunities Middleware Generator Plat1 Plat2 Plat3 Plat1 .pd Plat2 .pd Plat3 .pd 1. Read the target platform description & application requirements Applying Reflection to Optimize Middleware Statically • The functional and QoS-related aspects of middleware can be improved greatly by advanced R&D on the following topics: • A common internal representation (ideally auto-generated) for each middleware specification • Based on generalizing the middleware semantics CORBA/Java/COM+ Applications Common ORB + Assorted Tools • A generated implementation that is optimized automatically for each target platform & application use-case • Based on reflective assessment of platform descriptions & application use-case Common Semantic Representation Plat1 Impl Plat2 Impl Plat3 Impl

29. Client Object QuO Contracts Measured QoS Expected QoS Delegate Delegate Probes Probes Resource Status Service Correlate Probes Infer/Adapt Integrate Feedback Loop Piggybacked Measurements Translate Status ORB endsystem ORB endsystem Probes Probes Resource Resource Resource Applying Reflection to Optimize Middleware Dynamically Applying reflection as an optimization is even more relevant to middleware than compilers due to dynamism & global resources: • Key System Characteristics • Integrate observing & predicting of current status & delivered QoS to inform the meta-layer • Meta-layer applies reflection to adapt system policies & mechanisms to enhance delivered QoS Collect

30. Combined System-level & Application-level Management Feedback Client Object End-to-End Application-centric Feedback End-to-End Application-centric Feedback Local Resource- centric Feedback Local Resource- centric Feedback Key Research Challenge:Providing QoS Guarantees for Multiple Adaptive Feedback Loops • Goals • Ensuring stable QoS support at varying granularity & scope levels for integrated, multi-property feedback paths across different locations & time scales • Determining patterns, protocols, and architectures necessary to integrate COTS components

31. The Hard Problems • Decoupling functional aspects from QoS aspects • Automatically generating & optimizing multiple QoS properties adaptively & reflectively • Articulating pattern languages & reifying them into QoS-enabled frameworks & components • Leveraging, customizing, enhancing, & validating open-source COTS components

32. New Idea:Pattern Languages for QoS Key Theme Patterns & pattern languages codify expert knowledge to help generate software architectures by capturing recurring structures & dynamics and resolving common design forces Research Challenges • Identifying QoS pattern languages • Broaden the focus of conventional pattern-related tools and pattern languages, which focus on simple structural & functional behavior • Model QoS-enabled middleware via pattern languages • Must understand how to build high-confidence systems before we can automate V&V • Formal semantics • Articulate QoS properties of core architectures • Automation • i.e., auto-generate portions of frameworks & components from pattern languages

33. The Hard Problems • Decoupling functional aspects from QoS aspects • Automatically generating & optimizing multiple QoS properties adaptively & reflectively • Articulating pattern languages & reifying them into QoS-enabled frameworks & components • Leveraging, customizing, enhancing, & validating open-source COTS components

34. Cisco Culture No technology religion Empowerment Frugality Market Transitions Stretch Goals Trust/Fair/ Integity Open Communication Quality team Teamwork Drive Change • “Everything gets cheaper forever” • John Chambers, CEO Cisco Systems Key COTS R&D Challenges • Why COTS? • Commercial & military suppliers are increasingly driven by competitive forces • e.g., time-to-market/mission pressures & heavy competition for engineering talent • COTS can contribute systematic reuse, continuous innovation, & cost reduction via 3rd party life-cycle management • COTS can potentially reduce V&V costs • Lack of realistic alternatives… Key Technology Inhibitors to Success • Integration woes • COTS components are often not designed for composition • V&V and security woes • COTS components rarely designed for certification or high assurance • Inefficient feedback loops • e.g., “binary-only,” closed-source deployment hampers usability • COTS is not always standard • Non-standard COTS can greatly increase “refresh” costs

35. Open-source is a highly scalable and cost effective software process based on the following observations: • Validation scales, development does not • “End-to-end argument” applies to software • i.e., more resources at the “edges” Emerging trend in commodity IT market:Standard Open-source COTS • Benefits for Developers • Standards help to ensure longer-term viability of technology investments • Standard COTS helps control life-cycle costs • Standard open-source COTS helps to focus expertise, e.g.: • Leverage “everyone’s a beta-tester” syndrome • Resolves “COTS vs. ownership” conundrum in system acquisition • Benefits of Open-source for Researchers: • Leverage existing technology base for rapid prototyping of new technologies • Promote broad visibility of novel R&D activities • Accelerate the pace & impact of technology transfer • Lead, rather than follow, COTS software trends

36. Bold Stroke Open-source standard COTS is now mainstream at certain layers Flight critical software Next-generation middleware Formal Spec Linux, Apache, GNU tools, & TAO Solaris & Windows NT Informal Spec COTS desktop productivity tools EMACS, ACE, & USENET servers No Spec Closed-source Open-source New opportunity:High Confidence Open-source Software Systems • Key Themes • We know how to build open-source software quickly and cheaply • Quality and security remain key challenges, however… • Open-source enables whitebox V&V techniques • e.g., analysis methods can extend across layers & thru components • Reuse of middleware components can help amortize V&V efforts • No need to (re)start from scratch • Middleware is often written in relatively “civilized” languages • cf. operating system kernels • Middleware defines natural module boundaries for specification & testing • e.g., define QoS properties via QDLs

37. Concluding Remarks • Researchers & developers of distributed systems face common challenges, e.g.: • Summary of Research Themes in the ARMS Program • Decouple functional aspects & QoS aspects • Specify & apply component QoS as meta-data • Devise adaptive & reflective methods,optimizations, & tools that can provide scalable, multi-property QoS guarantees end-to-end • Enable high-confidence autonomous system capabilites • Leverage standard COTS APIs • But not necessarily COTS implementations or protocols • Connection management, service initialization, error handling, flow control, event demuxing, distribution, concurrency control, fault tolerance synchronization, scheduling, & persistence • The application of formal methods along with adaptive & reflective patterns, frameworks, & components can help to resolve these challenges • Carefully applying these techniques can yield efficient, scalable, predictable, & flexible middleware & applications