Thursday, November 19, 2009

Guest blog: Navy demonstrates value of military cloud computing during recent naval exercise

By Kevin Jackson

In October as part of the U.S. Navy's annual Trident Warrior exercise, Dataline LLC demonstrated that a standard shipboard communications infrastructure could be used to manage a commercial cloud computing infrastructure as a service (IaaS) platform.

Presented during the fall Trident Warrior '10 (TW '10) lab period, Dataline's secure cloud computing experiment used a simulated shipboard infrastructure to demonstrate secure access to selected collaboration and geospatial information service (GIS) applications. The purpose was to validate the ability of a commercial Infrastructure as a Service (IaaS) platform to support Navy requirements for military cloud computing in terms of global connectivity, server failover, and application access.

For this portion of the exercise, Dataline used the Amazon EC2 IaaS platform. The experiment also used SecureParser as part of the Unisys Stealth architecture to provide data-in-motion security. Dataline also used included Oracle Beehive, ERDAS Apollo and the Joint Forces Command (JFCOM) developed Transverse collaboration suite.

Navy Lt. Cmdr. Caroline Lahman, the officer in charge of Navy FORCEnet San Diego, says she was pleased with the results, and says she wants to continue these cloud computing experiments as part of the spring lab period. Cloud computing typically involves dynamically scalable and often virtualized computer hardward and software resources as a service over the Internet.

Robert Carey, Navy Chief Information Officer, also says that cloud computing offered real value to the Navy. Citing that the Navy Next Generation Enterprise Network (NGEN) and Consolidated Afloat Networks and Enterprise Services (CANES) programs will use cloud computing, he envisions a future day when gray clouds within a ship's hull would eventually switch to clouds within the battle group.

The increased IT efficiency delivered through cloud computing also would make more resources available for investment into Navy ships and aircraft. Carey says he sees ready access to authoritative data from the cloud as an important enabler to a real-time/near real-time decision making process, saying that the cloud delivers the ability to have a ubiquitous computing environment and interoperability.

After observing the experiment, representatives from the U.S. Space and Naval Warfare Systems Command in San Diego voiced similar sentiments, saying that the Navy is considering cloud computing technologies as part of its Naval Networks Enterprise-2016 strategy.

Trident Warrior '10 is scheduled to continue with a second lab period in the spring 2010 and an at sea demonstration period after that. For further information on the Trident Warrior lab based experiments, contact Lt. Cmdr. Caroline Lahman by e-mail at

Kevin Jackson is a vice president at cloud computing specialist Dataline LLC in Norfolk, Va., and is retired from the U.S. Navy, where he served with the National Reconnaissance Office, Operational Support Office, providing tactical support to Navy and Marine Corps forces worldwide. His "Cloud Musings" blog at focuses on cloud computing.

Tuesday, November 17, 2009

Heat is buckling the flight decks of Navy ships; this looks like a job for the thermal management experts

Posted by John Keller

Every now and then I run across things that although they have little, if anything, to do with aerospace and defense electronics, still stop me in my tracks. Here's one I tripped over this morning: did you know the hot exhaust from the V-22 Osprey tiltrotor aircraft is buckling the flight decks of the Navy's big-deck amphibious assault ships?

I didn't either, but this phenomenon hasn't escaped the attention of thermal management materials experts at the U.S. Defense Advanced Research Agency (DARPA) in Arlington, Va. (story continues below video)

It seems the V-22 "has resulted in ship flight deck buckling that has been attributed to the excessive heat impact from engine exhaust plumes," according to a broad agency announcement (BAA-10-10) issued this week from the DARPA Strategic Technology Office.

I suppose Navy leaders could deal with hot gas plumes from the V-22; what really worries them, however, is the future deployment of the vertical-takeoff-and-landing (VTOL) versions of the future F-35 Joint Strike Fighter, which experts say could really cause some problems on the decks of aircraft carriers and the big-deck amphibs.

Too muck buckling caused by the V-22 and the F-35, and these flight decks are going to fail. DARPA has a nice way of explaining this.

"Navy studies have indicated that repeated deck buckling will likely cause deck failure before planned ship life. With the upcoming deployment of the F-35B Short Take Off and Vertical Landing (STOVL) Joint Strike Fighter (JSF), it is anticipated that the engine exhaust plumes may have a more severe thermo-mechanical impact on the non-skid surface and flight deck structure of ships," according to today's BAA.

Worse, nobody knows what to do about this problem, except to build new flight decks, which would be expensive, to say the last.

Instead, DARPA is looking around industry to see of anyone knows how to use thermal-management technologies and materials to build a non-skid, heat-resistant veneer that could fit over the flight decks of the carriers and amphibs to mitigate the effects of hot spots created by the exhaust from vertical-and-short-takeoff aircraft like the V-22 and F-35.

The primary candidates for this kind of thermally resistant flight deck applique are the Wasp- and America-class amphibious assault ships.

Okay, all you thermal-management experts: any takers out there? If so, drop an e-mail to DARPA at More information about this project is online at


Follow me on Twitter

Join the PennWell Aerospace and Defense Media Group on Linkedin at

Become a fan of Military & Aerospace Electronics on Facebook at

Post your aerospace and defense-related material to the #milaero community on Twitter. Use the #milaero hashtag.

Tuesday, November 10, 2009

Trends: another embedded software supplier snapped up by a computer hardware company

Posted by John Keller

Well, it's official: microprocessor hardware maker Cavium Networks is acquiring MontaVista Software. This is the second time in a year that a hardware company is acquiring an influential embedded software company.

You might remember last June when Intel bought Wind River Systems. We're seeing a trend here. In both instances, the hardware company is going after the software company to position itself for the lucrative handheld electronic device market. We can expect to see more of this in the coming year.

These acquisitions have kicked over the embedded systems anthill. Device manufacturers are scurrying for cover, and software companies are looking to reap the spoils. No one wants to be the one left standing when the music stops.

The software companies, in both instances, can say whatever they want about staying independent and supporting several different computer architectures. The fact is that Wind River for the last six months has been fighting to convince its customers that it won't eventually be swallowed up by Intel and disappear.

Meanwhile, Wind River's competitors gather at the bar and talk about how they're going to carve up Wind River's market share. MontaVista can expect to see the same.

This kind of thing happens in cycles. Hardware and software companies are looking to join forces in a down market to achieve the critical mass necessary to survive and grow.

I reckon they'll find, as companies have in the past, that bigger isn't necessarily better. As hardware companies buy up the software talent, they create an opportunity for the next wave of software technology developers. When the economy picks up, I suspect we'll see some new software providers emerge.

Some of these new software providers will prove to be vicious competitors, ready to devour their predecessors when the time is right.

MontaVista Chief Technology Officer James Reddy realizes this perhaps better than most. He led what was the leading real-time embedded software company 20 years ago. That company was called Reddy Systems.

When the economy went bad in the early '90s, Reddy Systems eventually lost its market share to a tenacious little software startup called Wind River Systems.

... and so it goes.


Follow me on Twitter

Join the PennWell Aerospace and Defense Media Group on Linkedin at

Become a fan of Military & Aerospace Electronics on Facebook at

Post your aerospace and defense-related material to the #milaero community on Twitter. Use the #milaero hashtag.

Wednesday, November 4, 2009


Posted by John McHale

Nearly everyone I speak to at avionics or defense trade shows or for interviews over the phone brings up the COTS (commercial-off-the-shelf) procurement term in some way. They make COTS products, use COTS practices, or think COTS is the worst thing in the world.

Nearly everyone I speak to at avionics and defense trade shows or for interviews over the phone brings up the COTS (commercial-off-the-shelf) procurement term in some way. They make COTS products, use COTS practices, or think COTS is the worst thing in the world.

Everyone seems to have different definitions or different acronyms for COTS. I've heard GOTS -- government-off-the-shelf; ROTS -- rugged-off-the-shelf; MOTS -- military-off-the-shelf; NOTS -- NATO-off-the-shelf; or my personal favorite: KOTS -- kinda-off-the-shelf. A few industry friends tell me they see a lot of SHOTS or "sh "-off-the-shelf. I'll let you fill in the rest ... we are a family web site ya know.

Seriously though, COTS is a procurement term that is supposed to embrace technology standards, but lacks any standard definition itself.

We like to think of COTS as being anything that is available out of a company catalog, even if it is tweaked or adjusted for a specific program. On the other hand custom would be anything that the government or end-user pays a supplier to develop from the ground up.

We've been talking about COTS for 15 years now. We've had shows about it and dedicated sections of our magazine to it, but many of our readers still differ on its meaning.

Some think the original intent of the Perry memo was to embrace commercial practices rather than a decree to run out and buy gadgets right off the shelf at Radio Shack or Fry's. In other words, to create standard product lines of MIL-STD components that can be bought off the shelf.

Many companies do offer such solutions, but just as many will buy a totally commercial component that does not meet military specifications and put it in a rugged enclosure.

Using COTS also cuts down on development time, which is very important to DOD program managers who want to get technology into the hands of the warfighter in Iraq or Afghanistan as fast as possible. DOD funding has been diverted from long-term programs to solutions that can be deployed near term to the warfighter.

Regardless, of how COTS is deployed or used, its dark side -- obsolecscne remains. No matter how you define it, designers still have to manage how they will support programs with components that will be obsolete in a few months or years.

Desginers of the avionics for the Orion spacecraft -- the proposed replacement for the space shuttle -- at Honeywell told me in January that managing obsolescene is one of their biggest challenges, but they cannot reach many of their performance golas without making use of COTS electronics and standards.

A decade and half after the Perry memo COTS has become a household word to those in the defense industry, it remains a kind of procurement wonder drug with wonderful benefits and occasionally some nasty side effects.

What does COTS mean to you? I would love to hear your COTS definition, your COTS success, or even a COTS horror story.

Follow me on Twitter