2005 MURI White Paper: Difference between revisions

From Murray Wiki
Jump to navigationJump to search
(=MVWT=)
(=Alice=)
Line 61: Line 61:


==== Alice ====
==== Alice ====
* Not sure whether we should really include this
 
As a second testbed, we will make use of the infrastructure we have developed over the past 2.5 years through our participation in the 2004 and 2005 DARPA Grand Challenge.  Our current vehicle, which the students have named "Alice",


== Potential impact on DoD capabities (Richard; 1/2 page) ==
== Potential impact on DoD capabities (Richard; 1/2 page) ==

Revision as of 16:07, 2 August 2005

Return to 2005 MURI Proposal

Cover letter (optional)

  • Not sure what to put here. Perhaps description of team? Assume this won't be read by anyone but program manager.

Cover Page

  • The cover page shall be labeled “PROPOSAL WHITE PAPER” and shall include the BAA number 05-017, proposed title, and proposer’s technical point of contact, with telephone number, facsimile number, and email address

Identification of the research and issues (Richard; 1/2 page)

We propose to develop a mathematical language for specification, design and verification of distributed, embedded systems that provides an analyzable framework for robust performance.

Our specific goals for this MURI are to:

  1. Develop common mathematical framework for analyzing distributed, hybrid systems. This framework will be able to handle a combination of continuous dynamics and temporal logic, building on our previous work in analysis of hybrid dynamical systems. This will require a significant extension of current work to include temporal logic and distributed computing. In addition, we believe that it will be important to include stochatic systems, extending work such as SoSTools to include probabalistic analysis.
  2. Extend ideas from distributed/parallel computing to apply to dynamical systems. Concepts such as fairness, safety, progress and concurrency are not strongly linked with concepts such as dynamics, stability and performance in embedded systems. We plan to extend tools in distributed computing to allow for dynamic changes in behavior and provide methods for analyzing robustness to such changes. This includes incremental changes (evolution of the dynamic state), large changes (changes in mode or failure of a component) and probabalistic changes (noise, disturbances and other stochastic uncertainties).
  3. Move the handoff between handcrafted proofs and formal methods further upstream. A major theme of our work will be to show how to take currently handcrafted proofs and formal methods for verification and validation of embedded systems and move them to higher levels of complexity and abstraction. This will enable the design of increasingly complex systems without the need for huge amounts of iteration and Monte Carlo analysis to verify performance.
  4. Demonstrate the utility of these methods on problems in network centric environments. We will make use of two testbeds at Caltech for this purpose - the Caltech Multi-Vehicle Wireless Testbed (MVWT) and "Alice", our 2005 DARPA Grand Challenge entry. Alice provides a sophisticated embedded system environment that includes 5 Gb/s raw data rates from sensors, 12 high speed processing cores linked by 1 Gb/s ethernet and a complex set of tasks and environments for autonomous operations. The MVWT offers a simpler dynamic and computational environment, but allows cooperative control of multiple vehicles operating in a dynamic, uncertain and adversarial environment. In each case we propose to develop a collection of primitive operations which can be used to "program" the systems and provide automatically verified code that satisfies a given performance specification.

Proposed technical approach

Background (Richard; 1/2 page)

DoD systems are becoming increasingly sophisticated as we seek to design, build, test and field systems that are capable of higher levels of decision making and stronger integration into C4ISR infrastructure. The command and control software required to implement such systems is increasingly complex and our ability to verify that a system meets its specifications and validate the proper operation of the system is fast becoming a bottleneck in deploying new capability.

A distributed, embedded control system requires a sophisticated supervisory control structure that not only switches between control modes, but also manages communication and information among UAVs, responds to commands, automatically generates tasks and subtasks, monitors the health of the system, and so on. However, current software engineering practice cannot produce large complex systems for which any substantial formal guarantees can be made. In fact, in software engineering, it is usually assumed that large systems will have bugs. Unfortunately, the enormous complexities of such systems coupled with the fact that they are embedded in a physical, often adversarial, world means that exhaustively testing them is essentially impossible. The cost of and time associated with developing software for these systems makes rapidly reconfiguring them to adapt to new scenarios impossible. This makes the entire infrastructure fragile and susceptible to failure and compromise.

We seek to address this situation through the development of new approaches for specifying, implementing and verifying command and control systems. We will build on two new areas of development over the past five years under AFOSR and other funding: sum-of-squares techniques for constructing proof certificates for hybrid systems and formal methods for analysis and design of distributed computation and control systems. New results in each of these areas are ripe for further development and integration as part of developing a mathematical framework for analyzing distributed, hybrid systems.

Sum of Squares Techniques (Pablo, with John; 1 page)

  • Provide a short (1-2 paragraph) background on current state of SoS
  • Talk about what is lacking from current approach
  • Give some insights into how we plan to approach this and desired results

Specification and Programming Languages (Eric, with Mani; 1 page)

Two of the PIs (E. Klavins and R. Murray) have recently designed a specification language called CCL (The Computation and Control Language) that is model loosely after UNITY (developed by M. Chandy for modeling parallel systems) and which bears a strong resemblance to Promela (part of the SPIN model-checker developed by G. Holtzmann, a collaborator on this project). The idea behind CCL is to allow the control engineer to specify a simple model of the behavior of the system and to specify and reason about correctness properties in temporal logic. In particular, CCL allows (1) a formal model of the environment to be included as part of the specification and (2) allows the user to specify a model of how synchronized the distributed control elements are to be with each other and the environment (for example, one could say that the frequency of their clocks differs by no more than some small amount). Thus, the goal of CCL is to replace software engineering and testing with model-building, formal specification and proof.

Presently, there are many limitations to CCL (and of other systems that attempt to accomplish the same thing) that allow it to be used for only simple systems. First, the proofs in CCL are done by either by hand or with the help of a difficult to use theorem prover. Second, specifying and reasoning about a sophisticated set of continuous feedback control laws in CCL is difficult due to the fact that one typically uses a different tools to reason about concurrency (e.g. model checking and theorem proving) than one uses to reason about dynamical systems (e.g. barrier functions and sum of squares). Third, incorporating stochastic elements, such as the probability of a component failure or of the behavior of an adversary, in a formal and tractable way is presently impossible.

We propose to improve the approach in several ways:

  • We propose to simplify the language to disallow arbitrarily complex specifications. The PIs believe that a simple set of building blocks, each accompanied by a formal reasoning tactic will allow the "specification and proof" engineer to easily build and reason about systems without having to do one-of-a-kind proofs.
  • We propose to develop a common framework for reasoning about continuous controllers, dynamical systems and concurrent, loosely synchronized supervisory control structures. The PIs believe that the tantalizing use of barrier functions in hybrid control structures can be extended to systems with the sophistication of those specified in CCL.
  • We propose to extend our techniques to include probabilistic specifications. The state of the art in probabilistic model checking, for example, is presently to the point where simple systems can be reasoned about efficiently.

Testbeds (Richard; 1/2 page)

To test our methods and motivate new insights into their performance (and limitations), we plan to make use of two testbeds that have been developed at Caltech: the multi-vehicle wireless testbed and "Alice", an autonomous vehicle that will compete in the 2005 DARPA Grand Challenge. These systems represent complementary challenges that are very representative of those faced by designers of Air Force systems (and systems of systems).

MVWT

Over the past five years (under AFOSR DURIP and MURI funding), Caltech has built a testbed consisting of up to 18 mobile vehicles with embedded computing and communications capability for use in testing new approaches for command and control across dynamic networks. The system allows testing of a variety of communications-related technologies, including distributed command and control algorithms, dynamically reconfigurable network topologies, source coding for real-time transmission of data in lossy environments, and multi-network communications.

We propose to use the MVWT to demonstrate the ability to specify and verify cooperative control missions for multiple vehicles. We will do so by building an automated specification and proof interface to the MVWT that implements our approach to building systems that exhibit complex behaviors. Sample tasks include cooperative surveillance, area denial (in adversarial environments), and dynamic reconfiguration in the presence of vehicle failures (full or partial).

Alice

As a second testbed, we will make use of the infrastructure we have developed over the past 2.5 years through our participation in the 2004 and 2005 DARPA Grand Challenge. Our current vehicle, which the students have named "Alice",

Potential impact on DoD capabities (Richard; 1/2 page)

Potential team and management plan (Richard; 1/4 page)

Summary of estimated costs (1/2 page)

  • $1M/year

Curriculum vitae of key investigators

  • Note: this section does not count against page limit
  • Everyone should send Richard a 2 page CV to be included