The combined entity has gotten off to a strong start, said COL Michael Thurston, PM, Mission Command. “We have created some great efficiencies over the past year not only in contracting but also system engineering and development, and we are really looking forward to the common operating environment and how we can make our systems more capable and easy to use for the soldiers,” he said.

Watch the Video Roundtable at C4ISRNET.com/missioncommand

Thurston spoke at a C4ISR & Networks video roundtable, joined by several members of his team: LTC Michael Olmstead, PdM, Joint Battle Command-Platform; LTC Shane Taylor, PdM, Tactical Mission Command; and LTC Timothy Gearhart, PdM, Strategic Mission Command.

At its heart, PM Mission Command focuses on the warfighter experience and the need to simplify systems usage on the ground, said Olmstead of Joint Battle Command-Platform (JBC-P).

“One of the things we really focused on for JBC-P is the intuitiveness and the user interface that the operator sees, the ability to clear out the screen, declutter the screen,” Olmstead said. “They turn on the system, it works. It’s easy to use. It’s intuitive. They don’t have to go through multiple menu instructions to find that they need.”

Planners want to improve systems in part by opening up development on the commonly available Android platform. That makes it possible for a wider range of developers to create software solutions. In the meantime, Olmstead is turning to end users for further input. “We are looking to get as much feedback as we can,” he said.

The effort to forge simplified, common usage scenarios goes beyond the immediate needs of soldiers on the ground. As the Army operates on the international front, it also is seeking global command and control systems that will allow optimum interoperability with coalition command, said Gearhart.

In an ideal system, each partner would be able to populate one another’s data sets with relative ease. A user group of 27 nations already meets quarterly to achieve that end. “We make sure that all of our systems will interoperate, we follow the same architecture standards,” Gearhart said. The ability to leverage such data could give commanders in the field greater options, he said. But there are challenges to getting there. For example, any system will have to include comprehensive storing and labeling capabilities to indicate classifications and what can be released.

As planners consider issues of interoperability and data sharing on the front lines, they also are looking for ways in which commanders may be most readily able to access that data for use in real time.

The PM Mission Command team has another task at hand: the development of the “command post of the future,” as Tactical Mission Command’s Taylor described it. In the past 10 years, the Army has fielded some 20,000 systems. Now it is time to migrate tactical applications and new capabilities onto a common framework.

This merging of information will create an opportunity to port data across common user interfaces, to ensure users share the same picture regardless of their places in the user chain. The Army won’t be able to make that happen on its own.

“There are certainly new technologies coming out every day to help us,” Taylor said. “We want to be able to work with industry to come up with designs that allow us the most flexibility, the most modularity, so that as industry comes out with a new capability, we will have the ability to rapidly integrate that into our existing framework.”

Earlier this summer, Army PEO C3T folded Project Manager Joint Battle Command-Platform into PM Mission Command. JBC-P is the next-generation Blue Force Tracker (BFT) system and seems a natural fit in the PM MC area of responsibility for developing, deploying and sustaining integrated mission command and situational awareness capabilities. COL Michael Thurston, formerly the JBC-P project manager, assumed the charter for PM MC in late May, and he spoke to C4ISR & Networks Editor Barry Rosenberg about network simplification, the Mounted Family of Computing Systems (MFoCS), and tactical apps.

With support of the war fighter a given, what’s at the top of your to-do list?

One that is pervasive across all the products and efforts is simplification. We are really trying to simplify everything from the soldiers’ experience … what the user interface is like for soldiers from the system configuration and network administration experience, to what it takes to keep these systems operating in the field. One of the things that we are doing with the Mounted Computing Environment, for example, is creating one developmental environment where we can collaborate among industry, government agencies, science and technology, and program offices so we can share experiences and knowledge and have technologies, applications and capabilities developed quicker and at the right standard so they are easier to integrate, test and field.

What are some other specifics on simplification, maybe related to JBC-P, the program you managed before it was folded into PM MC?

In JBC-P we started several years ago on the simplification. The user turns the system on, it connects to a satellite transceiver, the user has to take no action to connect the network, the unit has to take no action to manage the network, and it is all managed here at APG by the program office.

For the JBC-P software, the interface was developed with user feedback. It used to be a multitiered menu structure like you would expect when Windows first came out. [Based on user feedback it became] a much more intuitive user interface where, for example, you can click on a blue icon and can immediately message that individual. You can get all the information that you need about that individual instead of having to go through several menus and selecting that name.

What systems still need work in the area of simplification and interoperability?

We have a long way to go in the command post environment to make that simpler. And even JBC-P has its challenges in interoperability with the command post systems. Our systems are technically interoperable, but there are some limitations. It requires the user to know what those limitations are. We need to do better at that. We need to make it so the user does not need to know what works on CPOF [Command Post of the Future] and what can’t be sent to JBC-P. The system should figure that out for them.We are trying to make those applications easy to use, with a more intuitive interface, with common maps and services across all the war-fighting functions — but also more robust and interoperable so the soldier does not have to know all the quirks of each system to be able to make it work altogether.

Traditionally there have been barriers that existed between mounted computing environments and command post computing environments. How are you breaking that down barrier by developing common platforms on which the applications for the various environments sit on top?

One of the things we are doing in the mounted computing environment is creating an Android framework that sits on top of JBC-P. Really it is a JBC-P application sitting on an MFoCS computer. When we add an Android framework on top of that I can now host additional applications on that computer to give it mission command capability. One of those things that we added was a capability called TIGR, Tactical Ground Reporting System. So we took some of the best in breed in this TIGR application, which was a command post system built into the JBC-P application. We are using the TIGR capability that allows you to synchronize information across all platforms and command posts, along with the CPOF synchronization mechanism, [to develop] unified data for the Command Post Computing Environment.

The whole principle of unified data is that all are using and sharing the common data. So if AFATDS [Advanced Field Artillery Tactical Data System, a fire support C2 system] brings in a piece of information, that can be used for CPOF or an intel system. You get that fusion of intel and ops data in one unified database. We have to synchronize that data. All that data is sitting in a brigade server; I do not want to replicate the data periodically onto another brigade server or a division server. I just want to be able to update and synchronize those pieces of information that are important to those users at those locations. So this TIGR synch mechanism is going to be very useful in a command post computing environment.

Even though we work in the same building and work closely together between mission command and JBC-P, we would not have had the engineers sitting around the table as closely as we do in this merged organization to be able to figure these things out. So that is just one example of where we are seeing synergies and sharing technologies so they can be reused elsewhere.

You mentioned MFoCS. Are you installing hardware in vehicles at this point?

Absolutely. MFoCS was a direct requirement from the G3 for the mounted environment to provide a computing platform to reside on vehicles to be able to bring in additional applications beyond JBC-P and create that intra-vehicle communication and interface system — interface with sensors, interface with vehicle, eventually we are going to interface with vehicle diagnostics and information, ammunition and fuel information. We are working with the various vehicle developers to expand on the capabilities that MFoCS provides for that intra-vehicle communications and displaying environment.

PM Army Battle Command System has adopted MFoCS as the primary computer that is going to host on all the heavy platforms: Bradley, Abrams and Paladin vehicles. They are all going to have MFoCS computers running on them. We took MFoCS to the last NIE 14.2. It was a follow-on test and evaluation for JBC-P, but we inserted the new MFoCS hardware — the basic and intermediate versions of the MFoCS hardware — into that test, and had a successful test. And we are looking forward to fielding MFoCS as part of JBC-P fielding in the first quarter of fiscal 2015. We just have to achieve a materiel release for this latest software, and we will start fielding these systems to our first unit equipped in the January time frame.

What will PM MC be evaluating at NIE 15.1 this fall?

Obviously WIN-T is taking a priority for good reason at this event. But we are not off the hook. We have a system under evaluation for MACE, the Mounted Android Computing Environment. MACE is a technology that takes JBC-P and puts an enterprise framework on it. But that doesn’t do anything for you unless you host an application on it. It’s like having an Android phone with no apps. MACE creates that Android framework, and we want to demonstrate some applications.

One of the first applications we are going to bring to this NIE is an application called ODIN, which stands for On Demand Information Network. It was developed in house here at APG by the PM Tactical Radios team, as well as CERDEC. The best way to describe ODIN is basically comparing it to what your iPhone does with just a few clicks when it picks up the available Wi-Fi when you walk into a hotel lobby. We say three clicks, three minutes where you can actually reconfigure your system.

So in the tactical space we have systems out there that run on the SRW waveform: the Manpack and the Rifleman radio. So unless you have all the networks that you want to operate in one of the [radio] presets, you may come across a unit that is not in your task organization and not have their network loaded. What ODIN does in cooperation with JBC-P and the Joint Enterprise Network Manager capability is share information across the BFT2 network about radio networks that are out there. It allows us to reconfigure that radio on the fly with just a few clicks so you can enter that radio net. So what used to take days or even weeks to configure a network that wasn’t in one of your planned network presets, we can now do that in a matter of minutes. So it is really an exciting capability. It is the first time we are going to be evaluating that at NIE 15.1. And the intent is to bring that back with several new applications as an operational test probably in the 16.1 timeframe.