[American Institute of Aeronautics and Astronautics 10th AIAA Aviation Technology, Integration, and...

1 American Institute of Aeronautics and Astronautics (v.0510)

Issues in Undergraduate Aerospace System Engineering Design

Education - An Outsider View From Within

Armand J. Chaput,

Aerospace Engineering and Engineering Mechanics

University of Texas at Austin, Austin, Texas, 78712

Industry, government and academia share responsibility for the development of future engineers needed to keep

aerospace products and capabilities on the leading edge of technology. One of the enablers is fundamental knowledge

of systems engineering and its practical application to systems that involve multiple disciplines. Multi-discipline

system engineering design involves much more than application of a systems engineering process, and our ability to

continue to advance the aerospace state of the art requires: (1) engineers with substantive knowledge of design across

multiple technical areas and (2) improved tools and methods for doing it. Nonetheless, engineering education

programs continue to focus on the traditional educational product – highly qualified but single discipline engineers

and technologists. Meeting the demand for multi-discipline systems engineering designers requires teaching

something different than is found in current text books. And it may involve a little bit "of going back to the future".

Nomenclature

A&D = Aerospace and Defense

CMU = Carnegie Mellon University

DoD = Department of Defense

INCOSE = International Council on Systems Engineering

MIL STD = Military Standard

NDIA = National Defense Industry Association

SAR = Selected Acquisition Report

SE = Systems Engineering or Systems Engineer

SEs = Systems Engineers

I. Introduction

The focus of the paper is about what we appear not to be teaching our students about system engineering design (and

analysis). Inadequate knowledge or improper application of systems engineering (SE) has been identified as a significant contributor to the poor performance of aerospace and defense (A&D) programs and if aerospace engineers are entering the work force with a shortfall in fundamental skills and knowledge , we're responsible. While, there is room for debate about the root cause, I suspect that the issue is simply that teaching SE is not a significant part of our undergraduate aerospace engineering design course objectives. Whatever the reasons, we need to get to the bottom of the issue. If we don't, and our industry continues on its current path, aerospace engineering as a separate discipline may not survive. A highly specialized engineering discipline that can no longer deliver a quality product to reasonable cost and schedule is not needed anymore.

Why the dire prediction? Aerospace programs around the world are in serious trouble. Huge cost and schedule over

runs combined with performance under runs are now the norm. Every three months the U.S. Undersecretary of Defense for Acquisition, Technology and Logistics submits a Systems Acquisition Report (SAR) to Congress showing the status of selected DoD programs1. Figure 1 is a summary plot for the last quarter century, tracking the total cost of the programs as originally estimated vs. the SAR cost forecast. The gap between the two numbers is currently running at about $300 billion a year and is showing no signs of going down. These overruns translate into an increased tax (or debt) burden of about $2,000 per year for every single US taxpayer. Admittedly the problems aren't all aerospace but an educated guess is that we are a significant contributor.

10th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference 13 - 15 September 2010, Fort Worth, Texas

AIAA 2010-9016

Copyright © 2010 by Armand J. Chaput. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.


US DoD System Acquisition Report (SAR) Cost

0

300000

600000

900000

1200000

1500000

1985 1990 1995 2000 2005 2010

Year

Acq

uis

itio

n P

rog

ram

Co

st

($M

)

Initial estimate

Projected actual

Fig 1 - US Department of Defense Acquisition Program Cost Performance1 If you are thinking about what you could do with your $2000, don't. Instead think about what you'd teach if you were

handed $2000 per design student every year, if and only if, you'd just (1) figure out what's lacking in the educational preparations of the previous engineers responsible for these incredible overruns and (2) agree to teach the new ones what to do differently so they don't make the same mistakes. Depending on the size of your class, this could turn into a pretty good chunk of change to supplement your design program budget. In my case, at 40 students per class, the chunk would run at about $80K per year. Looking at the problem from that perspective might just cause us to think just a little bit differently about what we teach our students, e.g. about how to deal with design requirements that push credibility, why it is important to check work carefully (even if it comes from a computer) and why they should speak up when shoddy engineering "visions" (including those that violate the laws of physics) are proposed.

The problem with my $80 design course funding scheme is that we'd have to say we're the only ones responsible and

we're not . The SARs break out responsibility for the over runs and their numbers show that engineering is only responsible for about $75-$100 billion of the overrun per year (Figure 2). Cost Estimating is one area that is even more culpable than engineering. My good friends in cost estimating, however, would respond that it is flawed engineering product specifications and/or person hour estimates that establish the basis for their admittedly flawed cost estimates. So If we want to accept responsibility for those flawed cost estimates, we could bring our culpability back up to about $200 billion per year and get back into the "good chunk of change" category. But pointing fingers at DoD and the military services is easier

Causal Factors - US DoD SAR Cost Growth

0

50000

100000

150000

200000

250000

300000

350000

2010200820062002199819931988

Year

Acq

uis

itio

n P

rog

ram

Co

st

Incre

ase (

$M

)OtherCost estimatingEngineeringSchedule

Figure 2 - Identified Causes of SAR Cost Overruns1

Root Causes. Prestigious committees have conducted countless reviews, dug into suspected causes and effects and generated a long list of explanations. Some focus on the role of unproven technologies, others point at inadequate


government oversight and/or uninformed customers. Other causes include infatuation with advanced technologies, lack of experience, cost optimism, inadequate modeling and simulation and a host of other issues.

What hasn't been identified as a root cause is aerospace engineering design education. So why are we talking about

aerospace design education and billion dollar aerospace program over runs in the same breath? The simple answer is that engineering education has been identified as a cause, it just hasn't gotten down aerospace engineering (yet). However, aerospace engineering graduates are major players in the industry and something about practices in the profession is causing overruns. Simple logic says that aerospace engineering education has to be a part of the problem.

An example of an educational element of the problem can be found In Kaminski et al that focused on causes of Air Force

program failures tracing back to decisions made during formative years, euphemistically referred to as Pre-Milestone A2. In the report, the usual list of causes was highlighted but an education related issue appeared at the top of the list. The issue was Systems Engineering (SE) and its proper application during early program design phases. The importance of having a fundamental understanding of SE was stated in a study finding as follows:

:

• Attention to a few critical systems engineering processes and functions particularly during preparation for Milestones A and B is essential to ensuring that Air Force acquisition programs deliver products on time and on budget.

Other SE education related issues included "a lack of System Engineering flexibility (i.e. "overly rigid processes or a

lack of trust among program participants or stakeholders)" and "the importance of placing experienced, domain-knowledgeable managers in key program positions". Domain knowledgeable means people that understand the disciplines for which they are responsible and during early program phases primarily means engineering.

In polite language Kaminski is saying that during early programs phases (which tend to be staffed by less experienced

engineers), the participants aren't applying fundamental systems engineering principles to their programs and/or are applying them rigidly (i.e. like a cook book). Stated bluntly, these less-experienced engineers either don't understand how to apply and/or know little or nothing about Systems Engineering. If we do teach SE as a fundamental principle of design then Kaminski is not pointing his finger at us. If we teach SE by showing a fluff process chart or two and then press on to more "substantive" subjects like aerodynamics and propulsion, we are culpable and Kaminski is pointing a finger directly at us.

Lest we get too focused on SE as an elixir to solve the world's problems, an interesting study by Carnegie Mellon

University (CMU) sponsored by the National Defense Industry Association (NDIA) should be on every SE educator's reading list3. In this study, defense industry participants were surveyed to determine how the role of SE contributed to their projects' success. Instead, they got some shocking results as shown in Figure 3. The survey results showed that while projects with high levels of SE capability performed significantly better (shown in green) than projects that didn't (shown in red), little correlation existed between failure (red) and SE capability. Translation - even with the highest levels of SE capability, 30% of the projects still ended up in the ditch from a cost, schedule and/or performance perspective.

Figure 3 - Project Performance Versus Systems Engineering Capability3

Even more interesting was another chart deep in the body of the report dissecting the Figure 3 projects by project

difficulty. Relatively simple projects were separated from the more complex ones. As shown in Figure 4, the expected


positive correlation between SE capability and project performance applied only to what were classified as "low challenge" projects, i.e. , projects that most engineers should be able to do with their eyes closed. For more complicated projects, there was a not only a negative correlation between performance and SE capability, the percentage of programs showing poor performance went up to 50%. One explanation might be that (hopefully) no procurement organization would give a contract for a complex project to an organization that didn't have a reasonably good SE capability. Therefore, the correlation showing that performance goes down with SE capability simply means that these organizations with good SE capabilities were on the receiving end of some poorly conceived programs. What can not be explained away, however, was that one-half of the high challenge programs still did not perform well. Unfortunately, the survey data identified only top level causes and again, design education didn't make the list. My speculation, however, is that the root causes involved either unresolved technical issues or fundamental engineering or management blunders. Either way, the data clearly showed that "something more" is required on complex programs than a having a world-class SE process. And that "something" might possibly be engineers that actually understand the fundamentals of SE because, once upon a time, that was the difference between success and failure.

Figure 4 - Performance Versus SE Capability (SEC) by Project Challenge (PC)3

II. Systems Engineering - A Design Engineer Looks Back

Some might interpret this section as criticism of SE and its practice but they would be wrong. I am a strong advocate of

SE as a foundational approach to engineering, and I proudly consider myself a practicing Systems Engineer as shown in Figure 5. Rather, the objective of this designer's perspective is to call attention to what used to work reasonably well and ask why we're not doing it anymore. Instead of throwing rocks at SE, I'm making a case for why traditional discipline engineering design educators should go back to basics in what we teach our students about SE principles as a foundational principle of design. Too many engineering graduates go to work in industry and government and don't know enough about SE, much less have a fundamental understanding of the basic principles. Andd these students aren't to blame, we are.

Figure 5 - Why I Consider Myself a Systems Engineer4

From a historical perspective, proper application of SE principles after WWII is why so many complex engineering

programs not only achieved success but came in reasonably on budget and schedule (at least compared to today's programs).


However, those successes were actually achieved not by what is today called Systems Engineers (SEs), but by traditional discipline engineers that simply applied SE principles to their own engineering practices. That model is not what we have today. Today SE has emerged as a separate discipline from engineering that has more in common with program, contract and financial management than it does engineering. Nonetheless, the foundational aspects of SE still need to be part of contemporary engineering practice.

For people who have worked in industry or government, SE is a well known approach to the development systems and it

has been around for a very long time. During and after WWII SE was advocated by the DoD and the military services as a relatively simple and straight-forward approach to weapons system engineering that could be tailored for almost any product. The basic principles were documented in 1969 by Military Standard (MIL-STD) 4995. This seminal publication described fundamental, common sense, standard engineering approaches for planning, executing and verifying product development. The fundamental concepts involved discipline and a focus on system requirements. Technical plans were tied to requirements and documented in a standard format called a System Engineering Management Plan (SEMP). Schedules were to a standard format called a System Engineering Management Schedule (SEMS). Program reviews were planned and scheduled again to standardized criteria. All of this may sound complex and bureaucratic but the underlying principles were straight-forward and easy to understand by working level engineers.

MIL-STD-499 (499) was used widely across aerospace and updated and revised as 499A in 1974 (Figure 6). Even in its

revised form, 499A comprised a grand total of 24 pages of text including the stamped order form on the back. 499 was applied to programs ranging from complex systems (nuclear submarines and ICBMs) to streamlined development programs (the F-16 lightweight fighter). Even though these programs still stumbled and were under constant scrutiny, in comparison to today, they were more successful considering the combined effects of cost, schedule and performance.

Mil-Std-499

Mil-Std-499A

Mil-Std-499B

EIA/IS632

IEEE1220

Dod-Std-2167A

Dod-Std-7935A

SoftwareEngineering

SystemsEngineering

ANSI/EIA632

IEEE1220

ISO15288

ANSI/EIA632

EIA/IS 731 SECapab. Model

Others ...

IEEE1220

Dod-Std-1703

Mil-Std-498

IEEE 1498/EIA 640

ISO/IESC12207

US12207

J-Std-016

19691974

1994

1994

1994

1998

1998

1998

Updates

(Trial Use)

2000+

2000+

1987

1988

1988

1994

1995

1996

1998?

1997

(Draft)

Figure 6 - Evolution of System Engineering Documents 5

An interesting element of 499 was its focus on engineering. Written by engineers for engineers, 499 focused on basic

principles not process and was remarkable for its engineering simplicity, clarity and usefulness. The basic principles formed the basis for engineering planning, design and analysis tasks and test and verification. 499 came across as a no-nonsense, disciplined engineering approach, traditional discipline engineers accepted the process and considered themselves a part of it. 499, however, did require non-traditional support. Somebody had to make sure all the requirements were written down and supported by documented design decisions, planning needed to be documented to a certain formats as did design reviews, etc. Therefore, specialized groups were established within companies and in government to manage and track SE unique tasks. The people assigned to these groups were called SEs but sometimes they were not engineers at all. Some were engineers, and some of them were very good ones with good administrative skills. Some were generalists in search of new opportunities, but unfortunately some were also rejects from traditional engineering organizations that didn't get much respect from their peers. Consequently, in the aerospace industry of the day, being a SE was a not what "real" engineers aspired to. The perception continues to be a problem today, some "more-senior" engineers continue to associate even fundamental SE with engineering administration, not technical substance.

During the 90's aerospace organizations started hiring SEs from university programs set up specifically to meet the

growing demand. Because of curriculum hour constraints, SE programs obviously couldn't teach everything about engineering and SE processes so the SE programs focused more on process and less on engineering. As a result, SEs started showing up on the job with limited knowledge of traditional engineering disciplines and they got even less respect from engineering organizations than before. In fact line engineers started using the term "book engineer" and the term was not intended as a compliment. The inevitable result was that SE organizations and personnel were not well integrated into engineering and projects and started developing along a different path as was previously highlighted as an issue in Figure 5.

Today no longer can anybody with or without an engineering degree walk in and call themselves a SE. Today's SE tools


and methods have become complex and specialized training and certification is required. SE Masters programs have become popular for traditional discipline engineers and getting more so. Perhaps the perception problem with other engineers will take care of itself eventually, but it is still there.

Another issue is that SE documentation and process descriptions have gotten very complex. In the mid-90s, under the

banner of streamlined acquisition, the government got out of the standards business. The SE mantle was picked up by a number of non-governmental groups as shown previously in Figure 6. Included was the International Council on Systems Engineering (INCOSE) whose membership was drawn primarily from university SE programs and SE groups in industry and government. Whether intentional or not, the previous focus on SE principles that were understood by traditional engineering disciplines switched to generic process descriptions and procedures that non-SEs found difficult to comprehend much less apply. Current SE document releases now run in the hundreds of pages (Figure 7).

Basic System Engineering Process Descriptions

(selected publications)

0

50

100

150

200

250

300

350

400

1965 1975 1985 1995 2005

Year

Do

cu

men

t p

ag

es

Mil STD 499Mil STD 499AMil STD 499B (draft)INCOSE SE HandbookDoD AF Product Descriptions VII.1.0DoD AF Product Descriptions VII.1.5all

Figure 7 - Systems Engineering Document Size

In defense of bigger documents , the new SE processes now accommodate DoD systems of systems (SoS) program needs

that are non-traditional. Nonetheless, demanding traditional engineering design and analysis procedures are now represented in generic process flows that are unfamiliar to most engineers. When sophisticated engineering design, analysis and test process are packaged into simple "gazintas" (goes into) and "gazaoutas" (goes out of) on multi-color flow charts, otherwise minor technical hiccups turn into seriously underestimated and/or misunderstood technical and programmatic blowups.

The bottom line for traditional discipline engineers is that in previous decades , universities didn't have to teach the

principles of SE because it was one of the first things graduate engineers learned on the job. Today what they are taught in government and industry about SE has more to do with program and financial management than it does engineering. Today's engineers also work in a more unsupervised technical environment than before. If today's engineers aren't exposed to the fundamental principles of SE as undergraduates, they enter the A&D workforce unprepared. At a minimum, today's undergraduate aerospace students need at least a 499A level of SE understanding. Even though SE understanding at this level may be considered a little old fashioned by contemporary practitioners, from an engineering standpoint, the basic principles are as valid today as they were during the Apollo and Minuteman programs. Requirements management, SE and risk reduction planning, requirements focused design reviews and other fundamental approaches are still critical to engineering success in any program. And so, my fellow aerospace engineering design educators, if we take this focus-on-fundamentals approach to SE to our design classes, we may be doing our part in helping resolve today's problems and save ourselves and our students multiple thousand dollars a year in tax or debt obligation relief.

III. Issues in Aerospace Engineering Education

The following is anecdotal and has an acknowledged bias. The bias comes from having spent a career in industry and

government as a reasonably successful air vehicle and air system designer and finding out that what I spent my career practicing is not taught in academia. .

At the most basic level, undergraduate engineering education is about fundamentals and the fundamentals are in

traditional engineering discipline areas as addressed in Figure 8. Among engineering programs Aerospace Engineers may get exposed to the broadest range of discipline areas as undergraduates which makes them reasonably well rounded and prepared for careers as technical managers and chief engineers where breadth of knowledge is valued. Thereafter, depth not breadth is


encouraged academically and in graduate school, most students specialize, typically in an established discipline. Therefore, the university focus on providing undergraduates with a broad exposure to engineering fundamentals is appropriate. .

Figure 8 - Undergraduate Focus on Fundamentals, Graduate Focus on Specialization The focus on fundamentals in engineering is also consistent with an educational environment where curriculum hours

required for graduation drive everything. Departments are under incredible pressure to pack more content into a fixed number of hours required for graduation. Engineering schools and colleges have to compete with other programs having less demanding graduation requirements. Creative professors can sometimes figure out how to squeeze a new subject or two into an existing course but in general it is a zero sum game. In general, if you want something added, you have to identify what you want dropped but this does not have to be the case for SE. SE principles can be integrated into other courses if engineering educators think it is important enough.

Although teaching styles vary widely, the instructional norm in engineering is still the university standard 3 hour per week

lecture course. A single 3-hour lecture course is considered a 25% time (10 hour per week) teaching load; however, engineering design courses are notorious for requiring significantly more instructional hours than the 10 hour norm

To enable learning, the theories and methods have to be applied and the traditional application scheme is homework. The

infamous problems in the back of the book are intended to (and do) reinforce learning of basic concepts. We need to recognize, however, that homework problems teach engineering analysis, not design. Undergraduate homework problems need to be reasonably well-defined to achieve learning objectives and to enable efficient grading and design problems don't meet either criteria.

Real world engineering design problems are typically ambiguous and take too much time and effort to formulate, teach

and grade to be useful for teaching a large number of students. It is not until students get into a design class or graduate school that they learn how to approach more complex or ambiguous problems. Even though successful students may excel in solving straight-forward engineering problems, they may not have a clue about how to approach those that aren't.

Aerospace Engineering Design. Teaching aerospace engineering design is a fundamentally different from teaching engineering analysis. Engineering analysis can follow a prescription. One simple problem can teach a class full of students how to do even a complex analysis. Design, on the other hand, almost never results in a prescribed solution. Design involves iteration and decision points that can take students off in different directions. This makes design inherently more time consuming to teach (and grade ) which is why it does not fit the standard 10 hour/week per class formula (no matter what the bean counters claim).

Another design education issue is the availability of professors with interest and/or experience in design. Unfortunately

American universities do not consider design as a scholarly pursuit. Apparently neither does government and industry funding organizations because few design related grants and contracts are made available for universities. Design professors, therefore, struggle to support graduate students. Also, not many academics have real-world design experience and some professors are uncomfortable with the subject. For these and other reasons, teaching design is not highly regarded in academia and not many professors want to do it.

• Academia is focused on replicating our traditional (and highly regarded) engineering education product

–Good engineers well grounded in the fundamentals

–Capabilities in traditional engineering discipline areas

• Undergraduates get exposure across department disciplines

–Aerospace Education may be the broadest, covering many elements of ME, ECE, CE, IE and Physics

• Masters Students specialize in selected areas

–Representative of individual department areas of expertise

–Learn how to think, solve problems, develop research rigor and document and present results

• Ph.D. students get even more specialized

–Expected to conduct original research in advisor’s specialty area, typically requires intense focus

– Good for the students, good for the faculty


The good news is that design professors do get tenure (sometimes) and/or become really interested in design, and find

design education to be professionally and personally rewarding. When that happens, they turn on and turn out fired-up and knowledgeable students that want to pursue careers in design. Another good news story is accreditation organizations such as the Accreditation Board for Engineering and Technology (ABET). ABET considers design a critical element of an undergraduate engineering program and has established firm accreditation requirements for capstone design courses. If it weren't for organizations like ABET, university level engineering design courses might not be taught at all.

The above issues are well known to academia and university administrators. One option is to hire adjunct professors as a

way to bring in faculty with real-world design experience. Universities, however, tend to look first and foremost at academic credentials when hiring, which for most universities, means a minimum of a PhD. In the real world of design, there aren't very many practicing designers with PhDs (present company excepted). Therefore, universities sometimes hire an "experienced designer" from government or industry that doesn't have any design experience. Another issue is teaching experience. Most academics learn how to teach and how to do it well or they don't get tenure. Many adjuncts, however, have little or no classroom teaching experience, and they may struggle in learning how to communicate effectively with students. The best solution might be to team adjuncts with tenured faculty but that just drives up the cost of education and most universities can't afford it.

Air Vehicle Design. Teaching students how to develop a new air vehicle design and analyze it is not inherently difficult. What is difficult is "the rest of the story". A number of excellent textbooks exist that explain the fundamentals of the first part of the story quite well 7,8,9. The textbooks start with requirements and take students through a logical series of design and analysis steps involved in estimating air vehicle size, weight, performance (SWaP) and sometimes cost. Unfortunately, this description of the air vehicle design process is what it used to be, not what it is today.

It has been at least 4 decades since an informed customer published a set of design requirements and asked contractors to

go design one of "these". What contemporary customers do instead is to define a top level mission objectives or jobs they want performed and ask designers to come up with the "best" design concept including how to use it. Performance "requirements" are defined but expected to be traded. Addressing broad design and requirement issues of this type involves a different approach to teaching design than is described in the textbooks. Students that master the "new" approach need a broader set of skills including (1) what the air vehicles do and how they do it, (2) how to develop, manage, trade and rationalize requirements, (3) how to do multi-discipline trade studies and (4) how to make and document "balanced" design decisions. The name that I give the "new" set of design skills is "Systems Engineering Design". Other educational objectives for teaching it are addressed in Figure 9.

Figure 9 - System Engineering Design Education Objectives Unfortunately, all of these "new" air vehicle design skill requirements are in addition to the old requirements. Students

still need to understand and know how to do the traditional design process. The process also needs to be efficient so the students can get through their design assignments and have time for trade studies before the semester comes to an end. To resolve this issue I developed an integrated design and analysis spreadsheet called Rapid Air System Concept Exploration and is shown conceptually in Figure 10 10.

Integrate Systems Engineering education (rigor and discipline) with design education (math, physics and technical integration)- Systems Engineering introduced simply as “how we approach

engineering design”, not something separate

Demonstrate why process, rigor and discipline is important- Student design projects are complex, so no other option

- Chaos develops when requirements float

Introduce Risk Reduction and Risk Planning as straight forward engineering approaches - Generate data needed to support a reasonable design

Require students to think and design across disciplines- Including communications, sensors and CONOPs

Achieve objectives through combination of formal classes and student design projects


Figure 10 - Rapid Air System Concept Exploration (RASCE) Other challenges associated with teaching aerospace system engineering design are (1) the absence of design textbooks

that address even the fundamentals of the "new" approach and (2) professors with knowledge or experience in how to approach SE design. In fact, after concluding that an acceptable text book was not available that adequately covered the "new" air vehicle design process, I decided to simply write my own. Unfortunately, not in publishable form yet, my students are exposed to a series of 25+ PowerPoint lesson charts that describe the basic approach.

The bottom line is that what used to be a relatively straight-forward approach to aircraft configuration definition, sizing,

performance estimation and optimization to a set of defined requirements has gotten ambiguous and complicated. Students that are educated in the "old" approach may not know what to do in the "new" environment.

Air System Design. If you've taken a SE course, you'll know the difference between Air Vehicle and Air System design. The air vehicle is only a part of the system design responsibility. Since Unmanned Air Systems (UAS) epitomize the air system concept, I focus my course and system design projects on UAS. At the system level, UAS design responsibilities include Concepts of Operations (ConOps), payloads, communications and control, logistics, support and training plus all of the other bits and pieces required to make the system work. The reason I teach this way is to give students an appreciation for and understanding of other parts of the system. Most of the other parts aren't designed by aerospace engineers but are sensitive to aerospace design decisions and vice versa. Fundamentally I want students to understand that what they design has to fit in with and optimize at the overall system level. If I succeed at this objective, students will be equipped with enough fundamental understanding to function as competent members of an aerospace SE design team and one day, to be able to competently lead one 11.

An example of a typical student team design project is shown in Figure 11. The important thing to note is the absence

of all but a few top level defined requirements. Basically students get a geographic area description, a top level description of the operational objective, takeoff, sensor resolution and timeline requirements and a few operational requirements specific to the mission. The students are also given a longer list of generic defined requirements that address a range of issues from integration in national airspace to landing reserves. All requirements are expected to be decomposed, allocated across the system elements and tracked.

Broad Problem Description- Concepts of operation- Sensors and Comms

- Requirements def’n

Parametric design- Initial estimates- Engine type

- Initial engine size- Initial vehicle size

- Parametric comparisons

Aerodynamics- Cfe ⇒⇒⇒⇒ CD0- CDi

- CLmax – no flaps- CLmax – flaps- Trim drag- Parametric comparisons

Propulsion- Size, weight and volume- Speed and altitude effects

- Installation effects- Parametric cycle decks- Parametric comparisons

Geometry- Models

- Fuselage(s)

- Nacelle(s)- Wings

- Tails- Pods

- Weight effects


Performance Methods- Takeoff- Climb

- Turn

- Accelerate- Cruise- Loiter- Land


Weight- Unit weights- Weight fractions- Weight convergence

- Geometry effects- Parametric comparisons

Integrated Performance- Trade Studies- Model convergence

- Requirement convergence- Parametric comparisons

RASCE provides physics based multi-discipline design feedback


Figure 11 - Typical Student Air System Project Description Given the discussion about education being a zero sum game, obviously my students can't learn how to do it all so I

focus on a few fundamentals that I think they need to internalize and apply. Obvious ones are ConOps, Sensors and requirements. Knowing how an air system is used and what it is can do is a key bit of knowledge to take away from an air system design class. Also, knowing how to track, analyze and manage requirements is another. All of us in the air vehicle design business know that the primary purpose of our beloved machines is to push people or some sensor or payload through the air and to provide enough antenna space and power to beam the collected information off to some user. Therefore, sensors, communications and other payloads are included in the problem set. Unfortunately, not enough time is available to get into operations, support and training concepts and related design issues but students are sensitized to how important these issues are to the performance of the overall system.

Student design responsibilities include a mix of individual and team assignments. All students are members of a design

project team where they have specific team responsibilities. For example, a team might select a project to design a UAS to meet US Coast Guard search and rescue requirements as shown in Figure 11. In this example, team design responsibilities would include development of the ConOps, payload design and definition and concepts of control. Another part of the team assignment would be to determine the "best" air vehicle concept for the mission. Selecting a "best" concept requires systematic design and evaluation of a matrix of concepts including different propulsion types, air vehicle configurations and payload integration concepts, e.g. internal vs. external carriage. To support a rational configuration selection process (another team responsibility), all of the concepts need to be reasonably well optimized for the mission. This means that each concept has to go through top level trade studies (wing loading, wing aspect ratio, etc) to demonstrate that they are reasonably optimum for the team ConOps. Due to the amount of work required, each member of the team assumes responsibility for design, analysis and optimization of one of the concepts for which they get an individual grade. Using a mix of team and individual responsibilities, students get graded on how well they perform as individuals and how well their teams perform. In this grading concept, individual students get a "share" of the team grade based on peer evaluations of their contributions to the team effort.

Specific team responsibilities include determining how sensors will be used and how they integrate with the ConOps,

e.g. speed, operating altitudes and maneuvers. The Payload team needs to work closely with the ConOps team that has the responsibility for overall mission definition to include the speeds, altitudes and maneuvers. The payload team is expected to work out acceptable slant ranges, target area coverage, meet resolution requirements and criteria and then make independent engineering assessments of the performance, size, weight and power required to support the payloads. Hands on hardware projects are also integrated into the assignments because students need to understand how brutally blunt mother nature can be about the laws of physics. Therefore, the ConOps and Payload teams are required to evaluate ConOps in flight before they start writing requirements. A Flight Test Team is formed to integrate ConOps and Sensor testing as well as to experimentally determine fundamental aero-performance parameters required to support air vehicle (Figure 12). Finally, the whole operation is put under a student Program Management Team that has to integrate all of the plans and schedules and make sure they can be performed within clearly defined resource constraints (a maximum number of student non-class hours per week). The resource constraint is imposed to provide realism and to discourage the students from putting off everything to the end of the semester.

UAS shall provide continuous 24/7 search and rescue (SAR) support from USCG Air Stations in US coastal areas of operation - UAS shall detect and identify ships in distress (SID) at distances up to

1600 nm from USCG air stations within 18 hours of tasking- SID shall have a designated last known position (LKP) within ±50 nm

and have been adrift for up to 48 hours, at up to 4 knots within ±25° of a line from the LKP to its current position

- Detection shall be accomplished in all (flyable) weather conditions- Identification shall be accomplished in under weather conditions- Emergency frequencies shall monitored for communication and

direction finding purposes and to establish SID voice communication - SID identification shall be by ship name and/or ID number

Upon SID identification, UAS shall support USCG rescue cutter operations for up to 18 hours

Required Trades- ConOps- Sensor(s) required- Search and loiter locations- Time on station

- Air vehicle size and numbers - Speed(s) and altitude(s)- Propulsion type and size- Aspect ratio- Wing Loading


Figure 12 - UAS Flight Test and Evaluation Students are also given simple physics-based or parametric models that allow them to design components across

disciplines. For example, a simple linear optics model can provide a physical understanding of how electro-optical sensors work, including the relationships between optical performance, focal plane array geometry and detection through identification criteria. Once the students get through the basic physics of the problem, they can use simple design parametrics to estimate size, weight and power (SWaP). The reason this approach is taken is to push students out of their comfort zones and to teach them how to deal with other discipline design issues from a math and physics perspective. Similar team design approaches are used for communications payloads and ground control stations.

Another more subtle objective of the course is to give students a more realistic view of how they should deal with

"authority". I don't know yet how well it works, yet, but when I play a "customer" role, I try to break down the traditional hierarchical professor-to-student classroom relationship. In real-world design rooms, engineers need to learn to think for themselves and to challenge (respectfully) and/or question things that don't look or sound right. Students are encouraged to speak their minds and issues are resolved openly and/or negotiated just as they are or should be in the real world.

Although the response thus far has been reasonably positive, areas for improvement are as shown in Figure 13. With the

exception of a graduate student teaching assistant who is typically focused on grading, more design interaction between undergraduate and graduate students is needed as is interaction with other faculty. Classroom facilities tend to be relatively traditional and are not very effective for computer modeling and simulation (M&S) intensive learning. Hopefully the other issues are self explanatory.

.

Figure 13 - Proposed Areas for Improvement

• Involve all students in hands-on projects/competitions • Provide opportunities for students to experience a longer term,

integrated curriculum approach to aerospace system design• Provide more physics-based, multi-discipline modeling and

simulation and inter-departmental interaction in the class room • Have design classroom facilities where students can interact with

instructors and other students in a real time M&S environment

• Have fabrication and test facilities with enough staff and through-put to accommodate student competitions and 2nd semester capstone design courses

• Be involved in competitions that emphasize real time system modeling and simulation as one product of the competition• Design-simulate-optimize-build-fly

• Provide academic, professional and financial incentives to teach

design and engage more proactively with students• Incentivize basic and applied research in aerospace system design,

integration and simulation (graduate and undergraduate)


VI. Conclusion

U.S. aerospace and defense programs are in serious trouble and experiencing unprecedented overruns in cost and schedule and unfortunate under runs in projected performance. For decades, Department of Defense (DoD) Selected Acquisition Reports (SARs) have pointed at engineering issues as direct causes of cost overruns that have averaged almost $100 billion per year for the last five years. In addition, indirect cost estimating effects of engineering overruns push that number upward. Prestigious committees have poured over the underlying issues and clearly identified improper application of SE principles as a cause. SE as documented in MIL-STD-499A is a systematic, rigorous and mature approach to engineering that has been successfully applied to complex programs going back to the Manhattan Project. The seminal 24 page 1974 document was elegant in its simplicity and applicability to everyday engineering. Written by engineers for engineers, 499 formed the basis for a rigorous, no-nonsense, approach to engineering until 1994. In the intervening years, SE has become a separate discipline that has more in common with program, contract and financial management than it does engineering. Today undergraduate engineers are entering the workforce with little or no understanding of even the fundamental principles of SE as they apply to everyday engineering. In this author's opinion, this is the educational equivalent of throwing gasoline on a fire. We need to bring a fundamental understanding of SE into the classroom and teach it as a fundamental principle of design. UAS systems are good "bite-sized" project that can teach undergraduate students about the fundamentals of SE design. If fundamental SE principles are not instilled in the future engineering workforce, our otherwise well-prepared students will join their colleagues from other engineering departments in adding cost, schedule and risk to already under-performing products and ultimately bring our once vibrant aerospace industry to its knees.

References

1 USD (AT&L), Quarterly System Acquisition Reports, US Department of Defense, 1985-2009,

http://www.acq.osd.mil/ara/am/sar/. 2 Kaminski et al, Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits

for Future Air Force Acquisition, National research Council, 2008, ISBN: 0-309-11476-4 3 Elm et al, A Survey of Systems Engineering Effectiveness - Initial Results, Figure 1, SPECIAL REPORT, Revision 1,

CMU/SEI-2007-SR-014, 2007 4 Chaput, A., “Advanced Product Development Program Systems Engineering”, Lockheed Martin Aeronautics Company,

Internal Publication, Fort Worth, 1995 5 C/AFSC, Military Standard-Engineering Management, MIL-STD-499(USAF), Department of Defense, Jan 1969

6 Fosness et al, Systems Engineering Handbook, International Council on Systems Engineering, INCOSE-TP-2003-016-02, Version 2a, 2004

7 Raymer, D., Aircraft Design - A Conceptual Approach, AIAA Education Series, 2009 8 Roskam, J., Airplane Design,Parts I - VIII, DAR Corporation, 1990-2003 9 Nicolai, L. and Carichner, G, “Fundamentals of Aircraft and Airship Design" Volume 1, AIAA Education Series, 2010 10 Chaput, A., "Rapid Air System Concept Exploration", AIAA ATIO Conference, AIAA, Fort Worth, Texas, 2010 11Chaput, A., Air System Integration – the Enabling Technology that Isn’t…”, AIAA-2007-3009, 2007, AIAA

Infotech@Aerospace Conference, Rohnert Park, California

Date post:	16-Dec-2016
Category:	Documents
Upload:	armand
View:	214 times
Download:	1 times