If you look at the role of military embedded computing systems today, the analogy of a duck coasting along the water comes to mind. The movement of a duck across a pond looks smooth and simple, but just underneath the surface its feet are furiously paddling away. In a similar way, embedded computers run the control and user interface tasks that hide the complexity from the end user. The trend has crept up on the electronics industry gradually, but the main theme of system design today is for more and more functionality to be implemented as software running on an embedded computer. There’s still—and will always be—a shell of real world analog interfaces that those subsystems connect to—sensors, actuators, motor controllers and so on—but the idea of a computer as the primary “traffic” manager and user interface engine has become firmly entrenched.

For the Navy the trend seems to be toward reducing crew size by automating tasks that have traditionally required specialists. For the other military branches, it’s more about taking the vast amount of incoming Intelligence, Surveillance and Reconnaissance (ISR), and organizing and presenting it in ways that don’t have to be interpreted manually by experts in signals analysis. The goal of an end-to-end network-centric military means providing information that any level of warfighter can access and act on.

Situation awareness systems are specifically hard pressed to deal with these issues. This avalanche of ISR data that’s coming in from multiple sources is actually causing a serious challenge for situational analysis systems. In its raw form, that data is made up of massive amounts of signal and imagery data. Problem is, the intelligence processing and exploitation capability has been limited to highly trained analysts and applicable only after the threat occurred. That limits the ability of non-technical individuals to “connect the dots” and affect mission outcomes in real time.

The good news for our embedded computing industry is that the solution to handling this “information overflow” is more and more powerful embedded computing. But the other leg of the solution is more advanced applications that process and sort the data for the warfighter so he can use it in real time. Companies like IvySys are doing some specific work addressing those needs. By applying signal processing algorithms to the problem it’s possible to detect potential threats as they surface. The company says this can be applied to deep domain expertise in signals intelligence (SIGINT), measurement and signature intelligence (MASINT) techniques, and to cyber security.

This trend of hiding system complexity also seeps down the food chain into the development of complex processing systems. Today we have almost an excess of computing muscle available, while the ability to properly exploit that increased compute-power is facing the classic “law of diminishing returns.” That could drive a shift to new ways of thinking when it comes to architecting systems. Such shifts have happened before of course. At one time general-purpose processors (GPPs) carried the full burden of processing tasks in military embedded computing. Then came Digital Signal Processors (DSPs) to act in a role as adjunct accelerators, leaving GPPs to handle system management types of tasks. Then more recently FPGAs, as they have become denser and more sophisticated, now offer on-chip DSP functionality that rivals stand-alone DSPs. Moreover, FPGAs can provide the benefit of application-specific—or rather, waveform-specific—logic implemented on chip.

Now, the latest concept is the idea of putting high-performance graphics processors to work on general-purpose processing tasks. Graphics processing units, or GPUs, are programmable floating-point graphics-rendering engines primarily used in personal computers, workstations and gaming consoles. Because of architectural advancements in GPUs in recent years, these devices provide unprecedented performance. And their “performance per watt” fits nicely into the military’s increasing requirement for reducing system Size, Weight and Power (SWaP).

Implementations of this idea of “GPUs as general-purpose processing engines” also falls nicely into the theme of doing more while keeping the complexity at bay—complexity to the system developer in this case. Along those lines, graphics chip vendor NVIDA developed a parallel computing architecture called CUDA (an acronym for Compute Unified Device Architecture) that addresses a key weakness of FPGA parallel processing systems: the complexity of programming them. CUDA is the computing engine in NVIDIA graphics processing units (GPUs) that is accessible to software developers through industry standard programming languages.

CUDA lets programmers use conventional computing languages to access the massively parallel processing capabilities of the GPU. Aside from serving applications in radar, signals intelligence and video surveillance and interpretation, GPUs based on the CUDA architecture have potential in other application areas including target tracking, image stabilization and SAR (synthetic aperture radar) simulation. Sensor processing and software defined radio are also well suited for this kind of processing. Board-level products have emerged specifically for GPGPU computing in a number of form factors including OpenVPX.

The bottom line is military electronic systems—across all branches, manned and unmanned, large and small—continue to head in the direction of increasing compute-power as programs require ever more functionality, autonomy and intelligence. And that’s all good for our segment of the industry because it drives demand for faster embedded computing and other more sophisticated electronic subsystems of every kind. The systems engineers’ job will be to apply that gear in implementations that run smoothly—as smooth as that duck looks on the surface of the water.