Fielding signal intelligence (SIGINT) capabilities in airborne ISR systems involves more than adding signal processing functions to a sensor. From a mission operator’s perspective, it requires the integration of airborne sensor functions to the corresponding exploitation tools located in the ground station enterprise.
These tools are typically referred to as Processing, Exploitation and Dissemination (PED) applications. PED software provides the capability to task sensors, process sensor data, exploit sensor data from multiple sources, and disseminate intelligence products.The combined airborne and ground capabilities support predictive battle-space awareness, indications and warning, current intelligence, analysis of enemy courses of action, targeting and weapon selection, mission planning, and execution of air combat training missions. In the era of accelerated technology insertion, coordinated technology upgrades of both airborne and ground software is imperative. Any misstep can cause unwanted delays. Component based architectures, like REDHAWK/Tactical Open Architecture (TOA), using open command/control interfaces provide some of the answers to coordinated weapon system upgrades.
REDHAWK Software Framework /TOA Plugin
REDHAWK is an open-source software framework providing infrastructure and tools to support the development, deployment and management of signal processing applications. Using REDHAWK software, these applications can be reused on different sensors with minimal integration effort. TOA is a companion product to REDHAWK that supports software “plugin” development through its common services and application programming interfaces. These development and deployment capabilities enable integrated system operations. As a SIGINT software developer, VTS has successfully used REDHAWK/TOA to develop and deploy innovative airborne and ground SIGINT applications.
REDHAWK/TOA Development and Deployment
Our most recent research focused on integrated applications that brought together both airborne and ground processing in a unified manner. During this research, we developed a TOA “bridge” plugin that provides the framework for integrating airborne signal processing applications with ground exploitation applications. This reusable plugin will allow REDHAWK software developers to quickly build applications for the ISR enterprise.
REDHAWK/TOA Software Development
REDHAWK/TOA is a large framework that provides users a significant amount of capabilities straight out of the box. The framework documentation provides many examples in Python, but is somewhat lacking in Java and JavaScript, both of which are supported. This can make new development with these technologies frustrating and time consuming.
The VTS team has had significant experience writing ground applications that interface with REDHAWK/TOA sensors, both in Java and JavaScript. We have invested time fine-tuning connection methods, receiving and processing different types of TOA-provided data, and improving code stability and maintenance requirements. The purpose of the TOA Bridge is to provide a Java developer with an abstracted, simplified means of interacting with a SIGINT sensor running the REDHAWK/TOA software defined radio framework.
The Reusable TOA Bridge
The intent of the TOA Bridge is to make integration between a Java application and a TOA sensor incredibly easy and straightforward. The TOA developer guide is 160 pages, while the TOA API Reference guide is 380 pages. While it is important to understand which TOA APIs are provided, and what data can be obtained from each, there is a lot of information and details that can be abstracted away from a developer by using the proposed TOA Bridge. It allows developers unfamiliar with TOA to easily jump in and develop a Java application to interface with TOA.
The TOA Bridge is a reusable Java library that eliminates a lot of duplicated code. Every Java application that wishes to interface with TOA would only implement code for how they wished to process specific data types. The TOA Bridge would provide the creation and handling of the REDIS connection. And it would handle all the extraneous, uncommon functionality for creating and opening streams to TOA Task Instances.
The TOA Bridge would provide an easy starting point for a Java application to interface with TOA.
Expanding TOA’s UI Technology Choices
Software developers building ground station applications for REDHAWK/TOA sensors can easily do so by using the TOA Bridge. Because of the complexity contained within air/ground C2I design, ISR software developers may limit their decision on what user interface (UI) technology or software framework to use based on how well it integrates with REDHAWK/TOA. For example, the Raptor X framework is commonly used to interface to TOA because the framework maintainers have added TOA support by providing a connection jar with the framework. The TOA Web UI is also commonly used because the TOA connection is provided in the out-of-the-box web application.
The TOA Bridge provides technology freedom to UI developers who are working with existing applications or are considering other UI frameworks to integrate with TOA sensors. The bridge essentially gives a UI developer a “leg-up” during application development.
TOA Bridge Design
The bridge provides two types of TOA communication objects. A regular request/response object, and a streaming data object. Streaming communication is one in which a stream is opened and asynchronous data is sent on that stream. Examples of streaming communications is receiving navigation, spectral, and audio data. The request/response communication is one in which a request is sent and a response is received. An example of this type is the connection made to retune a task instance allocation.
TOA Bridge Java Class UML Diagram
The starting point for using the TOA Bridge is to create a ToaConnection. This is created by providing an IP address and port for the REDIS connection. The bridge will create the connection and provides a test method to ensure if the connection is valid. This connection class also provides a method that returns all task instances for a given API type.
Once a ToaConnection has been created, the calling application will use that to generate either request response or streaming objects to communicate with the sensor. To begin receiving streaming data, the application will create one of the streaming objects and implement the associated listener for it. For example, to receive Navigation data, they will create a ToaNavStream and will implement the ToaNavDataListener. The original ToaConnection is passed in during ToaNavStream creation thereby passing in the REDIS connection to use. By implementing the ToaNavDataListener interface, when data is received on the stream, the onData method in the caller’s application will be called, passed in the Location data.
The same pattern is followed for all streaming data. To receive audio data, the calling application will create a ToaAudioStream and will implement the ToaAudioDataListener. The listener’s onData method is called with AudioData. Along with navigation and audio streams, the bridge also provides a spectral stream implementation. However, expanding the bridge to include more streaming data types would be a simple task.
In addition to streaming data, TOA uses request/response implementation for communication and specifically, tuner management functionality. The bridge provides a ToaTunerManagement object that exposes methods to createTaskInstance, retune, deleteTaskInstance, and getDeviceStatus. For each of these methods, the ToaConnection is passed in providing the REDIS connection. The responses returned are the requested data. For example, the deleteTaskInstance will return the TaskInstance that was deleted.
A minimal amount of TOA classes are required to use and implement this functionality. Most of the work is done in the bridge. To create a task instance, the calling application only needs to provide a ToaConnection, a string for the assembly and task instance IDs, and a TunerConfiguration object.
Code Example with and without the TOA Bridge
The following code excerpt demonstrates how a developer would open a navigation stream without the benefit of the TOA Bridge. For every API type, there are different objects that are needed to open a stream or communicate with a task instance. For example, the navigation open stream requires LocationStream, LocationStreamConfig and Locations TOA objects. The FEI Allocation update method requires FeiAllocation, AllocationsConfiguration, AllocationConfigRequest, TunerAllocation, and FeiAllocations TOA objects. When using the bridge, Locations is the only object needed for navigation while FeiAllocation and TunerAllocation are the only required objects for retuning.
public void openStream(final String taskInstanceId) {
final LocationStream locationStream = new LocationStream();
final LocationStreamConfig locationStreamConfig = new LocationStreamConfig();
locationStreamConfig.setId(taskInstanceId);
locationStream.setConfig(locationStreamConfig);
final Locations locations = new Locations(getRedisConnection());
final IStreamClient client = locations.open_stream(locationStream, null,
new NavStreamMsgCallback(getListener()), new NavStreamErrorCallback(getListener()));
}Navigation Stream without the TOA Bridge
The following code excerpt illustrates how to open a navigation stream and process the platform data using the TOA Bridge. The bridge design patterns make it significantly easier to integrate with REDHAWK sensor applications by minimizing the number of object references and method calls using optimized integration abstractions.
public void toaCreateNavConnectionTest(final String id) {
final ToaNavConnection connection =
(ToaNavConnection) ToaConnectionFactory.getStreamingConnection(ToaStreamingApiType.NAVIGATION, HOST, PORT, this);
final boolean opened = connection.openStream(id);
}
@Override
public void onData(final List<Location> data) {
if (data != null) {
LOGGER.info(String.format("Received %s locations.", data.size()));
}
}
@Override
public void onErrorMessage(final String error) {
LOGGER.info(error);
}
Navigation Stream using the TOA Bridge
Conclusion
Enterprise ISR systems require ground PED applications that are seamlessly integrated with airborne sensors. For these systems, the REDHAWK/TOA framework helps reduce software development timelines and system integration costs while providing a capability that scales across the enterprise, but the initial learning curve for end-to-end capability development is steep. The software design patterns within the TOA Bridge help simplify air-ground application integration. The TOA Bridge also simplifies the development Java-based PED applications. VTS’ sensor-to-PED research has resulted in the creation of software components like the TOA Bridge, which reduces the development and integration for enterprise systems.
If you are interested in learning more about the TOA Bridge software or other REDHAWK/TOA capabilities, please contact us at info@vts-i.com.
Acknowledgements and References
The author acknowledges VTS’ embedded and enterprise software teams for their contributions to the design and testing of the TOA Bridge. The embedded team under the leadership of Eric Ferrara provided guidance and recommendations on TOA integration with sensor applications while the enterprise team under the leadership of Jill Thornton provided guidance on integration with enterprise exploitation architectures.
