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
 |
|
|
Reply With Quote