Reducing costs and risk while speeding development of signal processing system development

Story

February 10, 2017

Denis Smetana

Curtiss-Wright

Radar and other digital processing systems are by their very nature complex and challenging to configure. Depending on the system architecture, the radar program?s team of software, hardware, FPGA and system engineers might require four to eight weeks to optimize the configuration of the board level modules selected for their particular project.

This phase of system development takes place prior to commencing algorithm development. The configuration phase can become costly and time consuming, as the program team familiarizes themselves with the hardware and the available I/O connectivity options if the team does not have a good framework or strong level of understanding of the optimal way to use the hardware, software, and firmware.

A typical radar, signal intelligence, or electronic warfare system development team –at the system integrator, prime, or Department of Defense (DoD) user level – might consist of 10 employees, which means a project-specific group might cost $50,000 per week or more (estimating $5K per labor week).

The primary mission of the team is to develop the signal processing algorithms used on the radar or signal processing system. But, before it can even begin to focus on those critical algorithms, the team needs to understand the mechanisms that will move the data throughout the system. One approach the development team might take is to offload the entire system integration work to the hardware vendor or a third-party integrator to build a turn-key system. While this eliminates this particular work burden, it takes away control of the primary algorithm development from the development team, which is usually their key value-add to the system. Additionally, it leaves the cost problem unsolved since these non-customizable solutions would likely cost more $1 million.

An alternative approach offers the dual advantages of freeing the customer’s radar system development team from much of the configuration optimization problem while also greatly reducing costs. This method sits midway between a dedicated radar system development team and the out-sourcing of the hardware integration phase and has two primary applications. The first is a focus on the data flow of the user’s particular use case. The second is to validate that the user’s specific hardware, software, and firmware configuration works as intended, both functionally and with the expected bandwidth. With this less intensive integration the module supplier develops and delivers a base connectivity “framework” to the end-user, who benefits from the supplier’s familiarity and experience with optimizing system dataflow with their board products.

The dataflow framework provides the development team with an outline of how a system’s boards should be physically connected and configured so that data can be correctly moved around. This reduces design risk and gives the signal processing system team confidence that their specific data paths will function as required and meet their system’s performance benchmarks. Using this approach can greatly ease the integration of the multiple board level products that comprise radar systems, saving valuable time that can be better spent on algorithm composition, optimization, or other key value-adds.

To best leverage its potential advantages, this method should be considered at the beginning of the radar system design. While users are unlikely to share information about how their radar, signal intelligence (SIGINT), or electronic warfare (EW) algorithms work (and what they do), that specific information is not required for development of the framework. Instead of insight into the algorithms, this new approach requires information about the system dataflow and the desired movement of data between cards or different devices on that card. For example, to create the dataflow framework the board supplier needs to know how the I/O will come into the processor card, say from an FMC I/O card to an FPGA, and whether processing will be done to the data in the FPGA, and then DMA data over PCI-Express to the processor board. The amount of data reduction (if any) that occurs in the FPGA will determine what data rate must be supported across the backplane connection. If provided knowledge of the dataflow and the required bandwidths, the board supplier can create the framework.

Included in the framework delivered to the user should be software code and associated firmware that the system development team can use to build on or to use as an example (or corollary) of how to optimally configure their system. Not surprisingly, different digital processor system users will typically have different levels of expertise. While one user may feel very comfortable with one part of the system, it’s likely that they might not be as familiar with another. By providing the radar development team with example code that shows how the system components work together, the framework makes their integration process much less stressful, especially when it requires that they work with unfamiliar modules.

Light Integration Services

An example of how this “light integration” process works is provided by Curtiss-Wright Defense Solutions, which has begun offering what they call Light Integration Services . The first stage of their light integration effort is to work with the user to define the set of requirements they desire. This phase addresses any key risk areas and provides the user with a plan on how to best address those concerns. The next stage of the process is to integrate the system modules and configure them to support the desired use-case. Lastly, the configuration is validated through a set of appropriate tests, and then demonstrated to the user on their own hardware. These tests might include functions similar to the following:

Demonstration of RDMA between all processor nodes on the processor modules interconnected via a 40 GbE Switch and measure bandwidth.
Demonstration of PCIe DMA on a FPGA module transmitting data to one of the processor modules at the necessary speed, as well as interrupt handling by the processor.
Integration of an FMC with an FPGA module
Demonstration of 1 GbE connectivity throughout the system.
Demonstrate SATA inter-connectivity to a third-party drive.

This modified approach to outsourcing, or what Curtiss-Wright dubs “light integration” results in a solid baseline configuration that a user’s radar development team can leverage as a basis for their system development effort.