Reasoning your way through the FSAE design process

[Big Bird]

What's really surprising to me is the lack of desire to learn the 'truth'. A few minutes in Optimum Lap, or your own lapsim will tell you that pretty much everything you thought that mattered didn't. Many members on my team haven't made the slightest attempt to unravel their assumptions. Everyone wants to save weight, have massive horsepower, and have 'innovative' design. This is great, but none of these guys have taken the time to problem solve .

Really nicely put Max. "Unravelling assumptions" - so critical to building your flexibility as a designer. Your quote deserves a spot on the workshop wall...

[Bemo]

I'd say this is a bit like the discussion in the "Teams from India" thread about setting goals.
I've often discussed this with teams. All the time you hear stuff like "We wanted to save weight" "Our main target was a stiffer chassis".

No one really cares about these figures. First of all you want the car go faster, therefore you want your car to react to suspension setup, therefore you want your chassis to be stiff, therefore.....

I've read a couple of design reports in the past from various teams and this was in my opinion the major mistake almost all of them made. They started their text with goals for single parts of the car. No word about the overall goals of the car (quicker, more efficient, whatever you want). Everything else has to come from there.

And as you said Max unfortunately people very seldom think really carefully what the major issues for achieving to overall targets are. In Germany we have a say they get lost in details.

If you had endless manpower and time you could optimize every single part to the end, but no team in the world does have that (and no company in the world). So you have to priorize (does that word exist in English? ) what is most critical for you overall targets and focus on that stuff.

[Markus]

I've read a couple of design reports in the past from various teams and this was in my opinion the major mistake almost all of them made. They started their text with goals for single parts of the car. No word about the overall goals of the car (quicker, more efficient, whatever you want). Everything else has to come from there.

Bemo, it's worth noting that in some competitions (FSUK at least) it's always been implied that comparing to the old car (i.e. evolution) is a bad thing. I'd think the reason is that "quicker", "lighter" and similar comparative expressions are indefinite and proper problem solving begins by defining the problem. This might lead to teams avoiding such statements on the concept design level.

I agree that the top level goals should (must!) be mentioned as they're basically everything that's important and the rest of the design / decisions should be made to approach those goals. But the goals should still be definite.

PS. The word is prioritize.

[Bemo]

It's true that at most competitions design judges don't like comparisons between the old and the new car (at least in the design report).

But still it does not make sense start with specific goals for weight, chassis stiffnes etc. First of all you need to define, what kind of car you want to build. Anything else is just coming from this. It is not easy to do so (propably that's why most people don't), but this is the way the design process should follow.

In our team we defined the following goals which have never been a secret: Get the car done in time, finish Endurance, win the overall competition

These are the three goals all the subgoals have to be derived from. Of course you can argue how consequent this way was followed over the years, but in first place this is what we always tried to do. And we always told design judges exactly this.
From their you can start analysing what properties the car must have to score overall as high as possible.

You can set different goals. If your goal is to win acceleration or to win efficiency you will propably build a different car. But if you're honest, no one will ever start to build a car with the words "I want to have a car with an extremely stiff chassis".
But I've seen design reports, starting like this...

[Markus]

Originally posted by Bemo:
But still it does not make sense start with specific goals for weight, chassis stiffnes etc. First of all you need to define, what kind of car you want to build. Anything else is just coming from this. It is not easy to do so (propably that's why most people don't), but this is the way the design process should follow.

Exactly this. That one centence in bold is the important thing in reaching top positions in competitions. Yet it's still forgotten so often, even in top teams.

In our team we defined the following goals which have never been a secret: Get the car done in time, finish Endurance, win the overall competition

These are the three goals all the subgoals have to be derived from. Of course you can argue how consequent this way was followed over the years, but in first place this is what we always tried to do. And we always told design judges exactly this.
From their you can start analysing what properties the car must have to score overall as high as possible.

It is no secret either that we've always had very similar design goals.

Unfortunately our way of surviving generation-changes hasn't been the best which has kept us mostly off the podium despite the fast cars.

[Big Bird]

I still have a few things to add to my “thesis” here – will try to make them reasonably concise. Some of this stuff I have written elsewhere, some probably appears above and I’m too lazy to search for it.

If you look in any design textbook they will give a design process that looks something like the following:
Define project purpose / objectives
Define project resources
- Fully understand human resources (skills, availability), budget available, materials and manufacturing processes available
- Fully ascertain and understand available time
Define the problem you are trying to solve, and the criteria by which your solution will be judged.
Propose conceptual design solutions
Pick the “best” solution (i.e. the one that will best deliver on the solution judging criteria WITHIN THE CONSTRAINTS OF YOUR AVAILABLE RESOURCES – no apologies for shouting there)
Detail design your solution
Build it
Test it
Deliver it
Document it
(Iterate back and forth through the above – hopefully not too many times…)

I’ve been deliberately brief about the final few steps – if you have read the preceding pages you will know I’m more about the early planning stages.

Now, I propose there are two distinct categories of simulation :
1. Simulations that you learn about at uni
2. Simulations that are useful
These are in most cases mutually exclusive, and in fact a useful litmus test for the value of a simulation is to show it to your university lecturer . The more excited he gets about it, the less likely it will be of any practical use to anyone.

OK, so maybe I’m being a little too cynical here. But in my time at uni I learnt a lot about multi-parameter optimizations and FEA theory – but nothing about using basic maths tools for big-picture, practical decision-making. And that is because there was virtually no-one on the academic staff at my uni, or nearly any other uni I’ve been to, who knew how to do it (or was even interested in it, for that matter)

The three points in the design process where simulations are useful are:
1. Understanding your design problem
2. Selecting your conceptual design
3. Refining your design (the detail design stage)

I’ll group the first two points together as they require similar treatment. I’ll call them the conceptual design phase, whilst the third point is detail design.
Some contrasts:
- Conceptual design is concerned with big picture, whilst detail design is about individual components and, well, detail
- Conceptual design is concerned with finding the best return for your available resources, and breaking down the project into sub-system and component targets - detail design is about meeting the individual and subsystem targets
- Conceptual design is about estimation, detail design more about accurate calculation and optimization
- During the conceptual design phase, shoot anyone who uses the word “optimization”. During the detail design phase, do the same
- Conceptual design is about sensitivities to the major variables of interest, detail design is more about meeting absolute values. (For example, at concept design phase, you might work out that one percent weight saving might give “x” times the return of one percent increase in power – whereas in detail design you might be set a component mass target of, say, 150 grams which is measured absolutely.
- There is less likely to be a commercially available software package to help you with conceptual design (as you are charting your way through a unique and complex problem). Detail design is usually about meeting targets for well-defined variables such as mass or stiffness – and therefore more likely to be serviced by commercially available packages
- You need to get your conceptual design phase out of the way quickly, and you are at a phase in the project where you will have large gaps in your knowledge. Therefore your treatment of this phase needs to be simple and quick.
- Conceptual design is about gathering information, understanding the problem and making a decision. Detail design is about delivering on that decision
I hope I am making it clear that the different phases require different approaches. A simulation with detail design objectives has limited usefulness in the conceptual design phase.

I shan’t repeat much of the stuff that I have written previously, but we were designing our car we started by picking out a few major variables of interest (tyre grip, mass, power, drag coefficient, engine efficiency), and writing the simplest excel simulation we could that could give us an estimation of which is the most important parameter. We wanted to know the major sensitivities – whether one factor was an order of magnitude more important than the others, not whether one might give us 8.34 points while another might be worth 8.45.

More importantly, we wanted to gauge how important the major parameters were in comparison to how many points we were trailing the leaders. I harp on this point but still the point gets missed – if you find that 1 kg weight saving is worth, say 2 points, and you finished 400 points behind the winners of your last event, then saving weight isn’t going to put you on the top of the podium.

I suggest the following for teams embarking on a new design project
- Read and understand the criteria by which you are being judged for this project – whether it be points scored or laptimes or dollars spent
- Pick out 5-6 variables at most that you consider most significantly influence the final judging criteria
- Using mathematical tools no more advanced than Excel, and theory no more advanced than what you learnt in first year, write the simplest comparative analysis you can IN NO MORE THAN ONE WEEKEND.
- If anyone mentions the words “transient”, “absolute” or “non-linear”, quietly walk them outside and show them the guy who mentioned the word “optimization”.
- At the end of the process, define a measure of how important each variable is relative to each other, and relative to the overall pointscore you need to achieve.

The secret to winning:
Convince your own team to simplify
Convince your opponents they have over-simplified

Cheers all,

[Francis Gagné]

And that should be mandatory reading for every member entering our team! At our school we are lucky to have a major design project of 2 years, in which we follow a similar product development process. And the project gives great results, won Supermileage and FSAE Hybrid, made the first student built acrobatic airplane to fly in canada, flown a pedal powered airplane, etc. Though most of them have no commercial value... Which is something we should learn in school IMO. But unfortunately, most guys (and gals) only "gets it" on the last month before graduation when they reflect on their prototype and see their past errors and why they should not had cut corners on conceptual design, and further more on the feasability studies!

For my old team, they need to find a way to integrate the process more rigourously and bash it in the head of the newcomers, for us it is the hard part since our advisor is non-existent. But I think it is making it's way slowly I think, and thanks to you I'm not the only saying how important it is, there is hope

[dynatune]

Great Post Jeff and if I may permit saying so, welcome in the world of true managerial thinking. We as engineers tend to focus many times on the things that we think are important. Many times they are, but many times they are less important to the final results as we would like to admit to. Often, also because the scheme that defines the quality of our designs is not always as fair as we wish it would be. The big lesson here to be learned, is to learn to design for pleasing the final customer. This customer might not be as we would like him/her to be, but our product better should be. If the customer request best laptime that should be achieved, if the customer requires lowest cost that should be achieved too whether we like it or not ... I have participated in meetings in various OEM's where actually the "points" to be gained in various customer reports/ press journals were a solid division key on where to spend development dollars ....

Cheers,
Dynatune

[Big Bird]

Hi all,

This isn't specifically about the original "Reasoning..." topic in the title, but I thought I'd throw this into my "thesis" here as some added material - given team politics play so much of a role in team success - or failure.

This morning I caught up with Steve Price, our Team Leader from 2003, and I would say the best team leader I saw during my time at RMIT. We happened to start chatting about team structures and teams. Now we were fortunate to have a very good team in ’03, comprised of a lot of people who were friends before we were on the FSAE team. But the key points that characterized the ’03 team were :
- It was INCLUSIVE – EVERYONE was welcomed to the team, and invited to team bbq’s and the like – whether they were first year, final year, whether they were experienced or complete novices
- It was SOCIAL – Steve made sure that there was down-time each week for everyone to recalibrate / calm down / download / vent / laugh. ESPECIALLY to laugh.
- It was VISIBLE – We made sure that the uni staff, the students, the visitors, anyone who came on campus, would see the team operating – e.g. holding meetings in the caf at 5pm when all the staff would be walking by to go home, or
- It was WELCOMING – When new students came in, or when other uni teams were in town visiting, or when the uni had guests to be entertained / impressed, the team would be ready to roll out the welcome mat
- It was COLLABORATIVE – The vehicle was designed with guided input from all. For example, each Wed night we would have a team CAD session where we would drag up the CAD model and visually explain design issues, shortcomings, automotive theory, etc etc. The senior students drove the development, but the junior students could sit in to listen / ask questions / learn.
- It was FOCUSSED – We knew our priorities, we knew what was a need and what were just wants – and we only attended to the needs
- It was CALM – Yep, sure there were stressful times - but the team did its best work when it remained calm under pressure – wherever possible!
- It was TEAM-ORIENTED – We were all there for the team’s growth and development – that no one person was bigger than the team, and that no one project year was more important than the others.
- It was FUTURE-ORIENTED – We were building the team for future success. Our year was the first of a three year plan, and we had the people who understood this and were happy to curb their own ambitious designs in order to just get a result for the team and the experience on which we could build better cars in future. (This is a big one – many teams I speak to now over-design and over-commit for THIS year, because, well, we’re graduating at the end of the year and we want to leave our mark on the project.)
- It was RESPECTFUL – Yep, we sure took the mickey out of each other, but the over-arching culture was one of respect – that the management were doing their best, that everyone was feeling out of their depth at times, we were all in this together, and that when a decision was made that was that – and that arguing further was detrimental to the project.

The result of all this was that students would come to the team and want to do something for it. Work would be done for the team’s benefit, and for the joy of being part of the process – not because there was some sort of obligation or threat.

The key points were the last three I guess. The team members took joy from the trajectory the team was on, and there was a distinct long term focus. Thus when we did win events, for example in 2006, the 2003 team members felt they were just as much a part of the celebrations as the competing team members. I see this in a select number of Australian teams at the moment, and will be very keen to see how their results go in the next few years.

Good things happen when the focus goes from one’s self to one’s team, and to its ongoing success.

On the other hand, when a team starts to go on a downward trajectory, a lot of the above goes out the window. A few bad results can see a good team set up its own self-fulfilling downward spiral, particularly when the above points are jettisoned because the team doesn’t have time for … (social events / hosting other teams / training first years / politeness and respect, etc etc)”

I've been watching a few teams over recent years, and have noticed some interesting (and consistent) trends. As performance/results in the FSAE event begin to drop away, pressure begins building and the “fun” factor begins to drop away too. A result of a bad finishing position is often a commitment to "try harder". In one specific example, as a previously successful team started getting some less spectacular results, the team culture changed from one of encouragement to one of criticism and ridicule. If you didn’t match team leaders for the number of hours you spent in the workshop, then you were crap. As the enjoyment fell away, team enthusiasm dropped off, team membership dropped off, and thus the team leaders were left with even more work – and so on.

The trouble with the “just try harder” culture is that it just wears everyone out. It is not sustainable.

If your yearly plan necessitates your team members to work on the project every day, and every spare minute, then you have prepared the wrong plan. If your culture is one of suspicion and ridicule whenever someone takes a day off or does something wrong, you have the wrong leaders.

The focus should be on working smarter, not harder. This of course comes back to knowing your priorities, which means understanding the design problem you are facing. There, I think I've now linked this back to the original topic....


I suspect a lot of the above is stating the obvious, but I’m seeing a few cultural issues within teams causing problems and thought the above might help some.


Geoff

[Z]

- It was TEAM-ORIENTED – We were all there for the team’s growth and development – that no one person was bigger than the team, and that no one project year was more important than the others.
- It was FUTURE-ORIENTED – We were building the team for future success. Our year was the first of a three year plan, and we had the people who understood this and were happy to curb their own ambitious designs in order to just get a result for the team and the experience on which we could build better cars in future. (This is a big one – many teams I speak to now over-design and over-commit for THIS year, because, well, we’re graduating at the end of the year and we want to leave our mark on the project.)

Geoff,

I am 1,000+++% in agreement with all of your post above. I consider the above-quoted section as especially important (as you also noted), so thought it worth repeating.
~~~o0o~~~

To all Teams who want to do well in FSAE, please consider the above post very deeply, before you even start thinking about that new gee-whiz feature you are going to add to this year's car.

And note, of course, that the above principles also apply on the football field, and in business, and in any sort of real-life competitive situations.
~~~o0o~~~

To re-restress the point...

...Thus when we did win events, for example in 2006, the 2003 team members felt they were just as much a part of the celebrations as the competing team members.

So that was a multi-year plan, based on TEAMWORK, PERSISTENCE, AND A LONG-TERM FOCUS on being the best team in the competition...

Z