What Happened to the Pentagon’s Formation-Flying Satellite?

<em>Art: DARPA</em>

Art: DARPA

by DAVID AXE

The U.S. military has cancelled a seven-year, $200-million effort to develop a new kind of satellite — one comprising groups of small, formation-flying craft orbiting in tight-knit formations and sharing data wirelessly.

The Future, Fast, Flexible, Fractionated Free-Flying Spacecraft, or F6, was overseen by the Defense Advanced Research Projects Agency, or DARPA, and featured an unusual program structure that probably contributed to its demise. Offiziere.ch spoke to one space-industry insider with insight into F6’s promise and problems. “It was a good idea to can F6,” the insider says.

F6 was meant to offer an alternative to today’s big, expensive, single-piece satellites, which can tip the scales at 10-tons mass and $1 billion or more in acquisition costs. The F6 concept envisioned several smaller, cheaper, self-contained satellites, each performing a few narrow tasks, orbiting in close formation and communicating with each other via datalink to form a sort of “aggregated” multimission spacecraft. In theory, an aggregated satellite is more resilient that a monolithic one, as it can lose some of its components and still function.

The concept was sound but the program management was not. Instead of paying an aerospace company to integrate the technologies being developed by small firms and university teams, DARPA decided to perform integration on its own — an unusual arrangement in the world of military acquisition.

A first test flight was slated for 2015, but DARPA recently ended the program after a review of programs this year. “It was a reach to use DARPA as the integrator, given the competitiveness of university programs,” the space insider explains.

Partially as a result of the poor management, the software needed to control the aggregated spacecraft advanced more slowly than the hardware components, in the inside adds. “Software groups in aerospace are small and often take longer than the hardware takes to assemble and test. Add to the problem that they are often picked off by the IT industry for twice the money or for a competing program, and that there are no shortcuts for bleeding edge developers of code.”

Bottom line, “the software is always late and full of holes.”

It’s possible DARPA realized early on that its integration effort would not work — and kept F6 going in the hope that some useful technologies would emerge from the program even if the main aggregated spacecraft failed. “They kept the universities busy and hoped for some technology carry-overs, hence the $200-million-plus expenditure.”

The good news is that some components, and even some bits of software, indeed appear likely to survive F6’s cancellation. So the years and hundreds of millions of dollars weren’t a total waste.

This entry was posted in David Axe, English.

1 Response to What Happened to the Pentagon’s Formation-Flying Satellite?

  1. Mark S says:

    There are many problems with building complex software systems, even when it is a well understood problem and it is just a matter of doing it.

    Software is a lot of work. Even if you can hack together a proof of concept or a demonstration, there is still a substantial amount of work to build a system that responds to real-world contingencies. Managers need to recognize that and not lowball their estimates just to land the contract, and contracting officers need to recognize when a vendor has lowballed their software estimates and refuse to reward unreasonable bids. Under-staffing your software project is a recipe for failure.

    We all know that the software industry has high turnover, driven not just by higher salaries, but also by engineers leaving because of the effects of poor management. Therefore, any reasonable software estimate must include the costs and lost time caused by turnover. This also points to higher staffing levels so you are not totally screwed when someone does leave the job and you have nobody on staff who cover it until you hire a replacement.

    A lot of software products I have had contact with were full of holes, but not just because they were understaffed. Not all software engineers are excellent at what they do. Many projects are staffed with people of minimal skill in software engineering. “I can write a simple program” is not the same as “I am a great software engineer”, but as the demand for software has grown so greatly, the lines are blurred as the jobs are filled by whoever we can get to do them. Sturgeon’s Law applies: 90% of everything is crap.

    The software doesn’t have to be “late and full of holes”, but it will be if you don’t realistically assess the costs and schedules, and treat software as a serious engineering task like any other.

Leave a Reply

Your email address will not be published. Required fields are marked *