About APSServicesEmploymentSite MapContact Us
GRAVITY Communications Framework
Augmented and Mediated Reality
GRAVITY Communications Framework
 

APS’ Gravity Framework

Overview

APS’ Gravity Framework is an open architecture designed to facilitate the rapid development of large-scale modular software systems, distributed across a heterogeneous network of computational hardware. Gravity leverages the best of current open-source software technologies to provide a scalable, modular, non-proprietary, and reliable high-performance environment that simplifies the interaction btween modules written in many popularprogramming languages (including C/C++, MATLAB, Fortran and Java) and provides valuable services (e.g. directory, archiving, logging, performance analysis) without imposing any significant restrictions on components or messages


 .

Figure 1 Gravity Application Stack




Architecture Approach

The Gravity framework is currently being used to address the need for a high-performance modular software architecture in support of APS's customers in many agencies and organizations. Gravity is enabling rapid development of a system that integrates computationally intensive radar algorithms in multiple languages, variable data rate sensors, and multiple user interfaces for ocean environmental sensing. Gravity is also being used in applications that provide the infrastructure between modules executing on autonomous vehicles. Gravity is built on open source libraries that provide critical performance oriented capabilities::

Ø  0MQ is an open-source networking library that provides a network layer built on TCP/IP which abstracts many of the details of working directly with sockets and provides simplified implementations of various transport protocols, including publish-subscribe and request-response.

Ø  Google Protocol Buffers are Google’s open-source, language-neutral, platform-neutral, extensible mechanism for serializing structured data.

Gravity offers many features that distinguish it from many of the available modular system libraries:

Ø  Open Standards: Fully non-proprietary with unlimited government-use rights.

Ø  Performance Oriented: Built on open source libraries that have been optimized to maximize throughput and minimize latency.

Ø  Broker-less: Gravity imposes no message brokers, middleware components, or other required process that must execute on your system, saving valuable system resources. Gravity provides direct peer-to-peer connections between components, optionally coordinated by a Gravity Service Directory module.

Ø  No requirements or restrictions on components or message content: Gravity provides the underlying message protocol without restrictions on content. In this way, systems built using Gravity can be made compliant with existing systems and standards (e.g. JAUS).

This figure shows the application stack for the Gravity Framework. Users of the Gravity library build their applications on top of the Gravity Node API and have access to all the Gravity Services.


System Module Interaction Paradigms

The Gravity framework is built around publish-subscribe and request-response interaction protocols that have proven powerful in high performance modular systems. The publish-subscribe protocol isolates the components that produce data from those components that consume it, reducing the coupling between components that leads to brittle system designs.  However, publish-subscribe is ill-suited to handle the common interaction pattern in which one component is tasking another and must wait for it to finish (or error, or timeout) before proceeding. For these usage patterns, Gravity provides the request-response interaction pattern with support for flexible service discovery to mitigate against the effects of tighter coupling.

Portability and Language Specification

Gravity minimizes significant language, platform, or operating system restrictions on individual modules or their developers. In this way, this single architecture will allow the system to take advantage of a diversity of hardware (from low-power embedded systems to racks of servers) and development teams. Gravity has been used on systems that integrate modules written in many languages (e.g. C, C++, Java, Fortran, MATLAB) across varying operating systems (e.g. Linux, Windows). This means that existing modules can be integrated into the overall system without the need to port to a common language or OS. Rapid prototypes can be developed in MATLAB and integrated with the operational system for test and evaluation.

Gravity Services

There are many features built into Gravity from which users will derive immediate value.

Service Directory

The Gravity framework integrates a service directory capability that allows for individual system modules to register their output data products and lookup providers for their required input data products. This feature simplifies the system configuration, allowing the system to be easily reconfigured so that processing can be easily moved from one platform to another to take advantage of the most appropriate host hardware. New configurations can be easily constituted for testing, operational use, or to transition to improved hardware capabilities in the future.

Logging

In order to reconstruct the operational behavior of the system, Gravity supports module logging. Gravity has built-in support for logging that can be configured for each individual module by selectable severity level. The logger can be configured individually for each module with specification log level (e.g. Debug, Warning, Error). The levels make it easy to identify high-priority messages as well as limit the amount of logging data stored locally or transmitted across the network. The Gravity logging system supports local logging on the module host as well as the transmission of those logs to a central location.  Identification of software faults is a consistent challenge in large, distributed systems. The availability of Gravity’s logging capability is essential to identify and localize these faults.

System Configuration

Configuration files can help achieve system flexibility because they allow for the initialization of key functional parameters without the need to recompile source code. Traditional implementations of configuration files for distributed modular systems can, however, promote errors in configuration management because the individual configuration files are distributed among the compute resources along with the modules, requiring a manual process for managing the inevitable dependencies between them. In addition, configuration settings can become confused or lost when attempting to reconstruct a previous system execution. Gravity’s system configuration allows for all configuration settings to be located in one easily accessible file. In addition, the system automatically archives all module settings at each re-start of the system such that previous runs can always be reconstructed with the appropriate settings.

Archive & Replay

During the development, testing, and operational phases of a complex distributed system it is valuable to be able to view, analyze, and reproduce all module interactions after an execution of the system. The Gravity framework supports this requirement through its built-in archive and replay modules. These modules can be configured to archive any module interaction and provides the ability to replay the archived data for future analysis and testing by providing a repeatable data flow through components of interest in order to reproduce and isolate bugs that occur only under nondeterministic conditions.

Visualization

The Gravity framework provides several network visualization tools that will assist in the testing, debugging, and general understanding of the system. These user interface modules assist in analyzing the performance of the network, identifying data flow, bottlenecks, and assessing overall bandwidth utilization. These tools are invaluable in providing an intuitive representation of the operations of the system and its data flow.

Gravity API/Examples

Gravity is designed to simplify the interaction between system modules, allowing the system developer to focus their effort on their higher level modules. Gravity’s simple API is demonstrated in the following C++ code examples (other supported languages offer similar APIs):

Initialize the component interface to Gravity

// Create and initialize the interface to Gravity (C++)

GravityNode gravityNode;

gravityNode.init();

Configure a communication channel for publishing a data product

// Register a data product for publication

gravityNode.registerDataProduct(“WIND_DATA”, 5555, “tcp”);

Create and publish a data product

// Create custom data

WindData windData;

windData.set_speed(2.5);

windData.set_direction(45.0);

 

// Package data in GravityDataProduct

GravityDataProduct dataProduct(“WIND_DATA”);

dataProduct.setData(windData);

 

// Publish Data

gravityNode.publish(dataProduct);

Configure a communication channel for subscribing to a data product

// Setup Subscription (with this component notified when subscription is filled)

gravityNode.subscribe(“WIND_DATA”, this);

// Setup subscription with a filter

gravityNode.subscribe(“WIND_DATA”, this, “SHIP_A”)

Receive a data product

// To receive subcription data, the subscriber implements this method

void subscriptionFilled(const GravityDataProduct& dataProduct) {

// create and fill windData from received GravityDataProduct

WindData windData;

dataProduct.populateMessage(windData);

}

Unsubscribe to a data product

// Unsubscribe (no longer want to be notified for this data)

gravityNode.unsubscribe(“WIND_DATA”, this, “SHIP_A”);

Unregister a data product

// Unregister (no longer want to publish this data)

gravityNode.unregisterDataProduct(“WIND_DATA”);

Establish a service

// Register this component as a service to be made available to system

gravityNode.registerService(“METOC_SERVICE”, 5556, “tcp”, this);

Respond to a service request

// To receive a request, the service implements this method

void request(const GravityDataProduct& dataProduct) {

// create and fill metocRequest from received GravityDataProduct

METOCRequest metocRequest;

dataProduct.populateMessage(metocRequest);

}

Make a request to a service

// Make request and have calling component notified when response is received

GravityDataProduct request(“METOC_REQUEST”);

request.setData(metocRequest);

gravityNode.request(“METOC_SERVICE”, request, this);

Unregister a service

// Unregister this service

gravityNode.unregisterService(“METOC_SERVICE”);

 

 

 

 

Top of Page
Copyright � 2007-2017 Applied Physical Sciences Corp. All rights reserved. Designed/Developed by WebSolutions