For additional information on SMAC, CRASH and other accident reconstruction and simulation programs please see the www.mchenrysoftware.com and the many technical papers on the website
IPTM published a hack job paper in 2007 entitled "Energy, Momentum and the Chaos of Time" by Bonnett. As a service to all SMAC computer program users, we include responses and discussions to the quotes to assist SMAC users. At some point we may add references. Our responses on this page have been presented before. See our 1997 SAE papers for a starting point.
Please send any questions on SMAC or comments to firstname.lastname@example.org
The IPTM paper made many erroneous and misleading statements about the SMAC and CRASH computer programs. The paper liberally quoted from the McHenry Software website. The author cherry picked the quotes and presented a skewed and erroneous representation of the SMAC and CRASH computer programs. Technical papers should rely on review and referencing published technical papers. The subject paper was not a technical paper, it was a sales pitch for the authors software. The following are direct quotes from the paper. No doubt attorneys may throw these incorrect and misleading quotes in front of a SMAC user in deposition or trial. So the following are to assist SMAC users in responding to the erroneous and misleading quotes from this irresponsible paper.
1) P2, “CRASH3 was an attempt to equate the damage severity of an accident to the severity of injury suffered by the occupants. If the correlation was timely and valid, it could greatly assist medical personnel, especially emergency room physicians, in diagnosing the injuries”
This is an erroneous statement. CRASH and/or SMAC were never created with the intent to "assist medical personnel". SMAC was created as a tool for NHTSA which would provide for a uniform interpretation of the accident evidence. NHTSA was to use SMAC in conjunction with their NASS studies to determine where and at what approximate level of severity injuries were occurring in accidents throughout the country. Prior to SMAC (and then CRASH), NHTSA had used the ACIR “Accident Severity Ratings Scale” (ASRS) and/or ad-hoc hand calculation techniques. For the ACIR ASRS technique damaged vehicles were compared to photos of damaged vehicles to the subject accident and determine minor, moderate, etc. With year end funds researchers at Calspan created the SMAC program for the reconstruction of automobile accidents. When SMAC was delivered to NHTSA, some of the the researchers at NHTSA had difficulties estimating initial collision speeds for running SMAC. SMAC is analogous to running a mathematical full-scale test. You point the vehicles at each other with initial speeds and let the vehicles interact and run out to positions of rest. You then compare the accident evidence with the predicted damage AND trajectory information. Based on the comparison, adjustments are made to the initial vehicle velocities and headings, and the simulation is run again. The process is called iteration. You iterate the program until you get an acceptable match of the accident evidence. To assist the researchers at NHTSA with ‘starting values’ of initial speeds for SMAC, the CRASH computer program was created. CRASH was created as a pre-processor for SMAC. CRASH incorporated two independent techniques: Linear Momentum and Damage Analysis, to come up with a first approximation of the impact speeds. These speeds were then to be used as a starting value for SMAC. The simplicity of CRASH and the ‘average error’ requirements of statistical studies by NHTSA made the CRASH technique preferred by NHTSA. (in statistical studies, the average error is most important, whereas in individual accident reconstructions, the maximum possible error is most important.) The actual ‘damage severity’ determined by either SMAC or CRASH was the Impact Speed Change otherwise known as the DELTA-V. This is the time rate of change of speed during a collision event. The researchers at NHTSA were compared injury rates with impact speed change for various impact configurations to determine where to spend their research dollars (where were people being injured? And at what level of DELTA-V?). In CRASH the ‘damage analysis’ was a secondary solution procedure. Linear momentum was always the primary solution procedure of CRASH, and damage analysis was added to assist in co-linear collisions (where linear momentum can not be used) and to add a secondary solution procedure as a check of the linear momentum solution. The simplicity of the CRASH damage analysis enticed NHTSA to adopt it for their NASS teams (They only had to simply measure the damage! This alleviated NHTSA to have "go-teams" who had to be prepared to immediately go to the actual crash site in a timely manner vs. a simple visit to the junkyard or storage location for the damaged vehicles). So in summary, SMAC was created first, then CRASH was created as a pre-processor for SMAC. CRASH had two separate procedures; Linear Momentum and damage analysis. NHTSA, because they were doing statistical studies (NASS) opted for CRASH over SMAC, and then opted for damage analysis over Linear Momentum. Why? Because they were doing statistical studies, not individual case reconstructions. Since then a cottage industry has grown around CRASH and the CRASH damage analysis as reconstruction method used in individual case reconstructions. CRASH should not be used as the only procedure in an individual accident reconstruction no matter how popular it may be as an accident reconstruction tool. The errors associated with CRASH and damage analysis are too great for individual accident reconstructions. No where in the history of either the SMAC or CRASH programs were they going to feed the reconstruction results to medical personnel.
2) P3, “it is interesting to note that some feel that in its present form CRASH3 is doomed to obsolescence”
McHenry hopes that folks will stop trying to imply that CRASH is anything other than a first approximation reconstruction technique. The CRASH program can produce individual errors of as great as +/- 40% when applied to individual case reconstructions. Would you want the police to use this technique to determine your speed in an accident? The training seminars which are presenting CRASH as a primary reconstruction method need to revise their message. The proper message for CRASH, as contained in the CRASH manual by NHTSA (page 1.3) NOTE: 5 meg file) is that “CRASH is not, nor was it ever intended to be, a high fidelity collision simulation program” The large errors which can occur in CRASH type analyses (+/- 45%) make it inappropriate for individual case reconstructions". CRASH is a good “first approximation” tool but must be used in conjunction with other tools.
3) P3, “CRASH is also used as a pre-processor for the collision phase of the SMAC program”
CRASH was created as a pre-processor for SMAC.
4) P6,”McHenry Software details the two basic techniques used for reconstructing collisions. The basic premise of the techniques is valid, but some of the opinions expressed within the descriptive narrative are subjective and certainly debatable”
Which opinions? The author should have either deleted the ‘subjective and certainly debatable’ parts of the quotes or taken the time and effort to create his own text for his paper. 50% of the paper is wholesale quotes from the McHenry Software copyrighted website. This demonstrates the laziness of the author. Copyright infringement has probably occurred as the paper goes well beyond any “fair use” doctrine. And the paper is sold for profit under the banner of IPTM. Maybe McHenry Software should sick an attorney on both the author and IPTM.
5) P6, “McHenry seems to criticize some of the very techniques employed in the SMAC program. But this is not technically correct”
What specific “techniques” is the author referring to in this statement? The author does not understand the SMAC program.
6) P6, “CRASH3 is used in SMAC and is criticized…”
Exactly! CRASH3 is a pre-processor for the SMAC program. The ‘robot’ automatic iteration we created automatically compared the results of SMAC to the physical evidence, while starting with the ‘first approximation’ CRASH3 results for a given collision, automatically iterated to a solution within 10% of the truth! Automatic iteration means a control program running the SMAC program, comparing the correlation of the SMAC results with the accident evidence, and automatically adjusting the speeds, re-run SMAC, repeat). No human intervention was involved in the process except in the programming of the automatic iteration scheme and the creation of the inputs and the target damage and rest positions. For additional information please see our paper SMAC-2003: The Automatic Iteration of SMAC, SAE Paper 2003-01-0486.
7) P7, “In our little excursion back in time, we learned that CRASH3 was developed primarily as a tool to equate collision severity with the severity of occupant injuries”
No we did not. This is the erroneous “belief” of the author. It is incorrect.
8) P8, “We now have this great mathematical model called CRASH. The logical next step is to get more money for research by mating it with SMAC, an even more complex model that will simulate automobile collision”
Misrepresentation. SMAC was created first. CRASH was created as a pre-processor for SMAC. SMAC was created on year end funds. CRASH was created by request of NHTSA. To infer that somehow the research was to ‘make more money’ is a misrepresentation. The refinement of the application of scientific procedures for the advancement of highway safety was and is the main motivator behind the creation of the various tools by McHenry (SMAC, CRASH, HVOSM, etc). Please see our website for a list of publications by McHenry.
9) P8, “SMAC, which used a post-impact trajectory section that lets us control the vehicle all the way to the point of rest instead of using simple trajectory-based section in combination with momentum used in CRASH”
Sales pitch. This is the beginning of the pitch for the author’s ‘new’ item in his software! Please note, momentum assumes ‘instantaneous exchange of momentum’. SMAC simulates the collision interaction of the two vehicles. Much more sophisticated, much more accurate. SMAC doesn’t “control the vehicle all the way to the point of rest”. With SMAC you make certain assumptions about the pre and post impact control inputs; was there damage related braking? A wheel locked or impaired due to damage? Was their engine braking?, was any steer input? The SMAC user introduces these control changes during the collision event, the 50-100 millisecond time from impact to separation. The SMAC program is analogous to running a full scale test; you setup the vehicles, run them at each other and let them go. You compare the predicted results, both damage and trajectory, with the physical evidence.
10) P8, “The control is achieved by telling it when to implement factors such as steering, braking and friction to affect the trajectory while insuring that the rules of physics are followed”
Exactly! Assumptions about pre and post impact braking and steering must be input into ANY technique. Particularly any momentum solution. How else do you determine the separation speeds? With SMAC the only added assumption is when to bring on the braking or steering caused by the impact. And a general assumption is that damaged induced steering and braking are transitioned during the 100 milliseconds of collision has been demonstrated to be a good assumption which correlates with reality.
11) P8, “Even in the early evolutions of SMAC, there were enormous problems to deal with like…and a myriad of tremendous mathematical challenges and hurdles to overcome”
What specific challenges and hurdles does the author know about and refer to such that he makes this blanket generalization without citing any references? With any computerized techniques there may be complications and ‘hurdles’. Scientific progress entails challenges and solutions.
12) P8, It is truly a major work, which will continue to have a major influence on accident reconstruction for years to come”
Why thank you!
13) P8, “SMAC is not the easiest program to learn”
Depends on the vendor marketing the program. Depends on the person trying to learn the program. Depends on the SMAC users training, experience and/or knowledge of the program. This statement could be said about ANY computer program.
14) P10, “but is this any harder than trying to use steer and wheel tractive and braking force tables to drive two vehicles to the exact point of first contact”
This is exactly the reason SMAC is superior to any other computer program. When you assume an instantaneous collision (Momentum solutions) you require the user to ‘pick’ an impact point and there is no feedback that the “point” chosen will produce the correct damage. With SMAC you get predicted damage as well as trajectory information as feedback of your choice of impact configuration, location and speeds. With any type of momentum type analysis, there is no feedback. With momentum solutions the user of the technique must pick and chose the impact location, the overlap and the force angle and then voila! With momentum solutions you sometimes can truly make anything fit the evidence. With the SMAC computer program, the simulation includes predicted damage and trajectory evidence which can be compared directly with the measured physical evidence.
15) P10, “Have you noticed that vehicles are no longer perfect rectangles”
When were vehicles ever perfect rectangles? The simplifying assumption of a rectangular vehicle has been demonstrated to correlate well with reality. With over simplified momentum solutions, the collision forces are assumed to act instantaneously at a point, a dot. Have you ever noticed that vehicles have never been simple dots?
16) P10 “SMAC demands that the entire side of the vehicle be treated as homogeneous” P10, “In fact SMAC demands that the entire vehicle deform in exactly the same way with no differences between the sides and the front or rear, and no allowances are made for hard spots in the perimeter or encompassed area of the vehicle”
These statements are erroneous and misleading. SMAC requires a value for the stiffness properties of each vehicle. That stiffness is representative of the area of the vehicle being impacted. It would be a unique impact indeed that resulted in an impact the front, the side and the rear of the vehicle all in one impact. SMAC can model different vehicles impacting different parts of a vehicle and the stiffness can be set for each type of interaction. And as far as stiffness it has been demonstrated that minor variations in the stiffness has little effect on the results of SMAC since both the damage AND the trajectory match is required to determine the match of the physical evidence. Any change of the stiffness may require a minor variation in the impact configuration, but the results, in general, will not be affected to a significant amount. There are options in SMAC to include variations of stiffness (snag option, etc.). Likewise the assumption of a homogeneous vehicle exterior has been demonstrated to correlate with reality.
17) P10, “Even the primitive (?) CRASH3 program has been updated to accommodate hard spots…”
Sales pitch. Where is the proof that the enhancements by the author (and others have done this) to include "zoned crush stiffness" make any difference in the crudeness of a damage analysis? And from where do you derive the "zoned crush stiffness" values? Deriving an approximation for the impact speed change from a CRASH type damage analysis is entirely different than the dynamic modeling of crushing vehicles in SMAC. SMAC includes the dynamic modeling of the movement of the vehicle while simulating the structural interaction or crushing of the vehicles. The author is erroneously equating and comparing two different techniques; CRASH v SMAC.
18) P10, “If Momentum is used as the methodology of choice, even the requirement of locating the point of maximum engagement is eliminated…”
Sales pitch. Where is the corresponding validation? Comparison with reality?
19) P10, “While it does require the input of approach angles to the point of first contact in the collision, so does SMAC”
Sales pitch. The author is trying to equate the technique he is trying to sell with SMAC. SMAC provides a feedback of the predicted damage and trajectory which would result from the impact configuration and speeds. Momentum does not. With momentum solutions there is no check of whether the chosen impact configuration would produce damage which in any way resembles the actual physical evidence.
20) P10 “Additionally SMAC requires both the exact heading angle of the vehicle and the angular rotation in degrees per second of the vehicles at launch, which is not required of the less “robust”(?) momentum computation”
This is erroneous. What momentum computation? The author uses momentum to represent simple linear momentum. With linear momentum there is no check on whether the impact configuration would be able to produce the angular rotation rate required to arrive at the correct rest location. Momentum also assumes instantaneous exchange of momentum of the collision. 50-100 milliseconds is the blink of the eye but vehicles move relative to each other during a collision interaction. Also during the collision interaction forces and moments are changing and the ‘direction of principle force’ is varying. Momentum requires a single value for all of this. Which do you use? The initial value? The ending value? The average value? All these assumptions create sensitivity of the solution procedure. Had the author investigated the more complicated and robust angular momentum solution, it would require “angular rotation in degrees per second of the vehicles at launch”. With SMAC you simply launch the vehicles at each other and allow them to interact. The predicted damage and trajectory gives you feedback on whether your chosen impact configuration and speeds were correct.
21) P11, “McHenry does allude to the necessity of doing a complete momentum-based computation in order to set up the SMAC run, “
McHenry has always emphasized that any analysis of an accident start with a thorough review of the physical evidence and then the use of traditional computation methods to arrive at a preliminary reconstruction. Computer programs should be used to test and refine reconstruction opinions, not create them.
22) P11 “but as far as the necessity for using SMAC to check the PC-CRASH (momentum based) values, that certainly seems a little extreme at this point”
SMAC provides a feedback of the predicted damaged and trajectory which would result from the impact configuration and speeds. Momentum procedures like PC-CRASH do not provide the user with feedback of the probable damage that would result from the impact configuration and speed. There is no check of whether the chosen impact configuration would produce damage which in any way resembles the actual physical evidence. SMAC used to rerun the PC-CRASH results would provide a check of the damage.
23) P11 “The same comments would seem to apply to the SMAC handles damage, albeit for slightly different reasons”
The SMAC simulation model includes the simulation of the collision forces between the vehicles as well as the tire forces and vehicle properties for every millisecond in time. Variations in the stiffness have a secondary effect on the results since the predicted damage AND the predicted trajectory can be compared to the physical evidence. A CRASH type damage analysis approximates the energy required to produce an area of damage. It is a single calculation with no feedback as to the effects of that damage on the trajectories of the vehicle.
24) P11, “It would seem that if you allowed the same 20 engineers to reconstruct a single accident with SMAC, you would also get 20 different points of first contact (not to mention and rotational or heading errors) and therefore 20 different results”
This is erroneous. Since SMAC predicts the damage and trajectory of the vehicles, if 20 different engineers iterated SMAC to predict a match of the physical evidence including damage location and area and trajectory (rest positions) they would all come close to the same results. There would be some variation due to differences in what constitutes a match but the overall results would be very similar. With momentum solutions, there is the fudge factor of ‘what shall I choose for impact location or point of maximum engagement?”. There is no feedback of whether the position and orientation chosen would produce the correct damage, With SMAC, the program will show you the damage and trajectory which would result from you chosen impact configuration and speeds and so all 20 folks would have to iterate to get a match of the evidence.
25) P11, “One of these challenges is computing the Yaw Moment of Inertia”
Computation of the yaw moment of Inertia is not a challenge. There have been many papers written how to calculate the Yaw Moment of Inertia. And an ‘exact’ value is not required! One of the things which can and will be demonstrated in a future SMACITER paper is that variations of the various input variable do not affect the results in a linear fashion. Because SMAC models for every millisecond both the collision interaction and tire forces it is not as sensitive as momentum solution procedures to variation in inputs.
26) P11, “Card 12 the velocity dependence”
This should only be used for wet road accidents. Tests have shown a variation in the effective friction coefficient as a function of velocity for wet roads. Momentum solution should also consider the variation.
27) P13, The inter-vehicle friction coefficient should also be a challenge for the most intrepid investigator”
Misleading. There are recommended values (0.55) and it can vary depending on the collision type from 0.35 to 1.0. This has been presented and discussed in the literature.
28) P11, “It is impossible to model a vehicle with zero (0) restitution in SMAC”
And in what real world collision do two plastic vehicles collide? When two vehicles collide, the restitution properties are the shared properties of the system.
29) P12, “SMAC is incapable of accurately reproducing these collision (true zero restitution rear-end collision)”
There are no zero restitution vehicles. When two vehicles impact and stick together, then they most likely have an impediment to separation (override, underride, damage interlock). The snag option of SMAC can be used to model this phenomena.
30) p12 “While SMAC has been tested against a collection of measured collisions (RICSAC) and has a verifiable record of accomplishments for these particular collisions, maybe its admissibility should be limited to collisions showing a certain standard of reliability”
Does the author also suggest the same for momentum solutions in general and also the procedures that the author is trying to sell with the paper? Have there been ANY verifiable tests of the author’s procedure? SMAC has a proven record of accomplishments and validation in modeling real word collision (and many more than just the RICSAC collisions). The author should venture beyond a simple web searches when preparing a paper.
31) P12, “even the selection of timing intervals, especially during the collision paths, should be viewed with a degree of skepticism”
Misleading. The validation tests have demonstrated that ramping on damage induced steering and braking during the 50-100 milliseconds’ of the collision is a good assumption. For momentum solution procedures the assumption of an instantaneous exchange of momentum should be viewed with an even greater degree of skepticism.
32) P12, “Moreover SMAC can be a useful tool in the arsenal of any accident reconstruction expert”
Halleluiah! Praise the lord!
33) P12, “Frankly SMAC requires too many assumptions on the part of the user”
Hey wait a minute! What about the last line above?? There are many competent accident reconstructionists who have successfully and correctly utilized the SMAC computer program as an additional tool for accident reconstruction.
34) P12, “An unscrupulous but skilled SMAC operator can make almost any collision seem possible in order to validate their theory of a collision”
Misleading and incorrect statement. SMAC results come down to two things; inputs, and match of physical evidence. You can not ‘make almost any collision seem possible’ with SMAC unless you either use incorrect inputs or do not match the physical evidence. There is no difference with someone presenting a momentum solution wherein an unscrupulous operator can make any collision seem possible through careful choice of impact point and force angle. As least when using SMAC there are both damage and trajectory solution results which can be compared to the physical evidence. Momentum only has trajectory information.
35) P12, “And the CHAOS of Time” section
The simplifying assumptions of SMAC have been around for 30 years and SMAC still remains the state of the art in accident reconstruction. It has a proven track record of correlation with reality. There is simply no more accurate accident reconstruction tool. Without SMAC, there is no independent check on the results of momentum analysis.
36) P13, “All the tractive forces and steer angles …are based on the elapsed time from the start of the run”
Misleading. For those (like apparently the author) who have problems with time, there are some versions of SMAC that include an automatic detection of impact option and the user simply inputs the pre and post impact steering and braking. For other ‘more sophisticated’ users the process of running the vehicles to impact and then setting the tables up to correlate with the time of impact is not a daunting task. It is quite simple and logical. If the time of impact changes, you simply change the start and end time for the tables.
37) P13, “SMAC still uses time to initiate changes in the forces affective the vehicle”
Erroneous. The author apparently is unaware that “time” is the fourth dimension and to perform a simulation, one has to integrate the equations of motion over time. Forces and moments act over time creating impulses. The only forces which are input over time into SMAC are the control inputs which are generally the damage induced steering and braking.
38) P13, Any changes of the post-impact speed of either vehicle will cause an error in any forces based on time in the post-impact trajectory of the affected vehicle or vehicles”
Erroneous. The author does not understand simulation models. This is pure nonsense.
39) “Any simulation model that bases a change of the forces affecting the vehicle on time and not on a special relationship suffers from the same inherent weakness”
Misleading and erroneous. The author again does not understand simulation models and is making incorrect statements apparently to hawk his own ‘time independent’ momentum analysis. This is pure gobbledygook! When you simulate a vehicle driving then you have to change steering and braking over time.. However when you model a collision, there is simply the pre impact and post impact steering and braking. Unless of course the operator regains control of the vehicle and drives and steers it after the collision. These can all be modeled in SMAC.
40) “The control inputs to a simulation program must be time based. “
Misleading. Unless you put a physical structure which the simulated model impacts then it is position based (and SMAC can do this!) So what’s the problem?
41) “What they are doing is curve fitting”
Wrong! The automatic iteration of SMAC is error minimization. Attempting to match the predicted damage and trajectory to the physical evidence through the minimization of the comparison errors. And had the author read the actual paper related to the automatic iteration of SMAC rather then relying on the web for information, the author would have found that error minimization in accident reconstruction is very non-linear. There is no curve to fit!.
42) “In McHenry’s approach, the post-impact speed and direction are also modified to help arrive at a solution. This is not a solution. This is a problem.”
Wrong! The only thing adjusted in the automatic iteration of SMAC study was the impact speeds and initial positions. Just like is required when running a full-scale tests to reconstruct an accident. SMAC simulates the vehicles colliding and the then their running out to rest. The automatic iteration scheme (or any SMAC operator/user) then has to compare the results with the physical evidence. Adjustments are then made to the impact speeds and initial positions and headings and the process is repeated. Please note that we have also tested the variation of many other variables with our research into the automatic iteration of SMAC.However for the research paper we limited it to the speeds and impact positions and headings.
43) p14, A Different Breed of CAT
This section is the authors sales pitch. And as they say, the proof of the pudding is in the tasting…” Where are the comparison of the authors technique with reality? Validation?
44) P15, SMAC is limited to two friction zones
Different vendors of SMAC have different limitations. An infinite number of friction zones are possible with any version of SMAC. If your version is limited, ask your SMAC vendor for more!
45) p15, “There can be almost no correlation between the actual collision and the one conjured up by a skilled SMAC operator, and yet they both can have the same area of impact, the same point of rest, and the same or similar damage profile”
Wrong! The validations of SMAC demonstrate that there is a direct correlation between the actual collisions and the SMAC reconstruction. This statement has no basis in fact.
46) p17, “The possibility that one or both of the vehicles may have attempted an evasive maneuver before impact. SMAC…does not deal with this problem”
Incorrect! SMAC can uniquely deal with preimpact maneuver by starting the simulation 50 feet or so before impact and varying the preimpact steer and/or braking.
Sales pitch and rehash of statements about SMAC.
This page may be periodically updated. At some point we may add references. Our responses on this page have been presented before. See our 1997 SAE papers for a starting point. Please send any questions of comments to email@example.com
For additional information, please see our website and the many technical papers referenced on the website | www.mchenrysoftware.com |