It’s important to look at the whole system, not just what the customer is asking for—that way, we often give them more than they expected, but exactly what they need.
GMS CTO Chris A. Ciufo recently participated in a roundtable panel on the design and development of embedded computing systems for UAVs. His responses give military customers insight into mastering the art of defining small form factor (SFF) embedded computers for these systems.
SFF Steps To Success At the risk of sounding obvious, it’s essential that the customer provide a very clear system Statement of Work (SOW), or in absence of that, be willing to be “interviewed” to provide a thorough understanding of the problem that needs solving. It’s quite common for a customer to come to us merely wanting a certain type of form factor, a favorite processor, and some select I/O. But this approach pre-assumes that the customer already thinks they know what they want.
“If we fail to keep op-tempo with the enemy’s technology, we’ll have to fight with overwhelming force to stay even. We can’t afford to do that on so many fronts.”
General Micro Systems offers boards, boxes, and complete systems from small form factors all the way up to displays with everything I just listed embedded inside (Figure 1). With so many system-level and packaging options, it’s important for us to assess the complete problem before settling on one or more possible solutions.
The system architecture of a UAV breaks down into three major sub-systems: airframe (flight controls), payload (sensors), and weapons (for UAVs capable of offensive operations). Table 1 shows the notional components of each major sub-system, and there can be a lot of computer sub-systems. When it comes to UAVs or autonomous vehicles, emphasis is usually placed on the payload processing. That is: a COTS computer that interfaces to the platform’s sensor suite. But often we find that the horsepower, weight and/or available power often exceeds what’s available on the airframe—that’s usually the reason the customer came to us in the first place. They had no idea how to solve the simultaneous equations for these three vectors.
|Avionics/Airframe (flight controls)||Airspeed, data|
|Inertial measurement unit|
|Compass, magnetometer, accelerometer|
|Payload (sensors, in-bird processing)||Electro-optical|
|Radar (SAR, phased, sidescan, etc)|
|Weapons (for armed UAVs/UAS)|
Fire control computer
Individual computers embedded in weapons
Table 1: Notional sub-systems of an offensive, armed UAV such as an Air Force MQ-1B Predator. Sensor-only UAVs omit the weapons sub-system components.
Instead, we expand the discussion beyond what was asked—the payload processing—to include their on-platform communications backbone, the mission processor, the avionics suite, or any other electronics that we can subsume into our system to meet those vectors of horsepower, weight, or power.
In summary: it’s important to look at the whole system, not just what the customer is asking about immediately. This approach is our standard step-by-step process, and it works well for our customers because we often give them more than they expected.
SWaP-C Reigns Supreme When Considering I/O And Processing Requirements Despite the promise of bigger DoD budgets, the reality is that all branches operating UAVs/UAS are forced to trade off new COTS programs with O&M requirements (“boots, beans, bullets”—plus health care). It remains essential to balance all of these with lowest cost.
Yet we are seeing more willingness to take purely leading-edge commercial technologies and field them if they meet the requirements. We’ve had a customer inquire about embedding a standard smart phone within one of our small form factor boxes, simply because the perception was that the phone met the requirements for LTE cellular, image processing, storage, and low cost. We couldn’t do that, of course, but the message was clear: processing high-res images from megapixel cameras and other IR sensors, civilian connectivity via Wi-Fi and cellular, and “cheap” storage.
“We expand the discussion beyond what was asked—the payload processing—to include on-platform communications backbone, the mission processor, the avionics suite, or any other electronics that we can subsume into our system to meet those vectors of horsepower, weight, or power.”
As well, there’s an equal need for better image resolution from the sensor, plus in-airframe image processing. This means increased emphasis on intermediate processing and the ability to move data to on-platform storage. Where once 1GbE was used, we’re shipping a lot more 10GbE interconnects. To meet the storage requirements, smaller SSDs are needed in M.2 format instead of the “traditional” U.2 (2.5-inch) sizes (Figure 2).
We’ve standardized on the PCIe Gen 3 interconnect for inter-board communications and all the way out to the drives, which are now more commonly NVMe instead of SATA. This also has the advantage of reducing latency as Intel CPUs (like Xeon D) and PCHs offer myriad PCIe Gen 3 I/O which can talk directly to the NVMe drives.
Look At The Whole System For Revolutionary—Rather Than Evolutionary—Approaches The issue that doesn’t get the right attention is how the customer asks for a specific solution. This is a function of how a whole program flows down from the government’s requirements and a prime- or sub-contractor goes out to ask the industry for bids. They usually specify what they want, and it’s typically an “evolutionary” improvement over what they already have or already believe is possible.
Yet as Steve Jobs of Apple famously requoted from someone wise: Your customers are asking for something but they don’t even know what they want. Stop listening to them. By asking for evolutionary system technologies and improvements, the UAV is constrained to missing out on the revolutionary advances the suppliers—like GMS—can offer. (For more on this, refer to Ben Sharfi’s blog “President Trump: We’re Wasting Taxpayers’ Money.”) Don’t ask us for a faster sensor processor; instead, ask us for a way to recognize image changes or for a way to predict the probability that the burned-out truck by the side of the road might have been moved since the last time it was imaged. This could signal the existence of an IED (Figure 3).
If this linear thinking—which is just fine, but inefficient—isn’t solved, our systems will not keep pace with the enemy’s way of capitalizing on civilian technology and adapting it to fight against us. Their modified smartphone is way more powerful than most systems we can bring online today—that’s because we will use that same civilian technology but it’ll take us several years to adapt it to a defense environment. By then, several civilian generations have come and gone, always leaving us a generation or two out-of-synch.
Instead, we need non-linear, or what Admiral Harris (USPACOM) calls “revolutionary thinking.” Take us into your confidence, tell us the complete problem and let select industry partners like GMS come up with the best way to solve the problem. Don’t just ask us to bid on your definition of what you think is the best way to solve the problem.
If we fail to keep op-tempo with the enemy’s technology, we’ll have to fight with overwhelming force to stay even. We can’t afford to do that on so many fronts.
The original interview on which this article is based is available here.