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.
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?
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?
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?
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?
Discussion of above process
There is nothing particularly ground-breaking about any of the above, and I hope I haven’t trivialized all this or bored you with statements of the obvious. However I personally think it is really important to break down this complex project into its constituent parts, and know how where each sub-problem ties into the project as a whole. Being part of the leadership group in our team years ago, we were faced with all manner of issues to deal with: budget and time management issues, workshop access, setting performance goals, design queries about individual components, packaging conflicts, tooling purchases etc etc etc. We certainly couldn’t solve these problems and make decisions without knowing where to file them and how they all linked into each other in the overall heirarchy.
I’ve made a few simplifications with the above process. Most notably, you could easily split up Levels 1 and 2 even further, into components integrating into sub-systems then integrating into the full vehicle. That is up to the individual, but probably not too relevant to my following argument.
I won’t bore you with too much analysis of Level 1 component design, as there are plenty of books out there on vehicle technical design. We should all be reasonably aware of what goes on here, our universities tend to focus on this for our engineering training and most of us should know how to use engineering software and even how to design and build individual components. This level is where most of the hard edged “science” takes place, (although even at this level we need to use some judgment, e.g. weight vs stiffness vs material cost vs manufacturability….). There are probably plenty of people around a uni who can offer you advice about component level design. It is also the level of design where you can spend lots of time and effort refining, for rather small gains overall.
Level 2 vehicle integration is where things start getting interesting, and this is where the good teams begin to shine. This is how, for instance, how your diff choice or your inner wheel packaging interacts with your suspension geometry, how all the suspension system ties in with the chassis, how power delivery matches up with tyre grip characteristics / chassis geometry, etc. In my year, we learnt some interesting lessons about integration when our choice of 10” wheels, large camber gains and floor mounted shock absorbers (all justified at an overall vehicle level), resulted in next to zero shock movement. We had to make some rather ugly tetrahedral upper a-arms to get around it, but we learnt from it.
Visually, you can get an idea of integration by how well load paths are fed into the chassis, or how the various controls sit comfortably with the driver. Teams could possibly assess their success at this level in terms of the overall handling of the vehicle, drivability, and overall track speed. Certainly when you see a Cornell or a UWA on track and at their best, you can see the effects of a well integrated vehicle.
Getting your Level 2 vehicle integration right is a pretty complex task, and is certainly not achievable simply by optimizing all your Level 1 components and then bolting them all together. Personally I found this Level 2 stuff to be the most technically challenging of the tasks that I faced, as it requires wisdom that you just don’t have as an incoming FSAE designer. Experience is the key and assistance and advice from alumni and design judges can be a wealth of information in this respect. (I am loath to say, that your academic support at uni might not be much help at this level. Once again, most academics are hard edged scientists / researchers, and their expertise is usually more about depth than it is about breadth. They are not often too helpful when trying to reason your way through a complex maze of competing priorities).
Level 3 is where this particular competition gets interesting, and where I would say the greatest gains can be had for the least impact on your time and money. I’d also say that it receives the least attention of the majority of teams, as it seems many have already decided what their overall design “answer” is before they enter the event (usually “we’re going to build the fastest lightest most powerful car and blow everyone to the weeds”). The organizers have developed a clever set of rules that not only reward vehicle speed, but also some “non-racing” parameters such as fuel economy, cost, manufacturability and even knowledge and ability to communicate. It gives teams who may lack the resources to build a full on mini-F1 a chance to compete, but at the same time it makes the competition possibly even more complex than F1 (i.e. vehicle speed and lap times aren’t the sole measure of success). Making some effort to understand the conflicts that are inherent in the rules and the scoring formulae goes a long way to developing an integrated strategy that scores well across the whole competition. I will address this a little further later in my ramblings.
Level 4 Project Management is just that – it is the set of tasks that ensures that the whole team works together, that deliverables are delivered in a timely manner, that key relationships are maintained with outside stakeholders, and that future teams’ chances of success are enhanced by this particular project. Level 3 competition success is an important factor, but not the only factor to be addressed at this level. Did you complete the project on time and on budget? Is your university happy with your year’s work? Are your team members / workshop staff / sponsors and supporters happy? Did you manage to put a decent effort into all parts of the project (e.g. both dynamic AND static events)? Have you enhanced the prospects of future teams by your effort? These are the sorts of questions that define success at the project management level.
Measures of success at each level
When you break a project up into the four steps above, you can then make sense of how to measure your progress at each level. As engineers we should be letting data make decisions for us, so it is important to understand what measures are relevant.
Level 1: Typical engineering detail level performance parameters – masses, power figures, coefficients of friction, stiffnesses, natural frequencies, damping coefficients, piece costs, etc
Level 2: Whole vehicle level performance parameters: acceleration capabilities in each direction (forward, lateral and braking), fuel consumption, whole vehicle cost
Level 3: Competition points scored
Level 4: Management level measurables – key ones I would suggest being time, money and goodwill. (I have no idea how you measure goodwill, but I’d still call it a measurable as we can get a sense of whether it is increasing or decreasing).
From the above I’d hope it is apparent there is a bit of a “flow” occurring between levels. The individual pieces with their masses, stiffnesses, power outputs etc, all come together at a higher level to give us a complete vehicle with certain acceleration & fuel consumption characteristics. The whole-vehicle performance characteristics then tie in with our static event skills to enable us to score a certain amount of points in the competition. The number of points scored can then be tied into the dollars and hours spent to determine the overall value of the project (I’d suggest dollars / point and hours / point being the most useful tools at this level).
It is our job as designers to try to understand this flow, and how the relationships work between different variables and different levels so that we can make wise decisions that give us greatest return for our own given resources. Many of the mistakes we make come from not taking the time to understand some of these relationships, or assuming some of these relationships are obvious or given.
I’ll come back to this later, but note that many of the parameters that are often used as outright deciding factors by many of us in our projects, such as mass & power, are deeply buried in the detail design of level 1. If your team management is making project level decisions based on Level 1 parameters (e.g. “this year we need to lose 5kg” or “this year we need another 5hp”), then either your management is fluent in the way that these values convert across the various levels to dollars per point and hours per point, or they are misguided.
The design path
In a complex project like this, you need to construct yourself a logical pathway that neatly weaves its way through the above levels of integration. You certainly can’t start at level 1 component design and then work your way up. I would say a successful vehicle project plan would look something like this:
1. Establish Level 4 Project goals and constraints, defining your measures of success for the overall project
2. Develop Level 3 competition strategy outlining what resources will be attributed to what events
3. Develop Level 2 vehicle performance goals based on your competition strategy, detailing whole vehicle and sub-system goals
4. Design Level 1 components to suit sub system and vehicle goals
5. Manufacture Level 1 components and assemble into working whole
6. Test vehicle to see how it matches up to Level 2 vehicle performance goals, developing as required
7. Compete at event, in accordance with Level 3 strategy previously determined
8. Finalize project, comparing final outcomes with initial measures of success and reporting to key stakeholders accordingly.
Notice how the process follows a bit of a “V”. We start with top level project goals, work our way down through all the various levels to define our individual component goals. We then work our way back up through to the higher levels, at each level cross referencing where we are, to where we had planned to be. The plan might be a little simplified, and we may very well do a bit of back-and-forth at the middle levels as our project might not work out as we had wanted, but the basic process is there.
Determining a Competition Strategy
From my observation over the years, I’d say that a large proportion of teams have very little idea of how to deal with the middle levels of the project. Many come in with roughly thrown-together ideas of Level 4 project goals (e.g. “We’re going to blow everyone away”) and then barge straight into Level 1 detail design decisions (our car needs to be 190kg, we need a Honda engine, do we want a turbo, our uprights need to be CNC’ed 7071 aluminium, what diff should we use, we really need a carbon tub, etc etc etc). The level 2 & 3 reasoning are mainly glossed over on the basis of a series of untried assumptions.
I believe the greatest understanding of what is important in this project can be gained by some reasoned analysis at level 3. We have a very tightly defined set of rules that set out what sort of track we are competing on (70 metre long straights, slaloms of defined spacing, average speeds, etc), and we have a set of point-scoring formulae that tightly define how well we will score for given performance outcomes. Competition results can give us a good idea of what sort of longitudinal and lateral g’s these cars can achieve, and we can usually find some sort of track map with a bit of searching too, so we can’t argue we don’t know what we are in for.
The competition rules are too complex to make absolute generalizations like “more power is better” or “less weight is better”. In some cases we have conflicts directly related to the performance of the vehicle (e.g. more power can drive down lap times but can also drive up fuel consumption), in some cases the conflicts are less direct (less weight can increase track speed but can tend to decrease vehicle robustness and reliability). FSAE is all about finding balance, and you will not find that balance point if you can only think in absolutes.
When sorting out a strategy at this level I think it is important to stand above the specific technical details of the vehicle and look at the design on a very basic level. You are looking at the car at a conceptual level, and the goal is to establish whether a car of “x” kW and “y” kg will score better than a car of “a” kW and “b” kg. Is your strategy to try for outright straight line speed, or cornering speed, or fuel economy, or some middle ground with a bit of each? We are basically looking for trends in the rules, and specifics such as gear ratios or suspension settings are not particularly relevant at this level. (For example, when you are considering the choice between a 165kg single and a 200kg 4 cyl, it is not worth worrying about specific gearing ratios or suspension geometries of the two options because either can be optimized when you get further into the detail design). The essence of good decision making is in reducing a complex problem down to a limited number of variables that you can deal with, (and of course picking the variables that are going to give you the most useful info).
The best few hours work I ever did in this project was to set up a simple lapsim to see how longitudinal and lateral accelerations affect laptimes, (i.e. taking the level 2 vehicle performance outputs, and seeing how they affect level 3 pointscoring). The first lapsim I did was really simple – breaking up an autocross/endurance trackmap into a series of straight lines and circular arcs, assigning appropriate lateral and longitudinal accelerations (assuming constant accel), and then finding laptimes. Change acceleration values, see change in outcome. Although very simple, it was one step up from simple “more power:weight ratio is better” reasoning, and gave some really useful results. For example, according to this simple autocross/endurance lapsim:
- A 10% increase in lateral acceleration gives approximately 8 times the points return of a 10% increase in forward acceleration.
- A 10% increase in lateral acceleration gives approximately 14 times the points return of a 10% increase in braking deceleration
(I have no concern sharing these figures, because people like Pat Clarke or Claude Rouelle aren’t going to believe you unless you can prove it yourself. Or come up with your own lapsims that disprove me. Just do it).
Although every model is an abstraction of reality in some way, (in particular this lapsim didn’t cover transients, and assumed constant forward accel whereas we are usually diminishing along the straight) I was confident that the figures were at least ballpark. Average speeds were around 55kmh, max speed was 100-110kmh, laptimes were around a second off from actual event times, WOT time was around 17%. So there were enough “ticks” there to indicate that we weren’t way off the ball.
Note that by analysing how accelerations in each direction are affecting pointscore, we are completely removing the means by which we are achieving these accelerations. Therefore we are clearing our mind of details like whether the vehicle is a 600/4 or 450 single, or carbon tub or spaceframe, or any other design details that may be clouding the argument.
Once you have a rough acceleration-based lapsim, you can start to extend it incrementally to incorporate lower level data. Do whatever you want, but at this point in time my own lapsim inputs include overall mass, engine power, tyre grip coefficients in each direction and tyre load sensitivity, rear axle load under acceleration, frontal area and drag coefficients, and engine thermal efficiency; and outputs are times and pointscores for each event, % time grip limited and power limited, min and max speeds, fuel used, and maybe a few other things I’ve forgotten.
(One of the important things is to model fuel economy. Hard to do exactly, but as a start I broke it down into an overall energy load, [including kinetic energy, drag and rolling resistance], and an estimated engine thermal efficiency. Knowing petrol is around 44MJ/kg, and is around 0.7 kg per litre, you can get an idea of litres used. Presently my model predicts around 2.5 litres for the RMIT car, and around 3.2 litres for a UWA style car – which is pretty well representative).
The importance of going through the above is that you can start to get some idea of how your level 1 detail design decisions affect level 3 competition scores. If you know how a 1kg weight difference or a 1kW power difference affects overall scores, you can start making informed decisions on your overall strategy based on engineering data, rather than “we need to lose 2kg because University X is lighter than us”.
You can also start reasoning your way through some of the more complex issues related to this event. Rather than simple arguments like “we have to have engine X because it the most powerful”, we can start to be a little more refined:
“We use engine Y. It has 10kW less than engine X, and this costs us approximately 30 points in straight line acceleration across the dynamic events. However engine Y weighs 10kg less than engine X, and this gains us 15 points in cornering performance. Also, the lighter weight and lower speeds save us 10 points in fuel economy, and the cost saving saves us 5 points in the cost event. Therefore we are at no potential disadvantage to engine Y, and the time saving from this simpler design gives us more time for driver training and testing”.
(The figures might be a little different, but that last argument is heading in the direction of where we were going at RMIT a few years back).
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.
On that note I might call it quits for now. There is plenty more to go depending on when I find the time, and whether or not anyone cares to read any of this (full marks for getting this far if you have). Any comments or feedback most appreciated.