Ruggedization should be tailored to the environment and to users.
Defense computing systems need to operate in a highly disparate range of environments. Depending on the program’s requirements, ruggedness is a function of the environment each system will be deployed in. A system that operates just fine in a pressurized aerospace application, such as a wide-bodied aircraft, may have issues in a marine application, and may be completely unacceptable in a vehicle being driven through a hot and sandy desert. Even within airborne applications, the environment might be a wing-mounted pod that is completely unpressurized. Computing systems for each of these environments must be ruggedized to match requirements.
Insourcing can enhance the government-industry partnership.
I have an entirely new appreciation for the U.S. Army. On a recent project, service officials broke the government’s often too-slow acquisition model, and instead worked together with us, the contractor, to define its needs, develop the right hardware and software, and then support the Army’s internal development and integration. This experience represents a significant change in the Army’s typical way of doing business, and it taught us both a few lessons.
For many military applications, the ability to secure-erase (“zeroize”) flash memory and SSDs is a critical element to protecting classified information such as data, crypto keys, or software programs from falling into enemy hands. But the wide variance among flash drives means that each implementation of security commands must be individually tested before it can be trusted to properly sanitize the drive.
Does Secure Erase Actually Work?
In 2001, a Chinese fighter jet attempting an intercept collided with a US Navy EP-3 SIGINT aircraft. The EP-3 was forced to make an emergency landing on China-controlled Hainan, giving unauthorized access to classified US equipment, data, algorithms, and crypto keys. The Navy crew had 26 minutes to destroy sensitive equipment and data while in the air—using a fire axe, hot coffee, and other methods—plus another 15 minutes on the ground, but their efforts were widely reported to be only partially successful.
In many ways, battlefield networks architecturally resemble a typical LAN/WAN, but the broader battlefield is far from a typical environment. The big difference is that platforms are on the move, so they must connect using RF technologies rather than wire or fiber. And that’s where things get tricky.
In many ways, battlefield networks architecturally resemble a typical LAN/WAN office or enterprise environment (Figure 1). There are end-point nodes—typically a vehicle, UAV, airplane, or even a dismounted soldier—which are rolled up into clusters (subnets) and inter-connected via battlefield routers. Communication is managed via IPv4/IPv6 for data, voice, and video, and the networks use flow control and typical terrestrial routing protocols just like the world’s Internet.
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.
Military procurement processes are costing taxpayers and getting in the way of progress.
While I might not go so far as to pen an open letter to President Donald Trump, consider this a note for anyone with a need to know how the procurement process works for defining and moving ahead on military expenditures. It’s safe to say the behemoth process borders on the absurd and wastes millions of taxpayer dollars.
Being able to replace damaged modules while at sea or swap functions at the LRU level adds a whole new meaning to “SWaP-C.
When you’re tasked with maintaining technology on the battlefield or similar arduous environment, options are a good thing—usually. When your option is to pull a complete system and send it out for repair, well that’s likely not the best alternative, although that’s what regularly occurs. When your option is to swap in a new subsystem for a faulty one with a limited amount of reconfiguration, you’re likely going to take advantage of that option
That “standard” you’re buying has some issues, and it carries a lot of extra baggage. For new designs, it’s time to look at more up-to-date, modular alternatives.
By most engineers’ definition of a board standard, a customer should be able to remove a CPU board from a box and replace it with another CPU board—regardless of the manufacturer—and have it come up and running with fairly minimal effort.
Open standards are easy to love. With a common, defined computing system, anybody can port their applications to them and the software syncs beautifully, simplifying upgrades and providing flexibility in customers’ choice of supplier.
One U.S. Army crack at open standards provides a good example of the expectation, which was to correct the problems created by the bolted-on approach of field equipment on vehicles. Unfortunately, like far too many of such standards, the Vehicular Integration for C4ISR/EW Interoperability, or VICTORY, falls flat on implementation.
The U.S. Army is upgrading, recapitalizing and redeploying materiel, with electronics a key part of the process.
It seems like a simple choice. You need to upgrade a platform’s computing capabilities—whether on a ground vehicle, a fast-delivery ship, a signal’s intelligence airplane or in a server room—but some of the existing hardware still is salvageable. Rather than do a complete upgrade from scratch, it is possible to leverage much of the existing technology and retain existing racks, power supplies and mass storage in the retrofit.
We’re processor-agnostic, but Intel’s processor evolution and upgrade path is superior to ARM. Customers can count on smooth longevity and lifecycle.
For a long time, General Micro Systems (GMS) prided itself on being “processor independent.” We weren’t an Intel house or a Motorola house or a SPARC house. We would design our products to operate with every major processor that was out there. We were processor-agnostic; we didn’t care which one!