MIC for the layman

1
NEPHEST Overviewfor the OMG
Nov. 21, 2002 Joe Cross
2
NEPHEST Program Structure
NEPHEST National Experimental Platform for
Hybrid and Embedded Systems
DARPA
NSF
Lockheed Martin
Lockheed Martin
BBN
Boeing
UC Irvine
UC Berkeley
U Md
Vanderbilt
U Penn
Wash U _at_ STL
3
NSF and DARPAGoals Constraints
4
A Common Thread

• Computing is inherently mathematical
• Embedded systems connect computation to physics
• The real world is inherently physical

5
How do we construct an embedded system?

• Hardware
• Well-established design methods and automation
• A century of experience
• Getting cheaper, faster, better
• Software
• No single, best approach
• Hand-woven, complex
• Physics is unknown
• Getting more expensive, slower, buggier

6
Model-based Development (MBD) in Traditional
Engineering

• Traditional engineering
• Create a MODEL of the system before you build
• Test and analyze the model
• Build the product!

Build
Analyze
7
Model-based Development in Embedded Systems

• Build a model of the embedded system
  hardware,software and its environment
• Analyze the models
• Generate the software

Analysis
Generation
8
Requirements Differences in MBD
9
Why MBD for Embedded Software is Hard

• We need embedded-domain-specific PIM-to-PSM
  transformations client-server to Real-time
  CORBA, message stream to Link 16 radio, .
• Proprietary lock-in not acceptable plan for the
  system to live 25 years
• There are no standard vocabularies for qualities
  of services latency, reliability, security,
  fault tolerance,
• There are no standard vocabularies for workloads
  communications, computation (single thread), CPU
  consumption (multiple threads), power
  consumption, memory consumption,
• Some code (e.g, Fourier transform) must be
  hand-written. How much is some?

10
Why the PIM/PSM Dichotomyin Embedded Systemsis
Ideal

• The platform independent semantics of a system
  may persist for 25 years.
• The mean time between platform modifications may
  be 1 or 2 years. (The frequency of modification
  is exacerbated by use of commercial off the shelf
  components.)
• We the People pay dearly for software
  modifications required to coordinate with
  hardware modifications.
• One PIM and many PSMs is the ideal abstraction.
• Serious money may be saved by automated
  PIM-to-PSM transformation. Prime Vendor Support
  contracts have our attention.

If you change the display, Ill have to re-code
80 of my application. -- a DoD contractor system
engineer
11
Why the PIM/PSM Dichotomyin Embedded Systemsis
Problematical

• Some properties of an embedded applications
  platform are essential they cannot be usefully
  abstracted away.
• Hence a literally platform independent model
  would not be useful.

Resolution Define platform asinessential
implementation details Words mean what I want
them to mean. -- H. Dumpty
space shuttle arm

• The uses of the PSM simulation verification
  and system generation are largely best
  performed within support tools
• Hence there is small benefit in exposing the PSM
  to humans.

model launch vehicle fairingwith vibration
sensors and dampers
12
Model-based DevelopmentResearch Issues

• Modeling Languages
• Formal semantics
• Textual/Visual syntax
• Model Analysis
• How to check
• when timing is critical
• when correctness is critical
• Model transformations
• How to generategood code?

?
13
An Example MBD Problem

• Given a PIM that specifies
• 1-to-many messaging
• 10 ms max latency
• A platform that provides
• CORBA Event Service and
• Sockets, and
• The PIM-to-CORBA-PSM transformation should
  determine
• Whether the latency requirement will be met
• Where to create required objects
• Event Service
• Proxies,
• When to create and destroy them
• How to configure the ORB