ASOG Article of the Month - April 2020
ASOG Author: Wayne Dahlke; Image: Commons.wikimedia.org
Besides integrating hardware with software, how do engineers and operators integrate as a team? Wayne Dahlke hits this point with a great real-life ASO story.
Wee Young Lad
I have been flying for most of my professional life. I started when I was a wee young lad of 19, in 1988. An RC-135 she was. A grand old bitch of an airplane. Old. Loud. Equipment that had been designed in 1950-something, meant to be used by something with more than three hands and the ability to see out of the back of its head.
For the next 35+ years, I worked in the aviation field in one way, shape, or form. One thing that has not changed in all that time, is that engineers who design and build new equipment normally know absolutely NOTHING about the operational use of the systems they build. They build awesome gear that performs a specific set of technical functions, but they rarely understand the operational concept under which it will be employed.
New Challenge
As ASO’s, most of us have had the experience of checking out a new piece of gear. Most of us, especially in civilian applications, also perform our own maintenance on the systems we use. We install them, we do preventative maintenance, and we do troubleshooting and software/firmware updating. Rarely do we design or build the systems or software.
In my career in the military, I was fortunate to be part of the AC-130W Dragon Spear program. Here is a link to the project, as it was around 2010: https://www.youtube.com/watch?v=6FvmWBx6BLw
What we were building was a modular gunship, with a Roll-On, Roll-Off kit that could be used as a gunship platform on some days, and a transport platform on other days. We were also testing out a number of new technologies that had never been integrated into the gunship world up until then, such as Stand Off Precision Guided Munitions (SOPGMs), a new mount to support a 30MM cannon, new fire control software that would allow for control of the weapons systems from multiple crew positions, and support for Small Diameter Bombs (SDBs) and Hellfire on the outer wing pylons.
Needless to say, this was a complex project. We had lots of moving parts, complex testing schedules, and a very tight timeline. The ONLY way we made it all work, was that we had an integrated team that involved the hardware and software developers, project managers, and operators. It worked. We went from a concept on the back of a pizza box to an operational platform shooting bad guys, in 18 months.
How to Make an Integrated Team?
One day, another fire control officer (we’ll call him Dan) and myself, with the lead software developer from the fire control software company (we’ll call him Jeff), were heading to the aircraft to review an update to the fire control software. The software was supposed to update a series of fire control settings that were key to swapping data between the different sensors and the fire control software, allowing for targeting handoffs between the various munitions onboard.
Jeff is the penultimate software engineer. You know the type. Great guy, and smart as hell when it comes to software, but he is all about the CLI (command line interface) and does not really like graphical user interfaces. He would prefer to type in the command and have the response come back in a text line.
Our software, on the other hand, HAS to be a graphical user interface. We have to juggle four or more active radios, at least two separate visual sensors, three large 24 inch monitors each, keep track of multiple teams of people on the ground (good guys and bad guys) and keep their positions updated on our situational awareness software, as well as dealing with stack management for all of the other aircraft in our airspace, and monitor our position and fuel state. We are too busy to type anything. Hotkeys, macros and mouse clicks are what we use, and all our software support has to be optimized to leave our spare brain cycles available to process changing information in real time. To top it all off, we fly around unpressurized, with O2 masks, gloves and helmets on, for 6 to 8 hours at a time.
Jeff does not understand any of this, no matter how many times we have explained how we operate to him. He brings up his new version of the software for us to review. We start getting into the various capabilities of what the software can do, and my partner asks him a question about a function, I don’t recall exactly what it was. Jeff responds with “Just type in ‘icuponme’ (not real – I can’t remember the exact command) and that allows you to change to the other function”.
Have a Problem, Find a Solution!
Dan and I look at each other. We look at Jeff. Without saying a word, we look at each other again, both of us grin at the same time, and Dan just says to Jeff “Come with us”.
We head over to the Aircrew Life Support shop, with Jeff in tow. Jeff is looking very confused.
“Where are we going?” Jeff says.
“Life Support” I say.
“Why?” says Jeff.
“You’ll understand shortly” says Dan.
We take Jeff into Life Support. The NCOIC of the shop is on duty and we ask for a full MOPP4 flying kit, size large. MOPP stands for Mission Operational Protective Posture. Level 4 is the full kit. Levels 0-3 are less restrictive, but still a pain in the ass to fly in. A MOPP4 kit is a set of protective gear for flying in Nuclear, Biological, or Chemical environments. The gear involved in a flying MOPP4 kit includes:
• A set of charcoal impregnated pants and shirt, to be worn over your regular uniform or clothing
• A pair of white cotton gloves
• A pair of heavy rubber gloves
• A pair of heavy rubber boots
• A rubber hood that can either be attached to a filter on a hose, or directly connected to the aircraft oxygen system.
We take Jeff over to the benches and deck him out in our full MOPP4 flying kit. Once he is dressed, we take him back out to the aircraft, him carrying his filter kit with the blower on, attached to his rubber hood. Once we are on the aircraft, we help him put on a borrowed helmet, hook him up to aircraft communications, and attach his hose to the aircraft oxygen.
Once he is on comms with us, we ask him “Jeff, have you ever flown on an aircraft during an ORE (operational readiness exercise)?” He, of course, says “No”.
We tell Jeff that what he is wearing at the moment is what we have to wear during OREs, and sometimes during combat operations, and we still have to be able to accomplish the mission. In the case of this aircraft that he is working on software for, that means being able to shoot and manipulate the fire control software, while wearing what he has on right now.
When the Lights Come On!
He gives a very confused “OooooKayyyy?!?” and we ask him to type in his “icuponme” command, to switch between the various functions of the software. He starts turning his head left and right (his mask is fogging up, as they have a habit of doing), trying to see the keyboard and the screen. He finally gets the angle correct to be able to see what he is typing, and he attempts to type in the command.
‘uoicupooinme’, ‘8i9fcdjyuploionmnjmwse’
After about five attempts without success, he asks us “How the hell do you guys type wearing all of this crap?! I can’t even see the keyboard, let alone feel the keys!”
We give the silence a few seconds to build, and then Jeff answers his own question with “That was the point of this, wasn’t it? To show me why you guys have to have hotkeys, mouse clicks, and button presses to do things with a GUI?”
“Yes, Jeff” Dan and I say in unison.
We never had another problem with Jeff not listening to us when it came to anything having to do with operator input for the systems.
The Moral of the Story
If you can give operator input to your engineers early on in the development process, and make them understand that you are just as much of an expert in your field as they are in theirs, system development, operational utility, and testing goes much, MUCH smoother!
I don’t want anyone to think that we felt Jeff was stupid. He was not. In fact, he was a bloody genius! But he did not have an operational “hook” to hang his ideas on when it came to design of the software. Our real world, operational experiences were needed to help him inform his design processes. In the end, we both won. We got a great piece of software that still amazes me at what it does, and Jeff learned a valuable lesson in why certain design parameters were essential to the proper functioning of his software.
As always, fly safe and have a great day!
Comments
Mr. Dahike,
Indeed, there is a difference between operators and maintenance, but he often the cumbersome relationship between engineers and aircrew can be a complete sh*t show. Not to forget, it can be deadly. An engineer designs a box to perform one way, and the operator, really needs it to do a task yet totally different.
thanks for the read and gunship perspective
R.
Scott