Electronics Technician 3rd Class Brent Vigil, from San Diego, runs diagnostic testing on an antenna aboard the Ticonderoga-class guided-missile cruiser USS Lake Erie (CG-70) during a replenishment-at-sea. US Navy Photo
SAN DIEGO – The Navy’s chief engineer thinks the Navy could make better use of ship-readiness data if the service could adopt a faster process to write and field software, and he’s eyeing the upcoming launch of a new readiness-monitoring system as an opportunity to be more agile in software development.
Rear Adm. Lorin Selby said the Navy is pushing out an Enterprise Remote Monitoring sensor system that will capture data on how engines, turbines and other hull, mechanical and electrical systems are performing on a ship. But that data is only as good as the Navy’s ability to crunch it and use it to make decisions about ship maintenance, and Selby said he’s “all in” on a faster way to generate questions and then write software code to mine the data for answers.
In the airline industry, for example, Selby said that “any plane you fly on today, there’s sensors on the engines, they’re talking to the ground, passing all kinds of parameter data from the engine. And they have environmental data – temperatures, altitudes, pressures – and they have actual performance data from the engines, power output, fuel inputs, the pressures and flows. All that. And it goes to the ground. And it’s being analyzed by algorithms that are looking for anomalous behavior.”
Selby, speaking on Aug. 9 at the American Society of Naval Engineers’ annual Fleet Maintenance and Modernization Symposium, said apps can compare actual system performance data with the ideal performance data – as determined by a virtual twin of the system running on the ground – and when an engine starts running too hot, for example, the app could suggest to pilots and maintainers on the ground that there might be a lube oil leak.
The launch of the Enterprise Remote Monitoring system – which a destroyer tested out earlier this year – will provide the performance data. Now, Selby said, he needs to start working on the apps to leverage that data and gain an understanding of whether the systems are functioning correctly, if they’ll need maintenance actions soon, if the operators could use them more efficiently, and so on.
There’s any number of ways that data from the Enterprise Remote Monitoring system could be crunched and contribute to readiness at sea and condition-based maintenance back ashore, both at an individual ship and a class-wide level. Different apps would be developed with algorithms to look at specific aspects of HM&E system performance, Selby said, and that’s where the “DevOps” model of continuous development, testing, fielding, monitoring, and improving software products comes in.
Industry has figured out how to write, validate and push out software updates for apps very rapidly in response to a cyberattack, an operating system update or other event that forces them to act or lose customers. The Navy can’t react that quickly under its current systems engineering model, but Selby said that he wants to change the mindset to one of continuous improvement, mirroring the DevOps model in the tech industry today.
“They’re continually developing software, testing it, releasing it, deploying it. You operate with it some, you monitor it, you learn things from it, you go back and change again. And that’s a continuous process,” he said in a keynote speech on Aug. 9.
“This makes a lot of folks uncomfortable; we’re not used to it. I’m conflicted – as the chief engineer of the Navy, I like things I can predict, things I can go test rigorously and get … the data proving, yes, that’s going to work. And then there’s the other side of me that loves this new stuff.”
Selby acknowledged that it would be a challenge for the Navy to push out software updates and new apps rapidly while also ensuring that the software would not harm ships and their ability to conduct real-world operations. But he’s looking to the Submarine Warfare Federated Tactical Systems (SWFTS) model as inspiration and said he hopes he can take that two-year process and speed it up.
Today, the training and tactical development teams at U.S. Fleet Forces Command and U.S. Pacific Fleet meet a few times a year with acquisition program offices to talk about combat systems and what additional capability the fleet needs from them as operations evolve. Sometimes the fleet needs enhancements in how sonar data is processed, and sometimes they ask for more complex things like software to integrate their combat systems with new torpedoes. The Submarine Tactical Requirements Group defines the next batch of requirements, which are signed out by the commander of Submarine Forces and then handed over to Naval Sea Systems Command to work, Selby explained.
NAVSEA and the relevant program executive offices work with industry to solicit and review white papers. Some applicants are invited to participate in a lab demonstration of their software solutions, and typically one is selected to put their software on a submarine at sea for further testing. The software is either productionized, tweaked or rejected based on the at-sea tests.
“I want to do the same kind of concept, where I’ll be able to have a requirements board validate the requirement, announce it, have industry give us white papers, downselect,” Selby said of his concept for generating and improving HM&E readiness apps.
“Ideally, the first ones I want to try to do are [Naval Surface Warfare Center Philadelphia Division] kinds of things … which is mostly your reduction gears, your turbines. … Once I prove (the concept) on HM&E components and get this thing kind of going, get the production line going, then I want to scale up to other things – and I’m talking things like weapons systems.”
Selby said he thought it was “safer” to start with HM&E systems as the Navy works out its process of writing, pushing out and monitoring software updates. Though the Enterprise Remote Monitoring sensor system was turned off after its testing on an unidentified destroyer earlier this year, Selby said he’s pushing to get the system turned back on within the next month or so, so his team can start collecting data and laying the groundwork for app development to make the most of the data being generated.
Naval Information Warfare Systems Command – formerly SPAWAR – has a Compile to Combat in 24 Hours effort going to field updates for information technology on ships at sea with a similar goal as his effort, Selby noted, but the two efforts are unrelated at this time.
The Program Executive Office for Integrated Warfare Systems also has a virtual Aegis Combat System for testing out software updates. Selby said he’s not working with PEO IWS yet, but “I think there’s a marriage for these two things at some point in the hopefully not too distant future,” if he can perfect the software pushes to ships at sea and provide that as a way to send combat system updates as well.
