home page
| forums | about |
projects | partners | contact
Welcome to Echovoice
 
Aircraft Optimization and Design Project 2009-2010
Arizona State University
Michael Olsen, Teddy Garland

 

 



Aircraft Optimization and Design Project


About the Project

As part of an aerospace engineering undergraduate design project, a group of us from Arizona State University were assigned the task of optimizing and designing a transportation aircraft given unique design constraints. The constraints were specific to the type of aircraft we needed to design as well as constraints set forth by the Federal Aviation Requirements, FARs. Finally, the aircraft had to be able to perform and complete an assigned air flight mission. I hope you like our work, any comments please email me at: mike.aircraftproject@echovoice.com.


THE FOLLOWING CONTENT ON THIS PAGE MAY NOT BE COPIED OR REDISTRIBUTED IN ANY WAY, SHAPE OR FORM. UNAUTHORIZED REPRODUCTION OF THIS MATERIAL WILL BE PURSUED UNDER APPLICABLE FEDERAL AND LOCAL LAWS OR REGULATIONS. THE AUTHORS OF THIS CONTENT TAKE NO RESPONSIBILITY FOR ANY MISUSE OF THE MATERIAL BELOW.





In this project, a program was written to design a plane that would hold at least 250 mixed class passengers, perform an 8,100 nautical mile flight, and adhere to Federal Aviation Requirements. The aircraft was sized from the inside out. First, the cabin was optimized based on seat mapping, then the fuselage was created based on the inner diameter and cabin length of the seat maps. The lengths of the nose and aft sections were found based on the cabin length. Wings were sized by varying three inputs-the aspect ratio, the wing loading, and the gross weight-while fixing the taper ratio. As these values changed, the thrust needed for takeoff changed. The thrust needed for takeoff was found from the balanced field length for a runway at an altitude of 5,000 feet. This thrust was used to find a turbofan engine with a bypass ratio of 6 and size the nacelles to house them. From these, the wing parameters were designed for optimal drag performance and to meet thrust requirements. The horizontal and vertical tails were defined based on the wings and a total drag for the airplane was found. The airplane would then perform the mission, including taxi, takeoff, climb, cruise, alternate cruise, loiter, descent, landing, and another taxi stage. The fuel consumed was calculated at each stage, totaled, and the total weight of the fuel consumed. After these calculations, the empty weight, total fuel consumed weight, and then the gross weight was calculated. When the plane completed the mission and the gross weight estimate was equal to the ending gross weight and the takeoff thrust was the maximum thrust, then the airplane design was deemed feasible. These were graphed and the plane with the lowest gross weight, and therefore the lowest fuel consumption was selected.



Full Resolution, Click Here

We used C# for our coding language in this project instead of MATLAB. While C# is not designed to perform math calculations, it is more equipped to handle large amounts of data. The garbage collect feature identifies the variables not needed for future calculations and does not store them. If a plane does not meet a single constraint, no matter at what point in the process, its data is erased and the next iteration begins. This clears the memory and allows the program to run faster, which in turn allowed us to have more iterations. By increasing the resolution of our iterations around the areas that resulted in feasible designs, the optimum plane was found. Threading allows all the functions to run in different threads to do multiple calculations at once, rather than simply running linearly as MATLAB does. An XML file is used to interpolate the data, rather than hard coding this data into the file, C# accesses the data when needed, pulls the numbers from it, then trashes it from its memory. The program is able to store feasible designs in a separate text file. Using this feature, we were able to plot all of our feasible designs and optimize our data by finding minimum values. Any value within the program could be found using the key array dictionary. This would allow us to find the iteration number assigned to a value, or vice versa. This is a much better method than if MATLAB were used, where the arrays would have to be human checked. This data could also be re-loaded into the program, so the same calculations did not have to be run multiple times, such as for the fuselage, which always retained its optimum seat mapping, lengths, and diameters, even as the gross weight estimations were changed. Best of all, a graphical user interface (GUI) was implemented. The GUI was instrumental in debugging. When the code ran, the numbers were displayed visually in their assigned text boxes, which allowed us to spot any values that did not make sense, quickly add a break, and inspect the values at the current iteration. This proved to be a valuable asset in the process, as debugging is a major part of the process. Also, the GUI provides a visualization of the project rather than simply outputting a string of numbers.




Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here


Full Resolution, Click Here






 
 
Copyright © 2010 All Rights Reserved.
Echovoice® and Gamersvoice® are either registered trademarks or trademarks of Echovoice LLC in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Powered by Echovoice Technology