Adaptive

1
Adaptive Reflective Middleware for
Distributed Real-time Embedded Systems
Dr. Douglas C. Schmidt schmidt_at_uci.edu
Electrical Computing Engineering Department The
Henry Samueli School of Engineering University of
California, Irvine
Thursday, October 15, 2015
2
Accomplishments New Directions

• Productivity quality gains from higher-level
  abstraction mechanisms

3
Current Challenges Limitations

• Emerging Trends
• DRE system requirements are increasingly more
• Dynamic
• Diverse
• Demanding

1000 1,000,000 node fusion of physical
informationsystems
4
Current Challenges Limitations

• Cultural Problems
• Existing research approaches do not scale to
  address key technology problems
• Non-appreciation of the importance of DRE software

• Emerging Trends
• DRE system requirements are increasingly more
• Dynamic
• Diverse
• Demanding

5
Why We (Now) Care about DRE Systems
Proliferating conventional, WMD, asymmetric
threats
Power grids, national infrastructure networks,
supply-chains, air transportation, military
systems are particularly vulnerable
6
RD Challenge Develop DRE Systems Technologies
to Protect Critical Infrastructure
The soft underbelly of commercial, military,
infrastructure DRE systems depend increasingly on
information technology, making attacks both
attractive lethally effective
Planet-top systems
Information Appliances
Clusters

• RD Challenges Create
• efficient,
• scalable,
• reliable,
• secure,
• predictable
• DRE system technologies from nano- to tera-scale

MEMS BioMonitoring
7
Lessons from IT History

• Extrapolating this trend to 2010 yields
• 100 Gigahertz desktops
• 100 Gigabits/sec LANs
• 100 Megabits/sec wireless
• 10 Terabits/sec Internet backbone

DRE software has not improved as rapidly or as
effectively as hardware networks
8
The Road Ahead for DRE Systems

• We need to create the new generation of open DRE
  system middleware technologies to
• Simultaneously control multiple QoS properties
• Improve software development quality,
  productivity, assurability

9
The Evolution of Open DRE System Technologies

• Tedious, error-prone, costly over lifecycles

• Open DRE system middleware helps
• Manage end-to-end resources QoS
• Leverage HW/SW technology advances
• Evolve to new environments requirements

The domain-specific common middleware services
layers are where researchers developers need to
have the most impact
Existing RD efforts have addressed some, but by
no means all, these challenges
10
Technical Challenge Real-time Control of
Distributed Resources
Goal Create new generation of middleware to
simultaneously control multiple QoS properties
Distributed security
Distributed fault tolerance

• Distributed
• resource
• management
• Allocation/reservations, caching, scheduling,
  monitoring, load balancing

Control Vars.
Workload Replicas
Workload Replicas
Workload Replicas

Local middleware
Connections priority bands
Connections priority bands
Connections priority bands
CPU memory
CPU memory
CPU memory
Ship-wide QoS Doctrine Readiness Display
Network latency bandwidth
Network latency bandwidth
Network latency bandwidth
11
Hard Problem 1Secure Multi-level Distributed
Resource Management

• Problem
• Multiple technology bases make it hard to analyze
  control the QoS of distributed resources at
  multiple system levels dynamically, dependably,
  securely

TBMD Application
Requested QoS
AAW Application
Control Algorithm
Control Algorithm
Control Algorithm
Control Algorithm
Control Algorithm
Control Algorithm
Measured QoS
Load Balancer FT CORBA
Workload Replicas
Connections priority bands
RT/DP CORBA DRTSJ

• Research Challenge
• Devise middleware to formally specify
  QoS-constrained global resource management plans
  model, reason about and refine them
  monitor/enforce these plans automatically at
  run-time

RTOS RT Java
CPU memory
IntServ Diffserv
Network latency bandwidth

• Solution Approach
• Doctrine-driven middleware to support multi-level
  management of DRE resources
• i.e., dynamic, dependable, scalable resource
  analysis, scheduling, allocation, monitoring
  balancing
• Guided by online reflective QoS models
  empirical evaluation

12
Example Data Parallel CORBA
Parallel Object
Computing Grid
Client on parallel ORB

• Airborne HPEC
• Distributed shipboard clusters
• CONUS supercomputers

Part 1
Part 2
Data reorganization strategies
Part 3

• Data Parallel CORBA bridges the gap between
  traditional CORBA applications high-performance
  embedded parallel processing applications as
  follows
• Enable CORBA applications over clusters of
  computers
• No change required in software technologies,
  methodologies, or tools
• Enable massively parallel applications to
  integrate easily with distributed systems
• Allow parallel applications to benefit from
  distributed object methodologies, technologies,
  tools
• Add parallelism data distribution to the
  transparencies offered by CORBA
• Enable a new class of applications e.g.,
  financial, industrial, medical, aerospace,
  multimedia, and military domains

13
Hard Problem 2Meta-programmable DRE Middleware
Frameworks

• Problem
• Existing DRE systems are rigidly designed with
  fixed QoS parameters that limit their utility for
  new operations

• Research Challenges
• Assuring dynamic flexibility and QoS
  simultaneously

• Solution Approach
• Meta-programming techniques that
• Decouple functional QoS paths to allow more
  degrees of freedom
• Specify QoS doctrine declaratively
• Support dynamic QoS adaptation optimizations

Applications
Applications
Interceptor
Interceptor
Sys Cond
Sys Cond
Sys Cond
Sys Cond
Mechanism Property Managers


Workload Replicas
Workload Replicas
Connections priority bands
Connections priority bands
Local Resource Managers
Local Resource Managers
QoS Contract
QoS Contract
CPU memory
CPU memory
Network latency bandwidth
Network latency bandwidth
Endsystem
Endsystem
14
Example Meta-programmed Distributed QoS Aspects

• Fidelity
• Highest fidelity frames must be delivered

• Importance
• Frames must be dropped in reverse order of
  importance

• Timeliness
• Maintain an out-of-the-window view of imagery

Mission Requirements
www.dist-systems.bbn.com/tech
www.cs.wustl.edu/schmidt
15
Hard Problem 3DRE Middleware Generation
Optimization Tools

• Problems
• COTS middleware is often unsuited for DRE systems
  due to insufficient
• QoS specification enforcement
• Time/space optimizations
• Flexibility customizability

• However, conventional DRE development techniques
  are
• Tedious
• Proprietary
• Manual ad hoc

Workload Replicas
Workload Replicas
Connections priority bands
Connections priority bands
CPU memory
CPU memory
Network latency bandwidth
Network latency bandwidth
tSTART
t2
t4
t5
t6
t7
t9
t10
t12
t13
t14
t15
t16
t18
t19
tREQD
t3
t8
t17
t11

• Research Challenge
• Minimizing footprint customizing standard DRE
  middleware capabilities without sacrificing key
  QoS properties

DRE Applications
Optimized verified DRE middleware
Common Middleware Tools
Common Semantic Rep.
Application Requirements

• Solution Approach
• Develop Model Driven Architecture (MDA) tools to
  reflectively auto-generate, optimize, verify
  custom implementations of standard DRE middleware
  from higher-level specifications

Impl1
Impl2
Impl1
Middleware Generator
Plat2
Plat3
Plat1
Plat2.pd
Plat3.pd
Plat1.pd
16
ExampleApplying Reflection as Compiler
Optimization
To illustrate the benefits of reflection as an
optimization technique, consider the evolution of
compiler technology

• Early compilers required
• Separate internal representations hand-written
  for each programming language

C Program
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

17
ExampleApplying Reflection as Compiler
Optimization
To illustrate the benefits of reflection as an
optimization technique, consider the evolution of
compiler technology
C Program
Ada Program
C Program

• Early compilers required
• Separate internal representations hand-written
  for each programming language and

C Compiler
Ada Compiler
C Compiler

• Separate hand-written optimizers for each target
  backend

Internal Rep.
Internal Rep.
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

PPC Opt.
MIPS Opt.
88K Opt.
1751 Opt.
32K Opt.
HPPA Opt.
PPC
MIPS
88K
1751
32K
HPPA
18
ExampleApplying Reflection as Compiler
Optimization

• 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 synthesized compiler 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 Reflective Optimization
• New targets can be supported by writing a new
  machine description, rather than writing a new
  code generator/optimizer

19
New ApproachApplying Reflection to Optimize DRE
Middleware
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

20
New ApproachApplying Reflection to Optimize DRE
Middleware
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

21
New ApproachApplying Reflection to Optimize DRE
Middleware

• The functional and QoS-related properties of
  embedded systems middleware can be improved
  greatly by advanced RD 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 synthesized middleware 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
22
DARPA DRE Software RD Focus