DARPA ITO Sponsored Research

2000 Project Summary
Dynamic Domain Architectures for Model Based Autonomy (DDA for MBA)
Massachusetts Institute of Technology (MIT)

Project Website: No URL -- Additional project information provided by the performing organization
Quad Chart: Quad Chart   provided by the performing organization

The nature of embedded system software has changed fundamentally. In avionics, for example, yesterday's embedded software was a federation of relatively simple control loops; but today's embedded software systems are the glue which integrate the entire platform, presenting high level situation awareness to the pilot. Soon there will be UCAV's in which software will play the role of the pilot, blurring the traditional boundary between pilot and platform and requiring wholly new forms of integration.

Current techniques for producing these systems are inadequate. The traditional approaches of entangling concerns in order to meet space and time constraints has led to software systems inconsistent with the goal of evolution. Model-based methods offer a better approach:

  1. Programmers have a variety of models in their heads;
  2. these models structure the problem into functional domains, into levels of abstraction and into techniques for managing cross-cutting concerns.
  3. They use these models to translate high level goals into code.
  4. The power is in the models. Instead of throwing them away once code is written, they should be represented explicitly and used to synthesize efficient reactive code. They should be available in the runtime system to faciliate integration and robustness.

The software must present a model-based view of its execution in terms of goals, strategies, plans, state-variables, and invariants. These should be monitored at runtime and the failure to achieve expected results should trigger diagnosis, reconfiguration and recovery.


At the lowest level, reactive controllers iterate through the following three steps:

  1. Mode Identification which attempts to characterize the current state of the system;
  2. Mode Selection, which is invoked if the current state is faulty, and which identifies a working mode of the system that is reachable from the current state;
  3. Reactive Planning which identifies a set of steps capable of achieving the goals posted by Mode Selection and by external components.

Thus the software must make deductions at reactive speeds. But, the computational power available to embedded systems is becoming abundant, allowing model-based deduction to be embedded even in the lowest level, reactive components of the control systems.

Embedded software should be developed against the backdrop of model-based frameworks, each tailored to a single (or a small set of) issues. Some frameworks deal with cross-cutting issues such as fault tolerance; others deal with particular components and functional layers of a complex system (e.g. control of an observational asset in a UCAV). A framework, as we use the term, includes a set of properties with which the framework is concerned, a formal ontology of the domain, an axiomatization of the core domain theory, analytic techniques tailored to these properties and their domain theory, a runtime infrastructure providing a rich set of services, and an embedded language for describing how a specific application couples into the framework.

A framework thus reifies a model in code, API, and in the constraints and guarantees the model provides. Each framework exposes its own goals, plans, state-variables and invariants in terms of an embedded language which captures the terms and concepts used by application domain experts. Each framework also expresses its dependencies on other frameworks in the same language. These are then used to synthesize the code which integrates the ensemble of frameworks into a unified, reactive system.

Recent FY-2000 Accomplishments:

PI's attended program kickoff meeting, presented the project plan, and participated in workshop topics.

FY-2001 Plans:
  1. We will redesign the Livingstone kernel along the lines of the the DDA framework.
  2. We will study how to create generalized versions of the Livingstone executive capable of supporting the operations of an Intelligent Room testbed, and of a Separated Spacecraft testbed.
  3. We will recode the Livingstone kernel in the DDA framework.
  4. We will develop semantic models for the primitives of distributed cooperating autonomous systems.
  5. We will develop or select embedded languages, including RMPL for expressing plans, schedules and goals, for use in DDA frameworks.
  6. We will identify the crucial models used in DS1, and study how to express them as parameterized DDA frameworks.
  7. We will implement the languages selected in a prior task for use in DDA frameworks.
  8. We express the crucial models used in DS1 as parameterized DDA frameworks.
  9. We will define and reuse/customize analysis tools that support constraint checking, constraint propagation, and consistency checking.
  10. We will create generalized versions of the Livingstone executive capable of supporting the operations of an Intelligent Room testbed, and of a Separated Spacecraft testbed.
  11. We will study how to apply the reimplementation of Livingstone to our Intelligent Room and Separated Spacecraft testbeds.
  12. We will identify complementary MOBIEs efforts and design mechanisms for integrating the results of those efforts.
  13. We will apply the reimplementation of Livingstone to our Intelligent Room and Separated Spacecraft testbeds.
  14. We will begin participating in MOBIEs program-wide evaluation efforts along with partners identified earlier
Technology Transition:

The results of this work will take the form of software, representation languages, and knowhow. The software will be a collection of prototype programs including a Framework Developer's Toolkit, a Dynamic Virtual Machine and a heterogeneous reasoning system suitable for program analysis. The representation languages will provide a way of describing, and perhaps more important, thinking about the structure and behavior of large scale embedded systems. These languages, and the knowhow that goes with them, will be described in technical papers and manuals, illustrated with examples from our work, and applied to tasks of interest to DARPA customers.

The technology will be transferred outside of MIT via several paths: traditional publication of re- search papers; network publication of software artifacts, manuals, and papers; through our students and through collaborations with other MOBIES contractors. The research will be concretely realized in software artifacts: programming environments, run-time systems, analysis and monitoring systems, representation languages and programmer interfaces. Usable software systems are a strong way to make a point, and the Internet will provide a venue for wide dissemination of the technology in source-code form for general use by the global Internet community.

MIT students are an important vectors for transferring technology out into the real world. Besides the graduate students whose dissertations will comprise much of the research, MIT also has a long-standing commitment to involving undergraduates in ongoing research through the Institute's UROP program.

Principal Investigator: Brian Williams
Cambridge, MA 02139
617-253-5060 fax

Robert Laddaga
MIT AI Lab - NE43-804
545 Technology Square
Cambridge, MA 02139
617-253-5060 fax

Agnes Chow
MIT AI Lab - NE43-932
545 Technology Square
Cambridge, MA 02139
(617) 253-3491
(617) 253-4734 fax