Kinesthetics eXtreme

 

Active Projects »

Managing Sensitive Data on Mobile Devices

Supporting privacy requirements on mobile devices

 

Overcoming the Intuition Wall: Automatic Graphical Analysis of Programs to Discover and Program New Computer Architectures

A joint project encompassing computer architecture, machine learning and software engineering

 

An Open Software Framework for the Emulation and Verification of Drosophila Brain Models on Multiple GPUs

Software frameworks and tools to emulate fly brains

 

Software Testing for Non-Testable Programs

Automating metamorphic testing techniques at runtime

 

In Vivo Testing

Executing tests in the deployment environment, using the state of the running application

 

Societal Computing

Exploring the impact of computational tradeoffs on societal concerns such as Privacy, Green Computing, Sustainability, and Cultural Differences

 

ARIS

Automated Online Evaluation for Improving Cyber-Physical System Reliability

 

genSpace

Enabling collaboration support for users of the geWorkbench computational biology tool

 
 

Our current mission is to develop a feedback/feedforward infrastructure for run-time monitoring and repair/reconfiguration of component-based distributed systems.

The DARPA Dynamic Assembly of Systems for Adaptability, Dependability, and Assurance (DASADA) Program involves research into software probes and corresponding measurement gauges.  The program is developing a standard for the structure of probe events that will be processed by gauges.  Columbia University’s Programming Systems Lab, OBJS, BBN, and other DASADA participants have developed an initial version of the proposed schemas.

An example message using the schema is located here.  The schemas are intended to function as SOAP blocks.  A SOAP message has a header section, a body section, and an optional faults section.  Each section can contain one or more blocks.  Further information on SOAP can be found at http://www.w3.org/2000/xp/.  Current usage is to put the context block in the header and one or more content blocks in the body.  There are currently two content blocks defined, one very low level, one very high level.  It is assumed that most users will want to define their own content blocks as well.

The low-level probe content block contains information about a particular function/method call, including name, parameters, value of “this,” return value, and exception information.  The high-level probe content block identifies an architectural mutation, involving components, connectors, and so forth.  A possible usage of this probe format is for the probe to generate low-level events, which are augmented by successive processing with higher-level information.