At my job, we use the X-Plane flight simulator program. X-Plane is a commercially available program that can be run on just about any home computer. Obviously, a flight simulator makes a great pilot training tool, and X-Plane has performed very well in that regard, but X-Plane has several features that make it useful as an engineering tool, as well.
Pilot Training on Simulator Powered by X-Plane
When purchasing X-Plane, several programs come bundled together, in addition to the main simulator program itself. These additional programs allow you to customize several aspects of the X-Plane world. Most important to a designer is the program called Plane-Maker, which allows you to build your own aicraft.
To design an aircraft in Plane-Maker, there are several parameters that must be specified. These inlcude things such as the shape of the fuselage, planform of the wings, airfoils used, engine horsepower and fuel consumption; really, just about everything you can imagine that you'd need to predict the performance of an aircraft. Below is a screenshot of just one part of the section used to define the engine, to give an idea of how much detail there is.
Once you're finished defining the aircraft in Plane-Maker, it's time to run the simulator. X-Plane will break your model down into several different elements, or panels (look at the wireframe picture above in the Plane-Maker section for an idea of how this break-down occurs). When the simulator runs, it will use aerodynamic theory to predict the force on each one of those elements, based on lift and drag coefficients and the airflow around the aircraft. (This isn't as complex as a computational fluid dynamics program, but it does use the same type of standard aerodynamic theory that I use for the analytical tools that I've developed.) It sums up the forces on each of those elements to calculate the total force on the aircraft, and based on that force predicts the motion of the aircraft. X-Plane runs through these calculations at a rate that depends on the speed of your computer and different options you have set, but is at least 30 times per second, and can be much faster. This gives a pretty good representation of the aircraft.
At this point, you can fly your aircraft. This is where X-Plane comes into play as a pilot training tool, but you can also use this for some high level analysis as an engineer. To give an example of how this can be useful, I'll describe a concept we had where I work. We had an idea for a small autogyro that wasn't intended to fly very fast. We wanted to add wings to help improve efficiency, but to help keep the design simple and lightweight, we wanted to control it like a conventional autogyro with the rotor only. Ailerons in the wings and a moveable horizontal stabilizer would have added weight, complexity, and cost. So, I built up a quick model of the aircraft in Plane-Maker, and then flew it in X-Plane. I found that this concept could work as long as the rotor was producing enough lift (which we already knew would have to be the case), but that it was too easy for the pilot to accidentally get into a condition where the wings picked up too much lift and unloaded the rotor and the pilot lost control of the aircraft. Now, this was something that we would have discovered had we done enough analysis on our own, but X-Plane let us do it much more quickly. This also gives a qualitative feel for the aircraft that's impossible to get just by doing analysis.
In conjunction with Plane-Maker, the other feature that makes X-Plane so useful as an engineering tool is that it gives you access to so much of the data from the flight model. Below is a screenshot of the Data Input & Output control screen, to give an idea of just how much data X-Plane gives you access to. Each one of those categories can have up to 8 pieces of data, such as position & airspeed, aerodynamic forces, engine rpm & horsepower, and even the status of various systems like the vacuum or electrical system. X-Plane offers a variety of ways to access that data, which are discussed below.
Just about the easiest way to access the data is to monitor it in real time by displaying it on the screen. This lets you monitor data for which cockpit instruments don't exist, or to monitor data much more precisely than visual indicators can provide.
Probably more useful is that X-Plane can also record the data to your hard drive while you're flying, allowing you to go back after the fact and study the data in more detail. The data can easily be imported into Excel, so you can use all the functionality of Excel to analyze the data. This is a feature that I use quite a bit as an engineer.
Another very useful way to access the data is that X-Plane can send it out over a network to another computer (or in the latest versions, back to the same computer that's running X-Plane). Not only that, but certain parameters, such as control positions, can be sent back to X-Plane. This is an extremely useful feature, that, among other things, allows you to simulate your own automated controls.
This was actually a project that I did at work. I work for Carter Aviation Technologies, a research & development company, with our main focus being a concept called a slowed rotor/compound aircraft. Basically - it's a hybrid between an airplane and a rotorcraft. The rotor allows vertical takeoffs and landings and excellent slow speed flight, and then the rotor is slowed down and unloaded to reduce drag at high speed flight when the wings take over providing lift (more info). To help reduce pilot workload, we wanted to automate several of the controls, using a computer for the control logic that would drive hydraulic actuators. Some of these controls had already been completed before we started using X-Plane, but as we started expanding the flight envelope into the region where we slow down the rotor, we decided to use X-Plane to help develop the control that would maintain the rotor at its target rpm. X-Plane simulated the physics of the aircraft, while the program running on the other computer simulated the onboard computer system we had on the CarterCopter, right down to sensor accuracies and the 10 Hz processor speed. I developed the algorithm, and the first time we tested it in the aircraft, it worked passably well. Only a few small tweaks were needed to resolve the difference between the actual aircraft and the X-Plane simulation.
When you stop and think about that, that's a pretty big deal. That project took me about a month, much of it spent figuring out how to communicate with X-Plane over the network and writing the program to do it (since I didn't have any network programming experience prior to that). I've done a few automated control projects since then, and using that program as a foundation, I've been able to complete the projects in a fraction of the time. Compare this to what it would take to develop these during actual flight testing. I'm one person working alone - flight testing requires a whole team (pilots, mechanics, ground control personnel). With X-Plane, I'm able to get in dozens of flights per day, no matter what the weather outside, and with a 100% reliable aircraft, skipping all the things that waste time in real life such as pre-flight inspections and taxiing around the airport. We seldom got in more than a handful of flights per day doing actual flight testing, and there were days when we just couldn't fly at all due to the weather. Using X-Plane to develop the automatic controls can save a huge amount of money compared to doing so during flight testing. It's also safer - no matter how bad I might screw up the control algorithm while flying X-Plane, nobody's going get hurt.
(If you're interested in more of the details of communicating with X-Plane over the network, I've written a tutorial on the subject titled, X-Plane, UDP, and Visual Basic.)
Yet another way that X-Plane lets you access the data is by writing plug-ins that run in X-Plane. This method gives you access to even more data than the other methods, and gives greater control to overwrite variables that are part of the flight model. You could use plug-ins in much the same way as transferring data over the network, but without having to launch a second program. I have written plug-ins for X-Plane, but I've found that for the types of projects I'm working on, at least for my level of programming proficiency, I can develop and fine tune algorithms much faster using the network method (I don't need to recompile and reload a plug-in every time I make a change to the algorithm).
There is one other aspect of X-Plane that is very useful - the receptiveness of its programmer, Austin Meyer (yes, it's pretty much just one guy doing most of the work) to customer feedback. I think he may be especially receptive to people like me - professionals using X-Plane, but it's still very handy. When our company first started using X-Plane, Austin came and visited us in person to make sure he understood the physics of what we were doing so that his flight model would be correct. As another example, for our latest aircraft, we plan to mount the rotor on a mast that can pivot at its base. Earlier versions of X-Plane didn't have support for this, so we talked to Austin, and by his next release (there's usually an upgrade every month or so), we could create an aircraft model with the tilting mast.
After all I've written about the usefulness of X-Plane and all that I've done with it, I figure I ought to at least briefly address the accuracy of the flight model. After all, the data would be worthless if the flight model weren't accurate. I have gone through and compared the data generated by X-Plane to data I've calculated, and to data gathered through flight testing. While X-Plane may not be perfect, it is pretty darn good - close enough to develop that automatic control I discussed above. We also had the qualitative feedback from our test pilots - comparing the feel of X-Plane to the actual aircraft. And again, X-Plane matched reality pretty closely.
The areas where X-Plane showed the most divergence from reality, at least for our applications, were rotor flapping, aircraft responsiveness, and possibly sink rate for rotorcraft at low airspeeds. As far as flapping, X-Plane usually overpredicted the value, but the trends were pretty good, so it was still useful. According to our test pilots, the CarterCopter model in X-Plane was more sluggish than the real aircraft. The last issue, sink rate for rotorcraft at low airspeeds, is one that I'm currently investigating at the time of writing this article. It appears that X-Plane may be predicting too high of sink rates for low airspeeds. The reason why it's only a possible problem for X-Plane, is that I don't have any good test data to compare it to. I know that X-Plane is predicting high sink rates, and the other engineers I've talked to "feel" that the sink rates are too high, but the airspeeds I'm looking at are really low, so it's not a regime where many test flights are conducted. Additionally, it's a very hard phenomenon to predict theoretically, so most predictions rely on some empirical assumptions. So, without actual flight data, there's no way for me to definitively say if X-Plane's predictions are off the mark.
X-Plane really is useful for engineering. It provides a sort of foundation of aerodynamic theory - we just need to build an aircraft with our configuration and see how it responds. X-Plane will never replace the other types of analyses I do as an engineer, but it certainly does add another useful tool to my toolkit.