I know that the car makers all do crash tests on computers before they ever build a car and now only slam cars into walls for legal reasons, but I’ve not heard what types of software or what kind of machines they’re running them on. Anybody know?
First of all, disclosure: I’ve done some consulting work for the automotive and off-road equipment industry in this regard, and I’ve used a couple of the following tools with a moderate level of experience, but I’ve no claim to being an expert analyst.
Most automakers (or rather the consulting companies they hire to do analysis–you’d be shocked to find out how little engineering is actually done by a car company) use either LS-Dyna, which is available as a stand-alone code or integrated into Ansys (a suite of analysis codes that do everything from simple linear structural and thermal finite element analysis to highly complex nonlinear multiphysics simulation), PAM-CRASH or Abaqus Explicit. Which one selected depends on the specific application and more importantly, the experience of the engineer doing the analysis, but while LS-Dyna has been around longer, AE is becoming more common owing to greater flexibility and large library of Python code to modify standard modules, and PAM-CRASH is an industry-specific code with a lot of tools designed for simulating automobile structures. There’s also a code called RADIOSS, which I’ve never seen or used–I guess it’s used pretty widely in Europe, but that’s all I know about it.
Most pre- and post-processing–that is, setting up the model and reviewing the results of the code–in American automotive is done using Altair HyperWorks. This is a twisted and very quirky but outstanding tool for doing preprocessing work; Altair is one of the larger structural consultants and they ended up creating this tool because they weren’t satisfied with the CAE and visualization tools that were available from structural code companies.
In the past the simulations were run on high speed dedicated mainframes, high end Unix servers like the SGI Onyx, or when the time is available, supercomputing facilities (there is, or at least was a program through the SBA that made supercomputing time available to small companies for peanuts), but these days its easier and cheaper to run the sims on a Beowulf cluster or for a small job even a powerful desktop station overnight. The bottleneck typically isn’t processor speed but cache size and memory access time. At the aerospace contractor I work for we’re actually obsoleting our SGI and Solaris servers in favor of a couple of Beowulf clusters for big jobs.
I do want to correct you on one point, though: you say “I know that the car makers all do crash tests on computers before they ever build a car and now only slam cars into walls for legal reasons”, implying that physical testing is unnecessary. While the simulation tools have come a long way in the last few years (these things bascially did not exist a decade ago) they’re still a ways from totally replacing physical testing. The reason for this isn’t that the code can’t effectively simulate complex nonlinear behavior like buckling or deformation–the capabilities of these codes are amazing in that regard–but rather that the results of the analysis are only as good as the assumptions in the model. For instance, with a hydroformed monocoque chassis, you’ll assume a pre-stress in a given area due to forming (this coming from a different simulation) and apply material properties and thickness from that; however, until you actually form the thing, you may not know exactly how it is going to come out or what variations exist in the process that will affect the structural integrity of the piece. Similarly, you’ll start with an impact scenerio–say an oblique forward hit at 35 mph or whatever–and make some assumptions about what piece will give way first and how fast, or that the engine (typically modeled as just a rigid point mass attached at the bracket locations) doesn’t move or give way, or whatever–and set up the parameters and timestep for analysis accordingly. This may or may not represent an accurate assessment of the situation, and only physical testing and correlation will confirm the validity of the analysis. Computer simulation is best used to iterate and optimize to a best design solution before building physical hardware.
I only make this point in such detail because I’ve been subject to a number of bosses and customers who think that by performing some gee-whiz pretty picture stuff on the mystery machine we can forgo any physical testing or prototyping. The reality is that, as the old saw goes, with computer modeling and simulation tools, it’s all GIGO–garbage in, garbage out–and a single bad assumption or overlooked factor can completely invalidate the analysis.
It reminds me of a design & manufacturing meeting I was once in where my boss, the Director of (Design) Engineering, and the VP of Manufacturing were yelling at each other about a warped part (a welded box structure). My boss kept screaming that our design was fine on the screen and that it was all a “process problem”; the VP of Mfg. kept trying to explain that the difference in wall thickness between various parts of the structure was leading to an irresolvable warpage due to welding. FTR, the manufacturing guy was absolutely right, a fact the designer (not me, but it could have been) would have known if he’d talked to anyone with any experience in welding; one does not weld .125 sheet to .500 plate with a single fillet and expect a straight, unwarped piece.
Anyway, simulation is all well and good in the design house, but out in the fleet, you actually need to beat on things and make sure they’ll hold up before you drop them in the drink and claim they’ll float. The automotive companies spend a lot of money on physical testing–not just crash testing of bodies, but all sorts of parts–and that won’t be going away any time soon. It’s easy enough to overload a detail in an analysis, but when your seatbelt mount rips out of the B-pillar and sends the CTD flying through the windshield, there’s no covering that up. Additionally, the more recent versions of CTDs–the Hybrid III and successors like THOR and SID–are heavily instrumented, giving not only information on the gross effects of vehicle impact but a good estimation of real-time effect of instantaneous acceleration and jerk on the occupants. This, too, can be done by simulation, but ultimately you’re going to want to verify that your pricey side-impact airbag system actually works and doesn’t cause more injuries before you start promoting it as a feature.
Anyway, the tools exist and are widely used, but the process isn’t exactly a turnkey, trained monkey one, and the results are considered fairly reliable predictions of structural behavior, not an absolute panacea to replace physical testing.
Stranger
(Wow, I feel like I don’t talk to Stranger On A Train enough.)
While I don’t know what software “the CAE guys” use, I participate in the process from time to time. It’s of utmost importance that there be no illusion that CAE is a substitute for performing real crash tests. There are invariably suprises that crop up and need to be investigated. While we manufacturers are all scrambling to cut costs everywhere, performing crash tests is really a very low cost activity given the entire budget for a complete vehicle program. Yeah, if you could eliminate the entire infrastructure behind every crash test then there would be significant savings. Given our penchant for outsourcing, I don’t think this is a bad idea in the long run – why couldn’t Toyota, GM, Ford, and Daimler all share a single contract facility? Oh, wait, we do a lot of that, too, now that I think about it.
Also, vehicle structures really do have a lot of standardization, and product designers really have an intuitive feel for what probably will work versus probably not work. So, CAE will confirm these gut feelings. CAE is also handy for new structure technologies where previous experience doesn’t exist, such as for hydroformed front structures. But in cases like this, real crash testing is even more important!
That’s not to downplay the importance of CAE. Without it, we’d have to crash many, many, many more vehicles just to confirm the mundane, every day decisions that product and manufacturing engineers make on a daily basis. For example a crash test of a subsidiary product last year, there was some metal malformation contrary to what CAE predicted. When corrections were made to account for the failure mode (“failure mode” doesn’t mean failure; it simply means a non-expected behavior; just like all of the lawyers here, yes, I’m compelled to point out the difference.), it was easy to propose several potential solutions and virtually test their effects without having to crash 30 vehicles to do it. Once a solution was proposed, its study would be tested on the next scheduled crash test vehicle. If the solution were successful, then no additional vehicles were sacrificed (as this was a scheduled test). If the solution didn’t meet expectations, duplicating the failure mode in CAE would start the cycle over again for study on a regularly scheduled crash test. No additional waste, and this is worth mega-mega-mega bucks to the companies.
Oh, CAE is “computer assisted/aided engineering” which is really very broad. In my particular company, though, its use if my field is always exlusive to meaning “the computer crash test guys.” I use a computer to assist in my engineering, but it’s not CAE :).
Oh, I just find this kind of interesting: the CAE people often can tell us the consequence of a particular failure mode given the 95th percentile customer. For example, in the case above, no injury to the passenger would result. In another case (for which the failure mode has been eliminated) the CAE people would tell us (for example) a single fracture to the right tibia of the driver. I don’t know how accurate this data is, but it kind of puts a nice psychological pressure on the product engineers as to why they must make a change.
I can’t answer the OP in terms of the latest and greatest as Stranger has done but I can lend a historical perspective. I am not an ME but I did some software work at Ford in the 1979-83 range, in CAE and test crash analysis (they didn’t like to call it “crash” testing; they were “barrier” tests). We had an in-house body design graphics system, as well as a copy of NASTRAN. NASTRAN was a finite element analysis tool developed by NASA that we used for some structural simulations, though not a whole crash (too complex). I made a software mod that added a new element, but it’s been too long to remember any details. I think we used it primarily for static tests of sheet metal body parts, where a part would be placed under a static load until it fatigued (not sure if this is a technically accurate description; remember, IANAME). IIRC we ran it on a CDC Cyber, a supercomputer of its day.
(I am puzzled by the statement that simulation tools did not exist a decade ago.)
Ford spent lots of money on testing because you just couldn’t simulate stuff like steering column intrusion measurement. I worked on software that would allow them to combine multiple tests into one test run to save money–the cars were hand-built prototypes that were very expensive to smash into a concrete barrier.
In other safety tests, we had software that simulated brake fade. The software would allow engineers to simulate brake performance using different design parameters.
What I mean by that is tools to perform integrated explicit analysis–that is, the simulation of a whole car (or all significant structural components) in a dynamic, nonlinear scenerio (i.e. changing loads with timestep and plastic deformation of structure)–were not commercially available nor sufficiently mature to use for this kind of work; on top of that, the computation power to do this type of analysis was not readily accessible; this was back, of course, when everyone was oohing and aahing over the Cray Y-MP, which is now worth more for the salvage value than as operating hardware. Computer finite element analysis has been around since the mid-Fifties, but has traditionally been limited to single pieces or small, simplified assemblies of critical hardware for the aerospace industry; only in the Eighties did it start to be widely used in other industries (the automotive industry, for reasons of economy and scale, was one of the first to get into FEA).
Today, there are packages available for just a few thousand dollars and integrated into commercial CADD systems that can do more–in a simplified and kind of idiot-resistant way–than the version of NASTRAN you worked on. But the kind of high-end explicit analysis required for integrated crash simulation or NVH assessment is still the purview of experienced analysts using advanced codes, although the cost of hardware and infrastructure has plummeted while capability and speed has advanced geometrically.
But, as Balthisar states, even as advanced as these tools are, they don’t replace physical testing; they merely supplement it as a way of homing in on the target solution with fewer prototypes and testing. Build one, crash it, see where it fails, and use that information to refine the model and indicate primary failure modes, rinse and repeat; hopefully only once or twice rather than ten or twenty times.
As something of aside, I went to school with and kept in irregular contact with an engineer who went on to work for Chrysler (or a subsidiary they purchased) maintaning and setting up biomechanical crash simulators for testing; he later went on to work for a company that was developing the next generation of simulators. In its own way it is just as cutting edge as computer simulation; they were working with companies that build solid state accelerometers and test recording equipment to push the bleeding edge of what these technologies can do in order to more accurately simulate and measure the behavior of a human body in a impact situation (not only high speed but also at moderate speeds and bumps–one of the pushes in automotive safety in the past fifteen years is mitigating occupant injury from low speed impacts, as seen in the Volvo WHIPS system. Physical testing isn’t just a legal requirement and isn’t going away any time soon.
Besides, do you really want HAL designing your automobile? Heck, I wouldn’t even trust him to open the garage bay door.
Stranger
I hope this thread isn’t too much of a zombie to revive (“They’re coming to get you, Barbara…”) but I came across some relevent information today while looking at changing some of our options on analysis tools we use. Here’s a press release on BMW’s crash simulation code, and a list of user papers for the same code (ABAQUS/Explicit.)
See all the pretty pictures? Wooo…shiny. So much prettier than actual hardware testing. 'Course, somebody switches a minus sign, and next thing you know, the model expands instead of collapses when it hits a wall, but that’s nothing to worry about. We’ll fix that in the next revision…
Stranger