The following tale is a fictional account of representative events. Any resemblance to actual events, persons or organizations is completely unintended. Technical details presented in the storyline are available academically and publicly. No government or proprietary information is disclosed.
Lieutenant commander Luke Maxwell Ryan, USN, Retired was in a jolly good mood. His first day at work as a civilian could not have gone any better. The new-hire orientation had started at 9 AM, the typical “welcome to the family” and “you are here to change the world”. A lot of employment paperwork had almost bored Ryan to death. But, being a former naval aviator, he understood that working on a Secret government project came with rules and regulations, and paperwork – lots of it. The afternoon had gone a lot better, however. The CEO had stopped by at lunch to give the group of new employees a welcome speech. It was more eye-opening and inspiring than the typical HR hand-waving two hours ago.
Frontier Aeronautics was not a veteran defense contractor with a long track record. But according to the CEO, it did not bear the ill repute of being constantly over-cost and over-schedule like the big integrators either. The company had formally entered the defense industry five years ago as a sub-contractor to one of the big integrators. Frontier Aeronautics’ design and delivery of the Drone Master Command Module had been the only aspect of the USAF $1.0 trillion program that was on-time and under-cost. The company had been one of the first contractors to embrace and implement a full Digital Engineering framework. Every employee from the executive team to the custodial staff was incentivized to innovate. Their annual performance was evaluated solely on their ability to improve their product or task every six months.
Because of this forward-leaning culture, the U.S. Navy had invited the company to participate in a bid for the first-ever Drone-Control Flying Fortress. The program objective was to put a combat-drone command center onboard an electronic-warfare aircraft. The aircraft would be a twin-engine four-seat attack aircraft, similar to the EA-6B Prowler: one pilot, one mission commander, and two drone operators. The Flying Fortress would communicate with a swarm of armed drones through line-of-sight links. The manned-unmanned teaming squadron would be capable of air-air and air-ground/surface engagements.
The CEO’s vision for the company and the program resonated well with Ryan and his combat-veteran mindset. He finished his lunch, feeling very motivated. And by 1 PM on his first day at work, Ryan was more than ready to engineer the crap out of this aircraft.
Ryan was thrust right into his first work assignment; no company time was ever wasted at Frontier Aeronautics. By 1:05 PM, Ryan and his manager, Robert Fraser, were on their way to a meeting after only a brief introduction to his new cubicle.
“I know this may be a bit overwhelming on your first day, Luke. But Mission Management really wants a pilot’s opinion on their new computer reset function. You know, the constant innovation mantra,” Fraser grinned.
Fraser was an experienced engineer, and the head of the Model and Simulation Department. He had insisted on hiring a retired combat pilot to add real-world experience and operator’s perspective to his growing department. Ryan’s Navy experience fit the bill. The unwritten agreement with Program Management had been that Ryan would also help out with other departments’ user-experience discussions. Fraser had no issue with that arrangement. The better the connection between his department and the rest of Engineering, the better his models and sims would turn out to be.
A man was speaking as Fraser led them into the meeting room, “As we all know, the mission management computer might need to be reset from time to time . . . ” All eyes in the room turned toward the two late arrivals.
Fraser introduced Ryan eagerly, “Sorry to interrupt! Luke Ryan, the new Navy pilot. We’re here to help. Sorry we are late. He just got done with orientation.”
“Ryan, this is Alex Austin. He’s the product owner of the mission management computer. We are in his meeting.”
A few hellos and head-nods were briefly exchanged before the attention in the room shifted back to the whiteboard. Fraser and Ryan took a seat at the end of the long conference table, right in front of the big projector screen – the last two adjacent chairs available in the room. “The worst place to sit for your very first meeting, Luke,” Ryan thought to himself.
Austin wrote on the whiteboard with a black dry-erase marker:
- Latched fault in the MMC
- Broken VMC-MMC heartbeat link
- Unresponsive Display-MMC transmission
He picked up a red one now and circled the number three item. Twice. “This is not good, folks. It could mean complete paralysis of control over the mission content.”
“How likely?” John Carlisle, the lead of Cockpit Systems, asked grimly.
“Minus three, for an eight-hour mission,” answered Greggory Garfield, a reliability engineer.
“This baby will need to be reset all the bloody time,” exclaimed a voice behind Ryan.
Austin continued rather cheerfully, “The good news that is my dear friends in VMS have a brilliant way to cycle power automatically to reset the MMC, in cases number one and number two. The heartbeat logic is self-explanatory. We just need VMS to monitor the latched fault condition taken off of the flight data recorder receiving link. The only challenge is to reset the Display-MMC link.”
“Because you don’t have the soft-button to reset the broken soft-button,” the same voice behind Ryan spoke judiciously.
“Automatically resetting one of my onboard computers. That’s quite concerning,” Ryan observed quietly to himself.
Ryan now rotated his chair around to face the speaker. The voice continued, “What pilot controls do we lose and for how long?” The man looked composed and relaxed. The gravity of his questioning almost betrayed his calm demeaners.
Austin replied, looking at his notes, “No control of the flight plan, no NAVAIDs, no imagery, no maintenance data, no mission-plan-type weapon employment. Sixty seconds to reset. And the success rate of a reset averages at 86% across three scenarios, Jim. I thought you’d also want to know that”
James Podolski, the Systems Engineering department lead, could carry himself with tact and politeness. He also knew how to walk the fine line between being respectful and being to-the-point.
“I trust that you already know the trade-offs between an MMC reset, automatic or not, and doing nothing for all three cases. Have you presented them to the pilots?” Podolski addressed Austin then his eyes turned toward Ryan as he said the word “pilot”. He nodded politely at Ryan, who returned the pleasantry.
“I showed Tony Ireland a functional thread between the pilot and Display before he went on vacation. But it didn’t do much good since he can’t use the soft buttons on the display to reset. They are unresponsive!” Austin answered with some frustration in his voice, noting that the same person asking the question had already admitted the problem with the soft-buttons.
“No, I mean, ‘have you considered how the pilot deals with this scenario as he flies the aircraft as a whole system, and not individual subsystems or components?” Podolski replied, leaning forward in his chair. He did not look so relaxed now. “Since Tony won’t be back for another week, maybe Luke here can help us.”
Austin walked from the whiteboard to the computer station of the meeting room. “The whole system? We partitioned the pilot-aircraft interactions in the integrated behavior all the way from component ICDs to system context. Isn’t that right, Hannah? Where is this extra pilot interaction going to fit?” He was starting up GENESYS and shifting through the project folders.
Hannah Grove nodded from across the room, “Yeah, if we start adding behaviors at the context level to account for these extra scenarios, how can we be sure if we are not changing any atomic functions where we are not supposed to? How much pilot-stuff are we thinking?” Grove was the lead architect in Podolski’s Systems Engineering department.
Fraser and Podolski both looked at Ryan as if saying: “Go right ahead”.
“First of all, y’all scared the crap out of me when you wanted to turn off/on my onboard computer automatically. Second, there is a series of checks we pilots need to perform, based on the particular failure mode and the current engagement scenario, before we bring something offline, if at all. For example, if the latched fault is not critical and I am evading a SAM on my six, I will want to leave the ‘crippled’ computer alone to see where I am on the flight plan. Or, if I choose to employ strike weapons before I get blown up by the SAM, I still can.”
Ryan could see that Podolski was now smiling with approval of his argument. Fraser was leaning back in his chair, squinting in deep thought. Ryan continued confidently.
“Otherwise, I will want to go through the maintenance data, verify them against other indications onboard – you haven’t gotten rid of all of my analog indicators, have you?” –the room laughed– “Check for my position against the mission plan if it’s not already INOP. Maybe command another set of imageries. Then reset. There is a 14% chance I won’t get my MMC back. Correct?” He was going to engineer the crap out of this aircraft, Ryan had promised himself.
Alexander Austin was now completely quiet. He could not believe a small discovery of a component’s limitation could lead to a critical functional change, which also could lead to a sizable impact on the system operations.
“So, how are we going to model all of these changes without mucking things up at the lower levels?” asked Grove, grimly, to no one in particular.
Podolski spoke judiciously, “We have tried to avoid this long enough, against our better judgement, but this needs to be modeled in the operational domain, at the aircraft level, from the pilots’ perspective, and with a lot of pilots’ inputs.” Ryan could almost hear a silent groan roaming the meeting room.
[To be continued…]
