©Brian G. McHenry, McHenry Consultants, Inc.
Intro | History | Refinements | Summary | Main site |
The paper I am presenting is entitled "SMAC-97 - Refinement of the Collision Algorithm". The acronym SMAC stands for the Simulation Model of Automobile Collisions. The computer program is a time-forward simulation model. With SMAC you set up a mathematical "full scale crash test" using the vehicle weights, dimensions and other properties. The vehicles collide and run out to rest. You then compare the SMAC predicted positions and orientations at rest with the accident evidence. SMAC was initially developed for government sponsored research in highway safety. It is currently being used mainly with respect to litigation. Whatever the use of SMAC, or its equivalent, limitations on accuracy and generality that were imposed by early 1970's vintage mainframe computers should not persist. This paper includes suggestions for needed refinements in the original SMAC computer code.
But first, I would like to present a brief review of the history of the SMAC computer program and its relation to highway safety research:
Intro | History | Refinements | Summary | Main site |
In 1952, a pioneer program in highway safety research, the Automobile Crash Injury Research program (ACIR), was created with the objective of determining injury causation among occupants of cars involved in accidents, in order that the injuries might be prevented or mitigated through improved vehicle design. By the mid sixties, 31 states had participated in the program and provided over 50000 cases for study. The main criterion for classifying severity in the ACIR program was through the use of comparison pictures of damaged vehicles.
Also during the 60's the digital computer was coming of age. Mainframe computers, which filled entire floors of buildings, cost hundreds of thousands to millions of dollars had evolved into time-sharing, batch processing machines. These were used in conjunction with 9 track tapes, card punch machines and terminals to provide to scientists, engineers and others number crunching capabilities unlike any utility ever before imagined. The digital computer quickly became an integral part of scientific research and development.
In September 1966, President Lyndon Johnson signed the National Traffic and Motor Vehicle Safety Act and the National Highway Safety Act. These established the authority to develop both the Federal Motor Vehicle Safety Standards (FMVSS) and the National Traffic Safety Agency (currently known as the NHTSA). As part of signing the legislation President Johnson stated that "auto accidents are the biggest cause of death and injury among Americans under 35". In 1965, 50,000 people were killed on the nations highways in auto accidents.
The SMAC computer program was initially created as a feasibility study by researchers at Cornell Aeronautical Lab (currently known as Calspan). The researchers at Cornell were interested in demonstrating the feasibility of a mathematical model of automobile collisions which could achieve improved uniformity and accuracy in the interpretation of evidence in automobile accidents. SMAC applications would give more accurate indications of collision severity. This would help to establish priorities, provide monitoring and assist in establishing the regulatory role of the government.
At the time of the creation of SMAC, limitations in the detail and the accuracy of the ACIR study had spawned a number of different exploratory approaches to the ACIR objectives. The SMAC program was evaluated as a possible tool for the investigative teams. SMAC is an "open-form" accident reconstruction program. A requirement of "open-form" programs like SMAC is that the user must initially 'guess' the impact speeds. The program also generally requires iterations to achieve an acceptable match of the accident evidence. One of the difficulties which arose in setting up SMAC simulations by the investigative teams was that the initial 'guess' of the speeds was not always obvious. Also, the user had to provide vehicle properties and specifications, many of which were not readily available. Those requirements, combined with the relatively high cost per run for a SMAC simulation run, required that a pre-processor be created which could provide the initial guess.
The CRASH computer program was first created to assist SMAC users in determining a first 'guess'. The original CRASH program utilized both piecewise-linear trajectory solution procedures and a damage analysis procedure to provide an initial 'guess'. The CRASH program was subsequently adopted by NHTSA as an integral part of the National Accident Sampling Study (NASS) investigations. The rationale for the use of the CRASH program was that for statistical studies, the average error in severity determinations is more important than any individual errors. The CRASH program, with it's question and answer mode, vehicle categorization, single step solutions procedure, and most importantly low cost, redirected the NHTSA interest from SMAC towards the CRASH computer program.
Since the creation of SMAC in the early 1970's, computer capabilities and capacities have increased dramatically, while the associated costs of computing has been reduced. During the 70's and 80's, the advent of low cost integrated circuits resulted in the emergence of minicomputers: Data General, Xerox, DEC, Prime, HP and IBM. Also at that time hobbyists began to create personal computers. The early tinker toys evolved: the Apple II and the IBM PC 8088.
In the last 5-10 years the computational power of PC's has dramatically escalated. With the advent of the Power PC, the Pentium, the Pentium-Pro, and most recently the Pentium MMX and Pentium-Pro MMX unlimited "free mainframe" processing power is now on your desktop.(aside from the initial purchase price of the computer and software). The low cost and widespread distribution of PCs and software has dramatically increased the utilization of computer programs for the reconstruction of individual accidents. PC versions of the SMAC program such as EDSMAC are currently being utilized in individual case reconstructions. This creates a situation where there have been many instances where applications of the program include significant effects of artifacts of the original programming simplifications and logic. This has been either through misunderstanding, misuse, misapplication or due to shortcomings in the original NHTSA SMAC (and therefore EDSMAC) programs.
This paper presents the results of reviews and revisions of some of the simplifying assumptions of the collision algorithm of the original SMAC program (and therefore the EDSMAC program). Many of the original assumptions and simplifiucations of SMAC were dictated by the limitations of computers available at the time of the initial formulation of SMAC. With the virtually unlimited computer processing and power available today, many of the original simplifications should be re-evaluated and refined.
Intro | History | Refinements | Summary | Main site |
Specific refinements to the original SMAC program collision modeling routines are as follows:
Item 5 is presented and discussed in SAE paper 97-0960. The suggested enhancements to the restitution aspects of SMAC are aimed at providing a more realistic model of the actual restitution behavior of automobile structures. In the original SMAC, limitations on storage capacities of 1970's vintage mainframe computers (and the associated costs) led to some important simplifying assumptions which were made to provide a cost efficient and low memory demanding technique to model restitution. The general effect of the simplifying assumptions was to model the restitution phase at the higher peak force levels. In general, the restitution phase of a vehicle occurs after the peak loading where the force level drops and the structure unloads at a lower level. With the astounding capacities of modern day PC's, a re-evaluation and refinement of the restitution model has been undertaken. We refer you to the restitution paper more detailed information.
In the original SMAC collision model, radial vectors with origin at the center of gravity are used to define the peripheries of the two vehicles . During a collision, the lengths of the radial vectors in contacted regions are adjusted by an iterative procedure which seeks an equilibrium of dynamic pressure on the collision partners. Adjustments to seek equilibrium of the two 'partner' vectors are made along each vector. The force is calculated based on the distance of the pressure points from the undeformed periphery. In some impact configurations and severity levels, some of the radial vectors of the two interacting vehicles approach the condition of being perpendicular to each other. As a consequence, the iterative adjustment procedure for the radial vectors cannot find an equilibrium. This may result in an unrealistic equilibrium interface that includes a series of jagged notches.
This is an ED-SMAC output which includes the phenomena. This is a close-up illustration This is a close up detail including a display of the radial vectors.The jagged interface occurs wherein only some of the vectors are "active" and therefore properly deformed. The problem is resolved in the revised SMAC program by means of locating the origin of the radial vectors of the collision interface at a position on the vehicle other than the center of gravity. In this manner, the origin of the vectors defining the vehicle periphery can be moved to be near the location of the collision contact. Here we have the origin moved longitudinally. Here we have the origin moved longitudinally and laterally. Research is underway to automatically locate the origin of the collision interface vectors on the basis of impact configuration and severity. Consideration is being given to requiring a damage profile definition, like that required in the crash computer program, to assist the collision routine in determining the optimal location of the center of the collision interface.
In the original SMAC (EDSMAC) program, the collision interface handles three types of impact configuration: end, side, and corner. Logic in the program calculates the extent of collision contact overlap at the instant of contact and determines which of the three types of configuration logic to use for calculation of the collision forces. Occasionally the program may exhibit a disproportionate sensitivity to minor changes in a particular impact configuration which is near a "logic" transition point. To avoid sensitivity problems a manual override of the automatic logic is suggested. The manual override of the impact configuration logic eliminates the sensitivity and provides for a manual check of the effects of changing the designated impact configuration type.
There are some impact configurations for which the simple combination of compressive forces and coulomb friction of the original SMAC program may be inadequate. The actual structural interactions between colliding vehicles can sometimes include significant tensile forces and/or moment constraints on relative rotation, in addition to the primary compressive interaction. Also, significant alternative load paths can occur which do not produce sheet metal crush. In such cases, supplementary impulsive constraints on relative motions may need to be applied. The extent of collision damage evidence may also be dramatically affected altering the relationship between sheet metal crush and the corresponding Delta-V.
For example, in a small-overlap offset frontal collision, interlocking front wheels can support large interaction forces with only a limited extent of sheet metal crush. Another example is pocketing sideswipes, which can also include major load paths (for example wheel axle and/or suspension) which do not produce corresponding crushing of sheet metal. An example application of the impulsive-constraint "snag" option is presented. For the depicted impact configuration. The original SMAC/EDSMAC program does not adequately simulate an impact on the LR wheel of the struck vehicle. In the subject accident, the impact on the LR wheel of the struck vehicle produced a 180 CCW rotation of the striking vehicle due to a momentary "snagging" or interlock of the LR wheel of the struck vehicle on the front of striking vehicle. Two different impulsive constraints ("snag") were applied to the vehicles in the area of the LR wheel of the struck vehicle. The results indicate that applying a 1000 lb-sec impulse is adequate to spin the striking vehicle 180 degrees and, thereby, it constitutes a reasonable approximation of the magnitude of the actual snagging of the vehicle structures.
In the SMAC program, each vehicle is represented by a rectangular box with the length and width dimensions of the actual vehicle. Collision detection is accomplished by continually checking the corners of each vehicle "box" to determine if it is within the periphery of the other vehicle "box". Once a corner point is found to be in contact, the program begins calling the collision routine to use the collision model to scan for interference and contacts and to calculate the associated collision forces. The program also changes the integration time increment to the user specified collision integration interval (normally 1 millisecond). The end of the collision event is assumed when a fixed time increments has passed wherein the accelerations for each vehicle are both below 1 g-unit. The program changes into a separation mode and utilizes the separation time increment (normally 5 milliseconds). If a fixed number of separation time increments are passed without any accelerations greater than 1 g-unit, then the program shifts to the trajectory time increment (normally 10 milliseconds).
Much of the logic associated with the changing of the integration time increment was created to reduce the computer overhead and costs associated with running a SMAC simulation on time-share mainframe computer systems. With the use of SMAC/EDSMAC on PC computers, there is no cost associated with the use of one millisecond time increments for all the time increments at least for final checkout runs to insure that secondary sideslap collisions are not missed or inadequately modeled. Problems have been found with applications of the EDSMAC program where the program may miss the accelerations associated with "side-slap" impacts. The following illustrates what occurred in an application of the EDSMAC program. This is the impact configuration. This is the EDSMAC output damage page. This is the damage display contains sideslap "damage" for which the accelerations associated with the sideslap "damage" were not simulated. This is the time history of the acceleration which 'misses' the side-slap This is the time history of the corrected simulation. Errors which may occur when the accelerations associated with the sideslap are missed may be significant differences in the total amount of rotation and direction of travel to rest.
Intro | History | Refinements | Summary | Main site |
With the rapidly changing capabilities and capacities of modern day computers, computer programs in general and accident reconstruction computer programs in particular require continuing efforts to check and refine results while critically evaluating the underlying simplifying assumptions. The capabilities of modern day computers combined with high resolution digital graphics have allowed for the creation of animations where anything imagined can also be made to look very real:
For example:
"stupid is as stupid does".
As scientists, engineers and accident reconstructionists
you should not let the unlimited possibilities of making anything look
real with animation obscure your duty to perform a careful and detailed
engineering analysis while also continually testing and evaluating your
techniques, including computer programs, to achieve the most accurate reconstruction
possible.
©Brian G. McHenry,
McHenry Consultants, Inc.
Intro
| History | Refinements
| Summary | Main site
|