Overview

As networking technology has become faster and cheaper in recent years, traditional stand-alone applications are evolving into distributed ones. This trend is occurring not only in large corporate computing centers but, increasingly, is reaching down into the embedded systems market as well. The number of devices manufactured across this spectrum is staggering, at 11 billion parts per year. The embedded systems marketplace includes a wide range of devices from small kitchen appliances to jumbo-jets and ocean-going vessels.

Middleware, such as CORBA, has proven to be a valuable tool in dealing with the many facets of distributed systems. CORBA provides an excellent object-oriented and platform-neutral middleware architecture for developing distributed applications. It provides elegant separation of the interface and implementation, along with its encapsulation of communication protocols and processing environments, and a rich set of services and industry-specific APIs. This allows not only for language independence and a high-level programming building block, but can also mask heterogeneity and allow for many different implementation configurations and optimizations that can be employed transparently to the client.

Current middleware tools are being applied to small, embedded systems with varying degrees of success. Many high-end workstations have more onboard CPU cache than some embedded systems have available memory in both RAM and ROM. Needless to say, tools developed in these memory rich environments often fail to scale down to memory starved environments. Other solutions have been developed for small, embedded devices, but typically they are point solutions that do not have the flexibility to widely cover the embedded systems market, or to provide the particular embedded application designer with the right set of constraints appropriate for its specific application functionality and target hardware.

We have designed and implemented an initial prototype of MicroQoSCORBA, a middleware framework that can scale down to memory-starved environments. In doing so, we are allowing the middleware to be tailored both to the precise properties of the hardware as well as to the application’s configuration requirements. Additionally, limited memory is only one of the many facets of small, embedded devices. We have thus architected it to address other facets of MicroQoSCORBA such as fault tolerance, security, power usage, and system performance, and we are presently extending the framework in these areas. Some of these are typical resource constraints and others may be perceived as Quality of Service (QoS) issues.

MicroQoSCORBA is the only middleware framework for embedded devices to which any of the following apply:

Is a “bottom-up” rethinking from the device level up of what constraints and components should be configurable, and in what ways. Top-down approaches using existing solutions or patterns do not scale down nearly far enough for very small embedded devices
Is tailorable for a given application to the wide range of both device constraints as well as application-dictated constraints, with sufficient granularity of configuration constraints.
Will support both the “functional” (baseline application data path) components as well as multiple “non-functional” quality of service (QoS) properties. Support is needed not for the traditional network notion of QoS but more broadly security, fault tolerance, and realtime performance

As MicroQoSCORBA's architecture was being defined to encompass each of these facets, it was quickly determined that traditional distributed systems concepts such as “client”, “server”, “push”, “pull” and so forth were defined at too coarse a level and were not orthogonal enough for use in the fine grained configuration control required for very small environments. To that end, we have further refined these terms and broken them down into their respective orthogonal components. This improved taxonomy of terms proved to be a key component in the successful design of MicroQoSCORBA's architecture.

As the embedded systems market expands, many developers will transfer into this area with a limited amount of prior experience. Those developers will not be capable of directly using implementing the great flexibility that MicroQoSCORBA affords. To solve this problem, MicroQoSCORBA provides a set of CASE tools to aid the developer. The developer specifies the overall system constraints, and then the tools work behind the scenes to meet these requirements. For example, a developer might know that a special project could require certain kinds of interactions with other computers and only a few data types. The CASE tools aid the developer in choosing between the various interaction styles and data type choices that best meet his or her design constraints (e.g., low power, minimal memory). Thus, these CASE tools aid developers who are not experts in embedded systems, middleware, or QoS to leverage the experience of the MicroQoSCORBA development team as instantiated in the toolkit.

The fundamental questions our research is addressing are:

Question 1: Constraints: What constraints must be imposed on middleware to achieve a small footprint (ignoring QoS for now)?

1a) Architecture: What middleware components or subsystems should be constrained? What should their architecture be?

1b) Costs: What memory footprint and power costs are associated with each subsystem or facet? How much can be gained by constraining its flexibility or removing it? What offline profiling tools can be developed to support this?

1c) Models: What models and heuristics for predicting memory and power usage can be developed, to map from larger environments with adequate profiling and other “hooks” onto very small embedded environments where this is not possible? How can spreadsheet-like online tools use these models to allow developers to project the costs of various possible tradeoffs and constraints without having to code them (like with 1b)?

1d) Composition: What composition of the components and constraints compose or interact? What combinations are legal or useful? How do we best allow a developer to constrain them? Are memory and power costs additive when composing multiple components or greater than the sum of the individual costs?

1e) Bottom line: How small and power stingy can we get, and with what constraints?

Question 2: QoS Properties: What strength or “flavor” of QoS properties (security, fault tolerance, realtime) can reasonably be supported in resource-starved embedded systems?

2a) Mechanisms: What mechanisms are used to support each QoS property?

2b) QoS Subsets: What is a subset of these mechanisms that can be used to implement each property that is reasonable in resource-starved environments?

2c) Costs: What are their costs in memory footprint and power consumption?

2d) QoS Composition: What combinations of these mechanisms are useful for resource-starved environments?

2e) Models: How can we extend the models and heuristics from #1c to include the subset of mechanisms chosen in #2b?

2f) Composition with Baseline: What interactions do they have with the functional subsystems and constraints in #1?

Question 3: Network-Wide Composition: What issues, optimizations, and tradeoffs must be made when a network of devices from #2 is integrated? How can we support more global properties, metrics, and goals involving the entire distributed embedded system?

3a) Local-Global Interactions: What is the impact of a single node’s behavior on functional characteristics of the network?

Question 4: Software Engineering Issues: How can we make the research above useable?

4a) Aspects: How can the QoS properties in 2 be organized into aspects that are orthogonal? How can this be woven cleanly in the architecture?

4b) Patterns: What canonical patterns involving combinations of functional constraints and QoS requirements are common in various embedded system domains? How can these be organized to help middleware novices avoid choosing from 2^N or similar number of combinations?

4c) Tools: What are appropriate CASE tools or configuration languages that utilize these patterns to allow novices in systems software and QoS to exploit their extensive application domain expertise to develop effective embedded systems applications. What patterns are useful for novices, and how can we measure the effectiveness of this?

Group Members

David Bakken, Assistant Professor

John C. Shovic, Adjunct Professor

A. David McKinnon, Ph. D. Student

Olav Haugan, M.S. Student

Tarania Damania, M.S. Student

Kevin Dorow, M.S. Student

Publications

McKinnon, D. and Haugan, O. and Damania, T. and Bakken, D. and Shovic, J. “MicroQoSCORBA: A QoS-Enabled, Reflective, and Configurable Middleware Framework for Embedded Systems”, submitted for publication, November 2001.

Funding Opportunities

There are many ways a company can help with this research, including (but not limited to):

o Supporting a student working on supporting the OMG Smart Transducer Interface in MicroQoSCORBA

o Supporting a student developing a handful of wireless devices in MicroQoSCORBA

o Supporting a student developing power-awareness to MicroQoSCORBA

o Support a student developing advanced profiling tools

o Equipment donations of very small embedded devices and their corresponding hardware and software development environments