By Robbin Laird
With the coming of the P-8/Triton dyad the U.S. Navy is paving a way ahead for collaborative concepts of operations between manned and remotely piloted aircraft operating in the Pacific.
But also, the US Navy’s MPR community is working man-machine teaming with regard to its P-8 as well.
Man-machine teaming is a key part of the way ahead for the P-8 as a software upgradeable aircraft, as well as being part of reworking decision making onboard the aircraft as well.
Although much of the focus on artificial intelligence is upon its future within autonomous systems, a real-world use which is evident in the MPR community is the evolution of decision aids through automating repetitive action tasks.
I had a chance to discuss these developments during my visit to Jax Navy with Lt. Sean Lavelle, a key player in the effort on man-machine teaming in the MPR community.
In an earlier piece, I highlighted the context within which Lt. Lavelle’s work was unfolding.
And in that article, I highlighted the discussion which Lt. Lavelle had in a podcast with Eric Lofgren.
According to Lofgren:
I was pleased to speak with Navy Lieutenant Sean Lavelle on the Acquisition Talk podcast. He is the founder and lead of the iLoc development team, which rapidly deploys valuable software capabilities to the Navy’s P-8 fleet. During the episode, Sean describes how P-8 aviators took it upon themselves to code new applications that could solve hard problems with software rather than pencil and paper. One application reduced reporting errors by 90 percent.
Sean provides a compelling vision of the future where operators also take on duties as software developers or product managers.
This doesn’t require everyone to have coding skills. The P-8A’s organic software team only has six rotating developers. Sean argues it is better to have many users involved in defining the business logic with a small team of software developers rather than a large software team with little access to user input.
The result is a continuous process where knowledge from the military operators can quickly get embodied in software and deployed to the entire fleet. Sean calls this “software-defined tactics,” and it’s a compelling concept indeed.
One of the many benefits is that it decreases the burden of training as operators are constantly involved in small changes. This is in contrast to the large and infrequent software drops from contractors, where increased capability often comes at the expense of increased complexity. It usually takes 3 or 4 years, for example, to train a P-8 tactical coordinator.
However, with the iLoc tools, a trainee of 6 months can reach a level of proficiency that used to take two or more years. Agile in-house software development vastly decreases complexity at the same time in generates new capabilities, allowing the U.S. military to scale much more rapidly in the event of conflict with a great power.
In that article, I highlighted importance of the kill web approach to provide for transient software advantage as conceptualized in the featured graphic above.
After writing that article, I spoke with Lt. Lavelle who explained how he saw the relationship of transient software advantage to a kill web versus kill chain approach.
Software-defined tactics are the key to quickly adding capabilities to different assets that are supposed to work together. It’s kill chain vs kill web for acquisitions.
In the kill chain – you devise a new weapon for a shooter, then figure out the sensor you need for the ISR node, then you figure out the network that makes the most sense for data transmission, then you write the messages you’ll send from sensor to shooter. After that, you have to try to sequence all the capabilities so that they arrive roughly at the same time.
Then when you add a sensor or a weapon, you have to teach the sensor asset what the new weapon brings to the table, or vice versa, and how they can maximize it. It’s hard for a community to get good at operating their own new sensors or weapons. It’s harder to get good at helping another community employ their capabilities.
All of that adds so much time to acquiring and fielding new capabilities, so you end up buying weapons and sensors much slower than the pace of what is technologically possible.
In the kill web – you buy whatever improves your capability as a sensor or a shooter. Period. If there isn’t a perfect network to transmit information right away, it’s okay. Just write a software-defined tactics application that can leverage information from a basic data-link, has some basic modeling assumptions, and can give the task force a good, ad hoc plan that gets to a local maximum solution. The force can figure out the absolute best way to work together as they experiment, we just need an acceptable way to work together that can get the ball rolling.
We actually just did this for a new sensor/weapon combination in less than 20 hours of software development. The application we fielded solved the entire coordination problem for a completely new concept and optimized the sensor/shooter team. It lets the sensor act as a cloud processing node for the team, even if the human in the sensor aircraft isn’t really an expert in what the shooter brings to the table.
This process means the limiting factor in technology adoption is not the acquisitions process as is typical, but the actual science.
During my visit to Jax navy the week of June 14, 2020, I finally met Lt. Lavelle and to discuss with him the way ahead with regard to the man-machine software redesign dynamic.
Lt. Lavelle is part of the Weapons School and an officer working the kill web capabilities of the force.
The basic software upgrade dynamic operates around block upgrades which are planned long in advance.
He explained: “The ideal acquisitions process is to conduct operations, learn from those operations and then decide what we want to buy based on that experience. The paradigm that the FAR forces us into doesn’t always lend itself to that sort of iterative, learning-oriented acquisitions process.”
He then noted that to break that paradigm, they were focusing on a different approach to software upgradeability.
As he explained: “Rather than trying to fix the entire contracting process, we are focused on finding ways to in-house talent to get more rapid software upgrades driven by operational experience.
“We want a tighter coupling of operations and software development than is really possible with current acquisitions regulations.”
They are focusing on ways to in-house software development under PMA-290, the Program Office for the P-8.
Within PMA-290 is an office called the Software Support Activity, which Lt. Lavelle and his team work with.
There they are focused on building a system on the P-8 where mission system data, including data links, and information generated by the sensor networks goes to the “sandbox” which is a secure computing environment that can take data, process it and generate decision making recommendations for the operator or alert them to tactical problems.
It does not directly push data to the aircraft, so it is divorced from safety of flight software considerations.
According to Lt. Lavelle: “This allows us to push updates to the sandbox on timescales measured in days or weeks, rather than years.
“The Weapons School is building the software for the sandbox based on operators’ experiences, while the traditional acquisitions enterprise builds the infrastructure to allow that development.
“The process is that we observe the fleet’s problems, we write code to solve those problems, send the finished application to PMA-290, they do a security analysis and then they push it back to be integrated onto the aircraft.
“We are funding this process operationally rather than on a project basis. We have four to six people at the weapons school at any one time who are trained to write software for the sandbox.
How does he view the impact and outcome?
“The way I think about it is, we’re changing the learning cycle for a force.
“Right now when we identify a solution to a tactical problem, we allocate training effort to teach the fleet how to implement it.
“About 5% of that effort goes toward teaching operators the theory around the solution and how to implement it.
“The remaining 95% goes toward continuous training to retain currency. If you have to practice a technique in two simulator events per year to retain currency, which is an underestimate for most techniques, you’re looking at 8,000 man-hours per year given the roughly 1,000 operators we have in our force and 4-hour simulator events.
“That’s a huge amount of resources and the end result is that we are just good at the basics and never really advanced anything because it’s sort of a treadmill.
“You need to spend all of your time maintaining basic skills. Adding new skills just requires too many additional resources.
“With the new approach, we find a problem, we still do the initial effort to teach the fleet the theory, but then we write a piece of software that alerts the operator when that problem is presenting itself and gives them in-situ tactical recommendations.
“It is much easier to stay proficient at a task if a machine is helping identify problems and recommending a set of reasonable solutions the human can choose from.
“Instead of 8,000 man-hours per year, each individual might only need to practice a technique every other year, meaning we save 75% of the effort we would have spent and can add 4 times more new skills per year.
“We’ve already executed this new approach with several tactical problems.
“In one case, we reduced failures in a particular scenario from 20% of instances to less than 1%.
“Rather than a treadmill where we’re constantly teaching the basics, we can have a baseline level that’s of performance that’s very easily maintained.
“And then we can advance from there much more quickly.”
In short, part of the innovation being done in the MPR community is about reaching towards a much more rapid process of software upgradeability and integrability for the distributed force.