LifeFormulae Blog » Archive of 'Feb, 2009'

Women in Flight Test No comments yet

Women in Flight Test

I spent some 10 plus years in engineering.  As a woman in engineering it was daunting.  As a woman in    Avionics Flight Test, it was even more so.

I was working as a systems programmer at McDonnell-Douglas (now Boeing) in St. Louis, Missouri.   Our project consisted of 6 compilers that supported a completely integrated database system for hospitals.  A woman on our team was married to a section chief who worked at McDonnell Aircraft.  McAir (as it was commonly called) manufactured the F-4, F-18, and F-15 aircraft.   As our project was in trouble, she said her husband said Flight Test was looking for someone who could develop database systems and do other programming for the Ground Support Systems (GSS) unit.

At my interview, I was told, “We manufacture high-tech war machines that might kill innocent women and children.  So, I don’t want any wimps or pacifists working for me.”

I wondered at the time if my interviewer was wearing cammo underwear.

I was accepted.   At the time I was one (if not the first) woman professional working at McAir Flight Test.

My desk was on the fourth floor on the West end of a hanger.  Flight Test had offices and labs on the East and West ends of the hanger. Since our unit was the first set of desks one encountered when accessing our area, I was assumed to be a secretary and asked all sorts of questions.  The fix was to turn my desk around so everybody was looking toward the interior and my desk was facing the window.  I got an up-close look at the planes taking off and landing as they were just clearing the building.  Take offs were bad because the fumes from the jet fuel were overwhelming.  I would have to ask the person I was talking to on the phone if they would hold because I couldn’t hear them over the noise.

The hush houses were less than 100 yards away.  You couldn’t hear the noise (that’s what hush houses do), but the thud-thud-thud vibration of the engines became a bit much at times.  Oh yeah, our hanger sat right on top of the Flight Test fuel dump.

The first project was to develop a database system to track the equipment used by Flight Test.  The original system consisted of a 6-ft. by 20-ft. rack of index cards in pull-down trays. Each piece of equipment had a card which stated what it was, where it was, etc.

Every time a Flight Test program was scheduled, all the parts for that program had to be tagged and their index cards updated.  This would take anywhere from 3 days to a week under the old card system.

The new system did it in a few hours and produced timely reports on all parts and their locations.

Next system was a database system for Flight Test electronics like Vishay resistors, etc.

Another project was providing the documentation and training aids for the Digital Data Acquisition System for the F-18.  This system directly connected the plane’s computer system and uploaded mission information and, subsequently, downloaded mission results.

The old system was called the “taco wagon”.  It was a large roll-about cart.  These carts cost about $300K and used a card reader to upload mission info.

Our system replaced the “taco wagon” with an early Compaq laptop that cost about $3K.

Then Flight Test submitted my name as one of two people for a special program.  The other person from Flight Test was an ex-Air Force major who flew F-15s.

I went through the program and upon returning to Flight Test was asked to make a presentation to our executives.

The major and I made our presentation and opened it up to questions.  Our VP asked the major a question that started with the phrase, “As Flight Test’s designated expert in this area…”.
Later, I told my section chief what happened.  He said and I quote, “Flight Test is not ready for a woman to be expert at anything.”

These are two of the most glaring examples.  There were lots of others.

However, when I left, the VP said, “We will tell your story around the campfires.”

I took that as the highest compliment.

After Flight Test, I worked on AI projects before returning to Flight Test.

The Dee Howard Company in San Antonio ran an ad in Aviation Week for Flight Test Engineers.  I answered the ad.  Alenia (the world’s largest aerospace company, headquartered in Italy) had a stake in Dee Howard.  They were taking on a new project, the UPS 727QF.  The FAA had mandated that all cargo aircraft had to cut their engine noise levels.  UPS decided to re-engine their 727 aircraft with new, quieter, Rolls-Royce Tay 650-powered engines.  Dee Howard was to do the work and conduct the testing.

At the time of the contract, the count of planes to be re-engined was given as 60 plus.  The number actually re-engined has been given as 44 and 48.

Previously, Dee Howard was known for customizing aircraft interiors.  The interior of the 747 that NASA uses to ferry the space shuttle was done by the company.  They also fitted an emir’s 747 with a movie studio, solid gold toilet fixtures, and a complete operating studio.  The tale was that the emir, who had a bad heart, had a living heart donor traveling with him at all times.  Anyway, it makes a nice story.

I was hired in and proceeded to work on the system for the new program.

We were the first to replace all 3 engines on the 727.  Previously, only the two external engines were replaced, the tail engine was left as is.  We were going to replace all three.

We were to have two planes.  The critical plane was to have a new data acquisition system.  The other plane was to use a system from Boeing - ADAS.  Originally designed in 1965, ADAS had 64K memory, filled half a good sized room, used 8-inch diskettes, and the measurements were programmed by way of EEPROM.

The new acquisition system was better.  We bought a ruggedized cabinet and started adding boards.   PC-on-a-chip wasn’t quite there, but we did have PC-on-a-board and we could set things up via a PC interface.  To analyze the PCM data stream I used BBN/Probe instead of the custom software that was used on the previous system.

First flight came.  The system came up and stayed up.  Except for the one time, the flight engineer turned the system on before power was switched from the APU to the aircraft (the 8=mm tape recorder died), it worked every time.

On the fighters, flight test equipment was mounted on pallets in the bomb bay.  It was neat to ride on the plane during a test flight.  An airplane, with all the seats and padding removed, is your basic tin can.

I always got along with the technicians.  They are the ones who do the real work.  They make the engineer’s design come to life or markedly point out the error of his ways.

It was really nice to ask for such and such a cable or gadget and have it brought to my desk. The best (and worst) part of the program was field testing.  I got to go to lively places like Roswell, NM, Moses Lake, WA, and Uvalde, TX with 35 guys.  The length of the test depended on flying conditions.  We were usually stuck there for 3-4 weeks.

We also did some testing at home.  For one ground test, we taped tiny microphones to different places on the engines. The microphones were connected to the acoustic analyzer and DAT recorders.  The engines were then run at various levels.  I ran the acoustic analyzer for a few seconds for one set of mikes and flipped to record another mike set for a few seconds more.  I had to wear headphones for the noise. We had to yell anyway.  It was really hot, because this was San Antonio in July. We were on a unused runway at the airport, next to a well-traveled road.  The test took several hours.  The guys took the door off the head (which was right across from the open front access door) so I could watch the traffic when I used it.  (Did I tell you I had to clean the head when the test was over?)

As the revs got higher, the airplane moaned and groaned.  One engine finally belched.  We were lucky it didn’t catch fire!

Other testing conditions were just as much fun.  Roswell has the desert.  Desert dust at 35 knots is awful.  Tumbling weeds have nasty stickers.  Moses Lake had volcanic ash.  Mt. St. Helen’s dumped about a foot of ash at the Moses Lake airport.  Airport officials dumped the collected ash on a spot at the airport that they thought was unused.  One of our trucks got stuck in it.

At Uvalde, we had heat and gnats.  You inhaled them and they flew down your throat.

A local asked where the women went to the bathroom because there weren’t any trees.

Other than the conditions, there was the schedule.  The equipment had to be set up, calibrated, and ready to go at sun-up.  If conditions were good, we worked all day with a break for lunch and put everything away after dark.

Wake-up was 3 or 4 a.m.   We usually got back to the motel at dark, after we prepped the plane.  It got to the point of going out to get dinner or getting an extra hour’s sleep.

The testing was fun, too.  The plan was to fly over at different altitudes carrying varying weights.  (We had to unload 14 thousand pounds of ballast at one point, consisting of 50-lb. round lead weights with handles on each site.  I took my place in line with the guys.  Same thing with the car batteries for the transponders and loading and unloading the generator from the truck.)

The locals thought we might be flying in drugs, so they called the law, and the local sheriff came to call.

The testing, when in progress, was intense.  After set-up, the microphones were calibrated.  We had mikes at center line and other mikes on the peripheral.  I ran the acoustic analyzer.

I set the analyzer to trigger on a signal from the aircraft and turn on the tape recorders.  After the fly-over I had to download the data, pass it off to an engineer who analyzed it via a curve-fit program, and reset everything for the next fly-over.

The fly-overs came one after the other about 5-7 minutes apart.  We had to re-calibrate the mikes after a few, so we got an extra 5-10 minutes.  We got a break for lunch (with the gnats).

It was hard, dirty work.  But it was fun - and dangerous.  One test consisted of engine stalls on a 30-year old aircraft at 19,000 ft.  (it was too turbulent down below).   Another test had the aircraft stall during takeoff with different loads.  I was on board and loving it.

My supervisor said that “field testing separates the men and women from the boys and girls.” He was right.

One day we had a visitor in the lab.  One of the techs was working on something and let lose a string of expletives.  The visitor said the tech should be quiet because there was a lady present.  The tech looked at the visitor and said, “That’s no lady, that’s Pam!”  (You had to know the guys. I took it as a compliment.)

If you haven’t guessed, as a woman working in this environment, you have to have a thick skin.  You have to work really hard because you have to be really, really good.   But I think it’s all worth it.

It’s too easy to become a “he-she” or a “shim” (dress and act like the guys), but I didn’t.  I wore my hair longish and always wore make-up.  Even in the field.  I laid out my clothes the night before.  I could be up and ready to go in 5 minutes, complete with mascara, eye liner, sunscreen and blush.  I always had my knitting nearby.

It was hard work, but it all paid off.  The UPS plane was certified the latter part of 1992.

I’ve got some memories, some good, some not, but I know I made the grade.

Addendum -

The group working on this project was international in scope and I worked closely with most of them.    We had several people from the British Isles representing Rolls-Royce, including J. who spoke with a find Scottish accent.

I worked with two engineers from Alenia on the acoustics aspect of the program.     They hailed from Naples, Italy.   M. spoke excellent English.  E.  didn’t, but engineering is universal, so we were able to make it work.  Another acoustic team member was a Russian, L.  His English was also excellent.

I can honestly say that I know Fortran in Russian and Italian.   I had to grab whatever Fortran text I could find in a pinch and the Russian or Italian text was usually the closest.

We communicated with facilities in Italy, England, and France on an almost daily basis. The time difference was the only snag.

It was interesting to see how our American ways are interpreted by other cultures.

ASN.1 to XML: The Process No comments yet

asn2xml

Jim Ostell, speaking at the observance of the 25th anniversary of NCBI, stated something along the lines of, “then they wanted XML, but nah..”.

While working on the filters for the LARTS product, most specifically, the GenBank-like report, I realized how tightly-coupled the NCBI ASN.1/XML is to the toolkit. 

Basically, you’ve got to understand the toolkit code in order to translate what the XML is saying. The infinite extendability and recursive structure of the ASN.1 data model is another conundrum. This is especially true of the of the ASN.1 data structures supporting GenBank data - Bioseq-set. For example, a phy-set (phylogeny set) can include sets of Bioseq-sets nested to several levels. Most Bioseq-sets are the usual nuc-prot (DNA and translating protein), but others are pop-sets, eco-sets, segmented sequences with sets of sequence parts, etc.

After we developed LARTS, I wrote the GB filter as a Java object.  It was an interesting experience. 

NCBI ASN.1 rendered as XML, either our version or the NCBI asn2xml version, is very dependent on  the NCBI toolkit code for proper interpretation.  

The two most glaring examples are listed below.

Sequence Locations

Determing the location of sequence features for a GenBank data report, is a prime example.  Here are a few simple examples:

primer_bind   order(complement(1..19), 332..350)
gene                complement(join(1560..2030, 3304..3321))
CDS               complement(join(3492..3593, 3941..4104, 4203..4364, 4457..4553, 4655..4792))
rRNA  join(<1..156, 445..478, 1199..>1559) 5231, 76582..76767, 77517..77720, 78409..78490))
primer_bind   order(complement(1..19), 1106..1124)

For Segmented-sequences:
CDS         join(162922:124..144; 162923: 647..889, 1298..1570)

CD regions locations have frames, bonds have points (that can be packed), strand minus denotes a complement (reverse order), a set of sequence locations for a sequence feature (packed-seqint) denotes a join, and locations can be “order(”ed, or “one-of”, and fuzz-from and fuzz-to has to taken into account for points and sequence intervals.

Sequence Format

DNA sequences are stored in a packed 2-bit or 4-bit per letter format (ncbi2na and ncbi4na).  2na is used if the sequence does not contain ambiguity, otherwise 4na is the format of choice. The sequence must be unpacked to be useful. This takes a basic understanding of Hex(adecimal).
Toolkit

The NCBI Toolkit contains all of the code necessary to render a GenBank report from the ASN.1 binary or ASCII data file.  (The code is there, but you have to figure out how to compile it into an executable.)

We took the toolkit code and converted  it to Java to produce the GenBank-style output format.  It differs from the actual NCBI GenBank Report in that the LARTS report lists a FASTA-formatted sequence instead of the 10-base pairs per column that the NCBI GenBank Report produces.

The Many Variations of LARTS

GenBankReportFilter.java is provided as an example with Stand-Alone LARTS.  The LARTS Reader enables the GenBank-style report.

Using LARTS Online, the user can select the GenBank-style report as the desired Output Format.

A third option, would entail using LARTS Online to obtain the keyword or keyword/element-path data wanted in XML format. This data is then downloaded to a local machine via the Thick Client option. Finally, Stand-Alone LARTS would process the dowloaded XML data into a GenBank-style report.

Stand-Alone LARTS provides example filters and SQL for processing XML and loading the relevant data into a local SQL database.  This includes sample code for  the BLOB and CLOB objects.

The filter for FASTA-formatting sequence data is also available as an example with Stand-Alone LARTS.

These options provide ready access to NCBI data for your research.

Programming Practices to Live By No comments yet

Programming Practices

I’ve been privy to all sorts of coding adventures.   I’ve had a website and supporting components dropped in my lap with little overview other than the directory structure.  I’ve had to plow through the methodology and software written for one aircraft certification program to determine if any of it was relevant for the next certification project.
In either case, it wasn’t a lot of fun.   I spent lots of time reading code and debugging applications in addition to talking to vendors, customer support, technical staff, etc.

There were days when I would have killed for a well-documented program.  Instead, I had to spend weeks in debug, poking around, learning how things worked.  In both cases, the developers of said projects were no longer available for consultation.

Here are few programming practices that I’ve tried to adhere to when writing code.

Document, Document, Document

I am a big proponent of Javadoc.  Javadoc is a tool for generating API documentation in HTML format from doc comments in source code. It can be downloaded only as part of the Java 2 SDK. To see documentation generated by the Javadoc tool, go to J2SE 1.5.0 API Documentation at
http://java/sun/com/j2se/1.5.0/docs/api/index.html. Go to “How to Write Doc Comments for the Javadoc Tool at http://java.sun.com/j2se/javadoc/writingdoccomments for more information.

Other languages have similar markup languages for source code documentation.

Perl has perlpod - http://perldoc.perl.org/perlpod.html
Python has pydoc - http://docs.python.org/library/pydoc.html
Ruby has RDoc - http://rdoc.sourceforge.net

I usually start each program I write with a comment header that lists: who developed the program, when it was developed, why it was developed, for whom it was developed, and what the program is supposed to accomplish.  It’s also helpful to list the version number of the development language.  List any dependencies such as support modules that are not part of the main install that were downloaded for the application.

Each class, method, module (etc.) should be headed by a short doc comment containing a description followed by definitions of the parameters utilized by the entity, both input and output.

Coding practices

I think all code should be read like a book.  Otherwise -

- Code should flow from a good design.
- The design should be evolutionary.
- Code should be modular.
- Re-use should be a main concern.
- Each stage of development should be functional.
- Review code on a daily or at least a weekly basis.
I’ve mostly found that peer review can be a great time-waster.

There are  several design methodologies, such as Extreme Programming, that are the flavor de jour.  None have been completely successful in producing perfect software.

To-Do Lists - Use them!

There are project management and other tools available for this, but a plain text To-Do file that lists system extension, enhancements, and fixes is a good thing.  It’s simple, you don’t need access to or have to learn how to navigate a complex piece of software. 

Find Out Who Knows What and GO ASK THEM

I worked on a project and shared a cube with a guy named Al.  Al was not the most pleasant person (he was the resident curmudgeon), but we got along.  Al had been working on the huge CAD (Computer Aided Design) project since the first line of code was written.  If I couldn’t understand something, a brief conversation with Al was all I needed. 

Every time a programmer on that project complained to me about not understanding something, I told them to go ask Al.  However, I ended up as the “Go Ask Al” person.  I didn’t mind, as we became the top development group in that environment.

Use Code Repositories

The determination of which code repository to use - SVN (Subversion), Mercurial, and GIT are the big three - has become something of a religious issue.  Any of these have their pros and cons.  JUST USE ONE!

Integrated Development Environments (IDE)

There are several of these available.  My favorite is Eclipse (www.eclipse.org).  I’ve also used SunOne which became Creator which is rolled into Net.Beans which was out there all along.

There are a lot of plug ins available for Eclipse and Net.Beans that enable you to develop for almost any environment.  The ability to map an SQL data record directly to a web page and automatically generate the SELECT statement to populate that page has to be at the top of my list.

I’ve used VisualStudio for C++ development in a Windows environment for a few applications, but most of my development as been on Unix, Linux, and Mac platforms.

The problem with most IDE’s is that they are complex and it takes awhile for a programmer to become adept at using them.  You’re also locked into that development methodology which may become inflexible, due to the applications under development.

We used EMACS on Linux for all LARTS development (LifeFormulae ASN.1 Reader Tool Set, my current project), although my favorite editor is vim/vi.  I can do things faster in vi, mainly because I’ve used it for so long. 

Which Language?

My favorite language of all time is Smalltalk.  If things had worked out, we would all be doing Smalltalk instead of Java. 

Perl is a good scripting language for text manipulation. It’s the language of choice for spot programming or Perl in a panic.  Spot programming used infrequently is okay.  However, if everything you are doing is panic programming, your department needs to re-think its software development practices.

Lately, I’ve been working in Java.  Java is powerful, but it also has its drawbacks. 

We will always have C.  According to slashdot.org, most open source projects submitted in 2008 were in C, and this was by a very wide margin. C has a degenerative partner, C++.  C++ does not clean up after itself.  You have to use delete. Foo(); can either be a function declaration or a call to a constructor, depending on the type of Foo.

Fortran is another one that will always be around.  I’ve done a lot of Fortran programming.  It is used quite extensively in engineering, as is Assembly Language.  I have been called a “bit-twiddler” because I knew how to use assembler.  

Variable Names

This is a touchy subject.  I’ve been around programmers who have said code should be self documenting.  Okay, but long variable names can be a headache, especially if one is trying to debug an application with a lot of long, unwieldy variable lanes.

Let’s just say variable names should be descriptive.

Debugging 

This should probably go under the IDE section, but I’ll make my case for debugging here.
Every programmer should know how to debug an application.

The simplest form of debugging is the print() or println() statement to examine variables at a particular stage of the application.

Some debugging efforts can become quite complex, so as debugging a process that utilizes several machines, or pieces of equipment such as an airplane. 

Sun Solaris has an application truss that lets you debug things at the system level and lets you follow the system calls.  The Linux version is strace.

I am most familiar with gdb - The GNU Debugger.   I’ve also used dbx on Unix.

The IDE’s offer a rich debugging experience and plug-ins let you debug almost anything.  

Closing Thoughts

Always program for those coming behind you.  They will appreciate your effort.

It’s best to keep it simple.  Especially the user interface. 

Speaking of users, talk to them.  Get their feedback on everything you do to the user interface.  I spent my lunch hour teaching the Flight Test Tool Crib folks (for whom I was creating a database inventory system) how to dance the Cotton-Eyed Joe. The moral, Keep your users happy.

 Technology is wonderful, but technology for technology’s sake (”because we can!”) is usually overkill.
The guiding principle should be — Is it necessary?

By the way, going back to that certification project.  I found that instead of spending $15K for a disk drive, the company was conned into spending $750K for custom developed software that I had to throw in the trash, except for one tiny piece. Was it necessary? The point is that the best answer is not always the most expensive one.

Top of page / Subscribe to new Entries (RSS)