Reasoning your way through the FSAE design process

[carbon_black]

Geoff, a great analogy but I'm left with the mental image of George and Gary shouting out during the design event: '10 minutes left - design like you've never designed before!'.

[Big Bird]

Maybe Ron Tauranac and Pat Clarke could design a car, we drive it and have to name the ingredients.
"It is definitely a 600/4, sounds a bit raspy - is it a Kawasaki?"
"When you brake into a corner it seems to want to turn out - that would be a diff mounted rear brake".
"I jumped on the brakes and the whole front corner sheared off and steered me into a tree. I'm now on life support. That's rod ends in bending, isn't it Pat?"

[Big Bird]

This might seem a gratuitous "bump", but I've been thinking of ways to make the below less verbose:

Level 4 - PROJECT-LEVEL MANAGEMENT
Level 3 - COMPETITION LEVEL INTEGRATION
Level 2 - VEHICLE LEVEL INTEGRATION
Level 1 - DETAIL AND COMPONENT DESIGN

Try this:

Level 4 - PROJECT
Level 3 - PROBLEM
Level 2 - PRODUCT
Level 1 - PARTS

It might make it easier to explain to newbies and the like.

Cheers,

Geoff

[bob.paasch]

Originally posted by Big Bird:
This might seem a gratuitous "bump", but I've been thinking of ways to make the below less verbose:

Level 4 - PROJECT-LEVEL MANAGEMENT
Level 3 - COMPETITION LEVEL INTEGRATION
Level 2 - VEHICLE LEVEL INTEGRATION
Level 1 - DETAIL AND COMPONENT DESIGN

Try this:

Level 4 - PROJECT
Level 3 - PROBLEM
Level 2 - PRODUCT
Level 1 - PARTS

It might make it easier to explain to newbies and the like.

Cheers,

Geoff

To me, level 4 is about organizational design. How about:

Level 4 - PROCESS
Level 3 - PROJECT
Level 2 - PRODUCT
Level 1 - PARTS

[Big Bird]

Yeah, I'm comfortable with that.

My obsession with the "problem" phase though is that many seem to assume they know what the "problem" is, and jump straight from project (we're gunna do FSAE...) into product and part design. And a solid analysis of FSAE rules and pointscoring can reveal some surprising results, (and some surprisingly achievable competitive solutions).

I assume Bob that you include detailed problem analysis as part of Process?

Monash seem to be the only team here in Oz (that I know of anyway) that are following a truly points-driven design process. Check results in Oz over recent years...

Thanks Bob, and sorry to hear about Endurance in Cali.

[bob.paasch]

Originally posted by Big Bird:
Yeah, I'm comfortable with that.

My obsession with the "problem" phase though is that many seem to assume they know what the "problem" is, and jump straight from project (we're gunna do FSAE...) into product and part design. And a solid analysis of FSAE rules and pointscoring can reveal some surprising results, (and some surprisingly achievable competitive solutions).

I assume Bob that you include detailed problem analysis as part of Process?

When I wrote the above, I was thinking that my "Project" above includes your Problem, ranging from "we're gonna do FSAE" on the low end to "we're gonna score more points at comp than anyone else" on the high end. Mostly just a semantic difference from what you had, but by calling level 4 "Process" I wanted to emphasis the point that the top level is more than just design project management.

But as I've had time to think about this since posting, I realize that point driven problem analysis comes in at every level of our design process. I can't separate out a Problem level. As part of our senior capstone writing requirements, our part designers construct houses of quality relating their subsystem attributes to overall vehicle performance to competition points. Technical leads are doing the same at the product level for the overall vehicle (invest additional design time in aero or engine or...).

At this point, the difference between Project and Process is unclear to me. Both describe the design of an organization capable of designing, manufacturing and testing a vehicle, and the design of a separate organization (using mostly the same people) that, several thousand kilometers from home, can execute in the static and dynamic events at competition.

So to answer your question, we are doing detailed problem analysis as part of Process, but also as part of Product and Part. With the rules and points breakdown, it's an absolutely wonderful thing FSAE has given us: a completely unambiguous way to measure product design, process design and organizational design success. Competition points.

I believe GFR's success these last two years has come in spite of rather than because of the collaboration between DHBW-R and OSU. To explain, although the advantages of combining the intelectual, physical, financial and human resources of the two universities are numerous, the additional overhead of managing and operating the combined team, in my opinion, outweighs the advantages. I believe our management is an order of magnitude more complex than that of any other team, and for that reason I don't foresee many other teams following in our footsteps. What the collaboration has done is force us to continuously evaluate and improve our organization and management processes. Plus we make design decisions based on points.

At both Michigan and California this year I spent a lot of time talking to other teams about organization and management processes. I tell struggling teams to build the simplest vehicle they possibly can, and focus on building good management processes, good project data archival systems, and an organization that promotes leadership training and technical continuity. And make design decisions based on points.

Monash seem to be the only team here in Oz (that I know of anyway) that are following a truly points-driven design process. Check results in Oz over recent years...

Thanks Bob, and sorry to hear about Endurance in Cali.

Disappointing for GFR, but nice to see ETS finally win one after getting close many times. Plus, there are more competitions yet to come...

[BrendonD]

Originally posted by bob.paasch:
At both Michigan and California this year I spent a lot of time talking to other teams about organization and management processes. I tell struggling teams to build the simplest vehicle they possibly can, and focus on building good management processes, good project data archival systems, and an organization that promotes leadership training and technical continuity. And make design decisions based on points.

In 2010 MIS I was on the receiving end of this exact advice from a different Bob(Woods). I had inherited what was then a struggling team that hadn't been to competition in 2 years and was losing members and momentum fast. We did most of these things (the point sims are being developed this year). End result: we grew the team 300%, made it to competition with a working car, left with a mostly working car (fuel starve, d'oh...) and scored middle of the pack. I graduated, and the 2012 car is full steam ahead under the direction of the new guys who learned a lot this year. There's a lot of things I would have done differently if I could have done it again, but I can't, so I'll just store the lessons learned for my time as an alumni advisor.

[Big Bird]

What's your problem?

Greetings all,

I haven't posted on here for some time (mainly due to work commitments), but unfortunately for you good people it doesn't mean I've run out of things to say. Recent conversations, along with some posts I've read here, have got me thinking about how teams view the FSAE design problem, and how the team philosophy can make or break their FSAE project.

We often think of engineering practice as being applied problem solving, but in engineering design we are also actually choosing the problems we are going to solve. (And therefore when reviewing designs we should not only review what worked and what didn't, but we should also be taking responsibity for why we chose to focus on that design problem in the first place).

So my question:

What is your FSAE design problem?

What is your team's overarching design philosophy? What is the team's motivation? What are you trying to achieve this year? What do you think you need to do to be competitive? I'm going to work through a few of what I think are common misconceptions, but firstly I would propose the FSAE design problem can be summarized as follows:

"We need to score the greatest number of points we can with the resources we have available to us"

There are two key points here:

We need to remember that this is about pointscoring, and all our design decisions should be founded on what delivers the greatest points return. This may not necessarily match our ideas of the perfect racecar. Be comfortable with this.

We need to fully understand that a key factor in understanding the FSAE problem is knowing what we are bringing to the project, in terms of our skills, budget, facilities & support, available manhours etc. This isn't fantasy land, this is a real world problem which needs to be solved in real time. And we need to recognize that a design solution that is deliverable by another team may not be the right one for us.

I think it is important for the team to have an over-arching problem statement, for some guidance when you are faced with the inevitable detail problems and conflicts we all have to deal with. So with the above in mind I'll look at some common examples of FSAE "problem statements", and identify a few shortcomings.

"We want the fastest car" / "We need to build the fastest car".

Admirable as a partial goal, but a little flawed. Firstly, why do we assume that the fastest car will score the most points? How does speed relate to cost, economy, design understanding etc? For example, we might argue that a more powerful car might get us a quicker laptime. But if the laptime gain is 10 points , and in the process we lose 20 points in fuel economy and cost, was the design direction the right one? There is some perception that points scored for outright vehicle speed are more meritable or "cool" than points scored in for example the static events. But in reality points are points, and it doesn't matter where you get them.

And where in this statement are we considering our own capabilities to deliver? That is as much a part of planning a successful project as any ideas about vehicle speed. It is very easy to dream up a world-beating design if you don't worry yourself with how you'll build it. There is at least some implied reference to being able to build the car in the latter statement.

" We need to build the lightest car" / "We need to build the most powerful car" / "We need to build the stiffest car".

These goals are even more fraught than the previous - very narrow focus, and aiming for an end goal that has at best only an implied link to the FSAE rules. The argument is along the lines of "lightest car => fastest car => most points", and both of these assumed relationships can be argued to the contrary. The latter is covered above, and the "lightest car => fastest car" argument doesn't address stiffness, reliability, drivability, driver skill, etc etc etc.

There is no prize for lightest car. Bragging rights maybe? Should anyone care?

Once again, in the above statement no consideration is mentioned about the team's ability to deliver such a car. And in fact, having the most or the least of anything usually pushes resources to and beyond their limits - how many times has the lightest car at the comp not finished (or sometimes not even started) the competition weekend.

"We must build a lighter / more powerful / stiffer car than we did last year"

The constant improvement model, with the implication that for a project to improve on the previous year's effort the car must rate better on most or all of the key design measurables - weight, power, stiffness, etc. There is some paranoia that a car that is heavier, or less stiff, is absolutely inferior and must be avoided at all costs. I've seen this philosophy work, but I've also seen it drive successful teams over the edge. Be very wary.

For some years, our team had success with such a model. Each year from 2002-2006 we built a lighter car, and we had a number of wins and podiums in this time. The progression was roughly 250kg > 200kg > 180kg > 160kg > 150kg, and each year the team was motivated by the desire to outdo the previous team. Warning bells began ringing in 2006 when we started breaking silly things like steering wheel mount bosses, etc. In 2007, the incoming team gave themselves the daunting (impossible?) task of building a lighter, stiffer car whilst trying to solve the serious ergonomic issues of the previous cars, which were hopelessly cramped for the drivers. But the team refused to spend a couple of kgs buying some much needed driver space.

Then in 2008 the new cockpit template rules sent the team into a tailspin. The extra driver space was going to cost 1-2 kgs in chassis weight. This was just unfathomable, and much sweating and handwringing went into efforts to compensate for this extra mass - even though the 1-2 kgs might be worth 2-3 points at most. Design time blew out, more high-end materials and techniques meant greater pressure on human resources and facilities, stress levels increased, tensions between team members escalated, etc etc. The result - a half completed car, and event results started heading southwards. This trend of needing to "out-spec" the preceding teams continued, and the results have continued to suffer.

Sometimes your design problem requires backing away from "lighter / stiffer / more powerful". If you are finishing hundreds of points behind the winners, your major design problem / priority might very well be to build the car sooner, or stronger, or more cheaply, or with less resources. Often this will require some trade-off in mass, power etc to buy the required time, or to align with the team's skills and resources for this year's project. The designer's art is in knowing how far "backwards" you can safely go.

"We need to beat Stuttgart / UWA / Cornell /(insert-current-"IT"-team-here)..."

Personally, I hate using such philosophies as the core team driving force. It draws the team into comparing themselves to the target team, often leading to perceived resource shortcomings, and railroading the team's mindset towards specific design solutions, (i.e."Team X has spark-eroded unobtainium uprights, therefore we need them too if we are going to be competitive"). It is difficult to develop your own unique and holistic viewpoint on FSAE when you are obsessing over someone elses project. And anyway, what part of "we need to score the greatest number of points we can with the resources we have available to us" doesn't encompass the above? To beat them, you need to "score the greatest number of points you can...". And if your best isn't good enough, you are still better of scoring "the greatest number of points you can..." than otherwise.

That is enough for one night - I'll continue soon

[PatClarke]

Thanks Geoff

Pat

[Bemo]

Once more thank you Geoff for your thoughts. I couldn't agree more.