Background
For the longest time, we were not procedures oriented
at AeroVironment. One guy at the top typically wrote flight
procedures, and often that guy would leave out a whole
bunch of stuff because, after all, he's just one guy...
there were things he didn't think about.
Another problem that stemmed from having just one
guy write the procedures was that not everyone used
the same nomenclature. The guy who writes a procedure
gets used to calling something by a nickname and that's
how he identifies it in the procedure. But if other
people who have to use the procedure aren't familiar
with that nomenclature, you can imagine their frustration
in trying to understand what the author of the procedure
is talking about -- not to mention the potential for
disaster that exists because of this.
But the most significant problem we found with autocratically
handing down procedures was that people were far less
likely to follow procedures that they neither created
nor could change. Procedures are tools. Like tools,
they need to be sharpened and honed. Any good craftsman
wants to sharpen his (her) own tools. What's more, people
feel less stress when they can control how they perform
their tasks.
When developing small, quick-and-dirty prototypes,
it is often most economical to just "fly it" and see
what kind of problems there are. Sloppiness is intolerable
when you work with expensive and essentially irreplaceable,
sophisticated airplanes like the unmanned, solar-powered
vehicles that we specialized in at AeroVironment. With
unmanned airplanes, what the pilot does is just a tiny
fraction of what the airplane is trying to do. To fix
a problem, you usually need to get a grasp of an entire
system. If you've got a bunch of people who understand
parts of the system, you bring them together to make
intelligent decisions using each of their areas of expertise.
 |
| Personnel consult
flight procedures in preparation for the Pathfinder
Plus solar-powered aircraft's flight over a coffee
plantation in Kauai in 2002. |
Hence, we realized a couple of commonsense things to help
refine our methods of writing procedures: (1) one person
is not as smart as a group, and (2) a person at the top
may not understand things the same way as does someone
looking at it from a different perspective, such as a
technician who is actually performing the task.
Creating the Procedures
Our first rule was always to "put the person closest
to the problem closest to the solution." Whenever possible,
the person(s) who actually performs the task creates
the procedure for it. Providing this type of ownership
is invaluable. It is also the most efficient way to
create the procedure. Certainly, we had people crosscheck
their procedures with co-workers, but we recognized
that we had to provide a way for handling the inevitable
mistakes. This process of continuous improvement by
the "owner" of the procedure accelerated the rate of
development of the procedure, and allowed us to both
rapidly refine a procedure and also allow for a quick
response to changes in the system during the flight
test program.
Refining the Procedures
- We read through the procedure with a group of people
who are involved. We also invite other people who
are not directly involved with the procedure to provide
some objectivity. We'll get a bunch of changes from
that -- that's generally where we catch the inconsistencies
in nomenclature. On the next iteration the labeling
is usually very close to being error free.
- We then get everyone together for another read
through. This time we have the actual hardware in
front of us, and we'll practice just as we would if
we were going through a flight -- a prototype of sorts.
This time we catch, for example, that the pilot has
turned the damping switch off before he started another
test that required the damping switch to be on. The
guy who owns that process -- it may be the pilot,
it may be a stability and control engineer -- will
take note of that and be responsible for correcting
the current version of the procedure.
- The next time we will sit at the ground control
stations -- we have a stationary one and a mobile
one (that follows the aircraft during takeoff and
landing). We'll go through the whole process again
with the same people, using the latest rewrite. This
is the last run-through before the actual flight.
- After the flight, we get a group together to look
at whether there were any abnormalities that could
be attributed to a procedure or discuss any "red-marked"
changes to a procedure made during the flight. The
person who is the owner of a procedure captures any
issues that came up and corrects the procedure before
the next practice.
Tips
This process allowed us to come up with a procedure that
everyone understood and could follow to the letter. You
must see it as a continuous improvement process. With
a group of people working together you can probably turn
out a perfect procedure in no more than 2 to 3 iterations,
depending on how complicated a procedure it is, of course.
Another benefit is that more people feel ownership for
the procedure. Not every project may require such a rigorous
approach for developing procedures as we used at AeroVironment
for developing flight procedures, but certainly all projects
benefit from this sort of attention to detail.
Example: Surf/Beach/Shallow Water Crash of Aircraft
Symptom:
- Aircraft crashes in or near surf. Aircraft is close
enough to shore that it could migrate onto beach with
wind and wave action.
- Aircraft crashes on sand, but is exposed to surf
spray that wets surface.
Rules:
- If Aircraft crashes in deep water, the aircraft
will be allowed to sink, or be scuttled and not recovered.
- If Aircraft crashes in the surf, where it is evident
it will be moved on shore by the winds and currents,
it must be recovered.
SHOCK HAZARD (120VDC)
- It is possible to receive a lethal shock from the
aircraft whenever it is in the sunlight, if surfaces/components
have been exposed to salt water. The solar array will
continue to produce power in the daylight, and the
saltwater could provide conduction of lethal voltages
and currents in an unpredictable fashion. Unless fuses
are blown, Li batteries also provide shock hazard,
even at night.
Pilot Tasks:
- Turn all motor switches off.
- Contact Aircraft Pilot, if airborne, and request
visual assessment of crash site and relay to Mission
Director.
Engineer Tasks:
- Provide GPS location to Mission Director.
Mobile 1 Tasks:
- Drive Mobile GCS to within visual range of Aircraft,
if near runway, to get best signal path from Mobile
1 to Aircraft, and allow Mission Director to assess
situation.
Mission Director Tasks:
- Proceed with MISHAP PLAN
General Comments:
Search by lesson to find more on:
Ray
Morgan has recently retired as Vice President
of AeroVironment, Inc., where he established the
Design Development Center in 1980, the division
of AeroVironment that develops and produces its
aircraft, serving as Director until April 2000.
Mr. Morgan has overseen more than 75 projects and
the development of over 50 unique vehicles, including
over 35 Unmanned Aerial Vehicles in his tenure at
AeroVironment Inc. AeroVironment has been globally
recognized as a pioneer in solar powered and electric
aircraft, and has placed 5 of its vehicles in the
Smithsonian Museums. |
|
 |