Reasoning your way through the FSAE design process

[Big Bird]

Greetings all,

I’ve been sitting down in the odd spare minutes I’m getting here and there, and slapping together a bit of a thesis about what I think of design, specifically in the FSAE context. I’ve written the odd wordy response here and there on these boards, but as with the nature of these forums they tend to get scattered in the morass of information. I figured I’d slap it all together in one place and see if it sinks or swims. Over the next few weeks or so I’m going to slap up a few different pieces relating to FSAE. It will be mainly to do with the philosophical side of the event, given there is a wealth of information here relating to technical design issues.

The following is around 4000 words or so. It might be rather painful at one sit, so you might want a beer or two to see you through.

My contention has always been that this even is won and lost on good management principles. Unfortunately we are not taught such things in our university careers. Rather we are mostly taught a collection of quite disparate facts relating to engineering science – and it is up to us to piece them together into some sort of greater truth. Therefore many of us blindly barge in with our bag full of engineering formulae and software skills, and attack an engineering design problem the way it is taught at uni. Given the repeated failure rates (usually around 60-70% fail to complete all events at most comps), and the large disparity in points across the top 10 at most events, I think that what we have been taught is falling short to some extent. This competition isn’t anywhere near as close as I think it could be or should be.

Whilst many of those attempting this project have excellent technical and analysis skills, something is getting lost between the design stage and the implementation stage. We are often seeing engineering as a purely technical exercise, whereas in a real project we have to take in a lot of outside factors that can conflict with, or even overwhelm, our technical aims.

The key point is that we have finite resources, and this is true of all project situations. Sure, in F1 the limit of those finite resources is somewhere up in the stratosphere compared to what we have to deal with, but even at that level the resources aren’t infinite. And when you are dealing with a finite resource base, then your design decision making process needs to reflect those limits. Not only do you have do decide whether a certain component or design will make your vehicle faster (if that is your design goal, but more on that later), but you also have to assess whether it is the most feasible direction for your team to find car speed

So rather than just say that “this is all about management” and leave it that, I’m going to try to put my money where my mouth is and convey what I consider to be good holistic design principles. I don’t consider myself to be a guru of any sorts when it comes to such things, but after viewing around a dozen of these events I feel I have seen enough common failure points to at least offer my thoughts. At least once I have committed all this stuff to screen, I might feel as though I’ve said enough and won’t have to bore you all senseless by hijacking your threads in future.

Design Management Structure
The following is a bit of a structure I’d follow as an FSAE vehicle design process. You’ll note that the thread I’m presenting below is focussed on the actual vehicle design itself, since that is what we talk about most in FSAE circles. Once you have read through it you might recognize that we could generate similar trains of process for the static events, and these would link in at the top end of the process. But I’m getting ahead of myself.

For the sake of readability I’ve labelled the below Levels 1 to 4, although this does not imply any order of importance – they are all significant in their own right. You might think of them as a design hierarchy, but I’d say each level has its own type of expertise required to make a success of this project.


Level 1
DETAIL AND COMPONENT DESIGN
This comprises design and manufacture of the individual vehicle components, and this is the level we are probably most comfortable with after our university training. This is the level where we are designing parts, calculating loads, masses, stresses, stiffnesses, heat transfer rates, etc. We are using typical engineering design and analysis tools such as CAD, FEA & CFD software, maybe engineering formulae, (stresses in shafts, bearing loads), etc. It is probably the area where we can best get advice from our academics, given this level requires expertise in specific areas, and generally academics tend to be people with deep expertise in a particular field.
Types of questions asked at this level: How do I make this part lighter? How do I make this stiffer? What material will we use? How do we manufacture this component? What physical tests do we need to perform on these components? Do we want a magnetic or Hall effect sensor for our crank angle sensor? What spring stiffnesses do we need?

Level 2
VEHICLE LEVEL INTEGRATION
This is where we are joining all the components together into a complete functioning vehicle. It is also the level where we identify conflicting goals that may arise between different components and sub-systems.
Types of questions asked at this level: What are our performance trade-offs at a whole vehicle level? How does our suspension geometry match up with our differential choice? How does our engine packaging tie in with our need for easy access and servicing? How do we address tradeoffs between engine mass and output torque/power? How do we address the conflicting demands of cockpit packaging and front suspension geometry?

Level 3
COMPETITION LEVEL INTEGRATION
Given the whole vehicle at level 2, how does this design tie in with our overall competition strategy.
Types of questions asked at this level: How do we score the greatest number of points at competition? What are the inherent trade-offs in our own design at event level? For example, how does our vehicle speed strategy tie in with fuel economy? Are there conflicts between our dynamic event performance and our static event performance? What are the risk factors that could possibly jeopardize our competition performance?

Level 4
PROJECT-LEVEL MANAGEMENT
This is the over-arching management of the whole project – how the competition performance ties in with other managerial level stuff like time and budget management, usage of human resources, etc. Functions performed at this level: Holding the whole project together so that you deliver this year, keep everyone reasonably happy, and hand over a healthy project to future teams
Types of questions asked at this level: What are our goals for this project? Are they feasible given our resources? How are we going for budget, time, material resources, etc? Are our key stakeholders (e.g university, tech workshop staff, sponsors, supporters, team members etc) happy with our project? How will our project affect future teams? Are our team members working in harmony? Are we leaving this team in a better state than we found it?

Remainder of this post found on page 19

[MalcolmG]

a very thought-provoking post, good work

I think breaking the project up into the 4 levels is a useful way of breaking up the tasks and objectives of the team, as I read it occurred to me that a very simple and probably quite effective way of defining the roles of people within a team would be to assign their responsibilities to a level. Using the management structure our team uses, you would have:
Level 1 - General team members
Level 2 - Subgroup leaders
Level 3 - Chief Engineer
Level 4 - Team Leader

And typically the goals for each level are set by the person responsible for the level above, e.g. subgroup leaders give team members briefs/instructions for component designs to help them achieve level 2 goals, chief engineer gives subgroup leaders performance targets to help level 3 goals be met and so on.

As I'm approaching the end of my final year in FSAE, I certainly wish I'd spent more time to get out of level 1 and 2 and put some good analysis into level 3. I guess the interesting thing here though, is that while spending time on the analysis of level 3 aspects of the design has the possibility of being very fruitful in terms of competition success, it's the details in level 1 which can make or break a competition, as the detail design will really be what dictates whether the car is capable of achieving any of the higher level goals, and obviously whether something fails in the middle of endurance - so it's not suprising that most teams will devote considerably greater effort to the lower levels. edit: although more high-level analysis would undoubtedly reduce the workload and add direction to the lower levels

[ed_pratt]

Kudos to Geoff!!

I think we've all been waiting a few years for this post!

I'm glad to finally see someone with some a wealth of experience sit down and write a fairly definitive (although i'm sure Geoff will protest otherwise!) top down explanation of how to do this project.
It's great for new teams and also really good for established teams to take a step back and have a good look at whether or not what they're currently doing is helping their cause.

I hope the mods sticky this one as I think it will alleviate a lot of the simple questions which seem to have been plaguing the forum recently.

Thanks again Big Bird.


Ed

[Jersey Tom]

That's excellent stuff, Geoff. Everyone should read that.

I totally agree, and think a particular note of importance is that design should be driven from 4 to 1, not 1 to 4.

IMO, 1 to 4 is "tinkering" whereas 4 to 1 is "engineering."

To save time you can certainly work on Levels 1, 2, and 3 simultaneously. The key though is that the high levels drive the lower ones, not the other way around. Using my Formula 1000 project as an example, I have spent a fair amount of up-front time on "Level 1" design, but in a manner that's easily configurable. I can have a rough idea of where A-arms, rockers, and dampers are going to fit and go together.. and once I determine my upper-level targets I can change a few sketches and the L1 components re-build themselves as necessary. You don't need to worry about what A-arm planes and specific hardpoints need to be.. when you define upper-level parameters they all fall into place as the only unique solution.

In my experience while doing this stuff, as talented as we thought we were, we barely had enough experience to really grasp the Level 1 part of things. Only a very few people really had any knowledge of REAL materials selection and manufacturing.. or stuff like the experience to avoid bare aluminum suspension spacers as they have the tendency to warp and gall and stick. Likewise there was always a learning curve regarding all the suspension and engine terminology, much less having in-depth real understanding of tire/vehicle dynamics.

As such we fumbled around at the 1-2 level, organized by a leader ("captain") who was taking their first stab at project management and inevitably wound up biting off more than they could chew. I readily admit I was no exception.

Given that most engineering curricula are geared toward developing a "Level 1" engineer, it is difficult to truly orchestrate a diverse, talented team that operates on all levels. At least from CU it would have been nice to have courses in systems engineering and management. I'd imagine the way to really develop people beyond the 1st Level in FSAE is to have lots of engagement at the underclass level, and work very hard on knowledge retention. Otherwise you're starting all over from scratch every year.

The other point you make that I really strongly believe in is to separate the high-level design drivers from the low-level details, at least initially. Start simple. I really like the example of building a simple lap sim that uses only peak acceleration values. Forget all the other crap initially. Once there's some comfort level with the basics, start moving incrementally toward more detail.

Overall a very good and well-written thread.

[VFR750R]

Originally posted by Big Bird:


Reality Check
The greatest lesson I learnt by working through the above process is how little effect the potential performance of a design really plays out on final results. For example, my own model indicates that a 1kg weight saving is worth around 1 point in the overall event. If we can see that for instance, a 5kg saving is worth maybe 5-10 points in terms of overall potential - and then we see that the top 5 in a comp may be spread by 200 to 300 points – it puts perspective on all that time you spend saving 1kg out of your chassis or a few hundred grams out of your uprights. And that if your team ended up 250 points behind the winner, or even 50 points behind the winner, it is not going to be a change in your vehicle’s performance specs that is going to bridge the gap.

Cheers all,

Geoff

I know I've been waiting years for someone to put some kind of number on points/kg.

Your post is what I'd call System Engineering. It is a master program at Cornell and the team works much the same way. We mostly look at the points system first and determine sensitive areas. In general we're looking for more power/less weight, but how we achieve those goals is often driven by a systems approach where we try to determine ahead of time our "biggest bang for the buck".
Project management is one of the most important areas for success because it's very easy to waste man-hours on things that don't contribute to the overall goals. And due to the limited number of man-hours all projects are prioritized.

Unlike Malcolms team we don't however have a chief engineer or single team leader. It stops at level 3 with a team committee of sorts. There is typically a team leader for each of the following; chassis, engine, electronics, and business. This is usually driven from the fact that no one person can be responsible for everything, nor is an expert in every system. It also means there is a specialist in each area present when hard team decisions are made. We do have subteams (and subteam leaders) in both chassis and engine, which report to the team leader in their area. The car is broken down to just about every last component, and team members are made responsible for those components. Subteam leaders need to know everything going on in the subteam so that at least two people are experts on every part. That way if someone can't be reached when there is a problem, someone else can be contacted. For some stuff this never is a problem, but for some electronics stuff there really may only be 2 people capable of troubleshooting.

I think not enough man-hours, and weight has been aimed at final tuning of the car in the past. With the tire consortium, I bet that this has been improved overall, but a lot of teams worry about every last hp when designing intake and exhaust systems, and then throw it way with a bad engine tune. Likewise on the chassis, our team struggled one year in doing simple toe, camber, and tire pressure matrices that are critical in taking full advantage of the tires. It's a lot easier to throw away 50 points then it is to find 50 in design.

[moose]

I agree here with everyone - I think that this should be nearly mandatory reading for anyone joining a team, and especially for those taking on any sort of leadership roll. While none of the thoughts are necessarily earth shattering, why its great is that its in a great, simple structure which helps drive home the point. We can debate all day over the individual points, or how its broken out, but the main message gets through very well - and really makes it a valuable read (just like the rest of your posts).

The hard part for teams, even that agree and want to follow this path, will be working this in to understand how to best manage all of the forces pushing them towards just doing what is easy in the momemt (#1) and the benefits of avoiding taking that path.

For instance - everyone knows that as much testing and prep as possible will certainly help with competition performance. So in response, with an eye towards getting the build moving, teams say "ok lets start designing and building as soon as possible". They then run off in 5 directions to get going by delegating work (if possible).

For many small teams, the core group of 2-3 probably feels it necessity to spend as much time "working" on designs/building as possible, rather than thinking about how to best prioritize and where the extra time spent by the best people on the team will yield the best results.

This is why some very small teams can do surprisingly well.. if you are just that short on man-power, you have to make these decisions, and spend a little bit of time thinking where can I spend time, and where do I have to just do something quick and dirty (or just buy it). At the same time, these teams will have 1-2 people doing all of the design so there is automatically a more holistic view of things.

Unlike a normal corporate environment, the people on the team taking the lead roles will also be doing a bulk of the work. Finding the time to really step back and spend a few hours at the start of every year/month/etc to plan and prioritize, in the same way as any compay does when it projects the next quarter's earnings, etc, and which divisions will provide that $, is something that really can be invaluable, and something that I can say I certainly didn't do enough of in my time. Having good direction at the lower levels of a group, makes doing work much faster/easier, as you aren't trying to think about what your boss/group lead is thinking about - but instead can focus on executing. We have all designed many quick parts standing at a mill, and it took no thought, because it was just a matter of already having all the main constraints set - and being able to do as much of that from the start of the project makes integration and moving forward with everything probably that much easier and faster


Matt

[murpia]

Excellent post Geoff.

Just one thing I'd like to expand on:

In between Level 1 and Level 2 is what I believe to be the single most effective way to build a good racecar: minimising the parts count. Parts you don't have weigh nothing and cost nothing and cannot break.

I'm not suggesting another level to the Systems Engineering approach but it's important when cascading out the design from Level 2 to Level 1 that you don't have too many parallel paths.

I don't have much time to discuss further today but I wanted to get the comment in ASAP. I have in the back of my mind a 'thesis' on the Minimal Parts Count Racecar. One day I'll have the time to write it.

Regards, Ian

[PatClarke]

Thank you for that post Geoff.
Hopefully it will be 'stickied' for all new teams to find easily.

Cheers

Pat

PS, I emailed you at your RMIT address earlier today.

[Mikey Antonakakis]

Geoff, thank you for that post. Trust me when I say I'll be doing a lot of thinking about that this week (when I should be studying for two midterms haha).

Having read it, I can say there are some higher level things I already do/do automatically, and some that I never really thought about. Your post will help me figure out how to fill in the gaps. Being good friends with both of our past chief engineers (one graduated) has certainly helped. The way we are structured is:
-Team members
-System Heads (including a new system, sponsorship/fundraising)
-Chief Engineer and President (CE being in charge of design, president in charge of administration, although both of us being MECE juniors means that we do a lot of consulting, and he is chassis lead)
We have traditionally been a "small" team, with usually 10-15 solid members at any point in the year, but this year we grew quite a bit, and I can say that going from being the only engine guy to being trusted with heading the entire design (now with, say, 20-25 solid members, many freshman) is almost overwhelming. I already have some clear ideas of how I would do things differently, given a second chance at this (I DO have another chance, if the team wants me to be chief engineer again next year). We are having to make compromises at this stage that I was hoping to avoid, but the project must move on.

I hope this gets stickied, it is probably the single most valuable post on these forums (of what I've managed to read so far).

[J. Vinella]

Thanks for the post Geoff. It was a good read and I have to agree with you on many of your major points.

The only thing I would add is...have fun!