One way to shrink the development cost of automobiles is to use digital prototypes to reduce the cost of building physical prototypes for crash tests. It allows the safety of vehicles to be tested and changes to be made at an early stage in the design process.
“At an early stage in the design process, the cost of change is low. But once you commit to physical testing, the cost of change rises considerably. It involves the cost of building new prototypes – including the cost of the test-engineer’s time – as well as the cost of reproducing the original design,” says John Hemmings, senior manager of crash simulation at Rover. There is also a cost to the quality of the car. If safety features are not an integral part of the car’s design from the start, their inclusion will add weight to the vehicle.
At Rover, simulated crash tests are relied on heavily. Analysts are required to conduct increasingly sophisticated FE crash analysis so that year on year they can have greater confidence in their predictions. Whereas in 1990, analysts tested the impact of a car colliding directly with a wall at 48 kilometres per hours (kph), by 1996 they had begun to test the impact of a deformable offset barrier (with only 40% of the car hitting a wall) at 64kph. In the same way, the number of elements being considered in each test has increased from 30,000 individual elements in 1990 to 120,000 elements in 1996. Today, this figure has risen to 250,000 elements. Where analysts previously modelled and tested individual vehicle components separately, they now model the vehicle as a whole. This allows them to analyse the effect on many other elements aside from the body panels including the chassis, power train and the vehicle occupants.
A long time ago…
Prior to 1996, Rover’s crash analysis team conducted its research using a Cray YMP supercomputer, a resource shared with other analysis groups at Rover including the body structures group, the chassis group and the power train group.
According to Hemmings, competition between analysis groups for time on the computer was great and the crash analysis department was often unable to access the system. Crash analysis was very much limited by large analysis run times. At times of heavy Rover workload, much of the analysis had to be conducted at night and at weekends.
The matter was made worse by the complexity of using the system. A designer’s CAD data was sent to a pre-processing package to create the mesh of the model. The mesh in DYNA 3D NCODE was then manually converted into a form that could be sent to the Cray. After processing, the information was sent back through a data converter before post-process analysis could begin. The system was running over an FTP network so it could take several hours to get data back from the Cray processor. As a result, it was taking up to four days to turn a job around.
In 1996, a new product needed a rapid turnaround. To meet the deadline, Rover had to commit to a speedy re-design and testing process. Because Rover did not have time to conduct the usual number of physical crash tests, it had to make a strong commitment to simulated crash environments using virtual prototypes. Six analysts worked on each part of the crash simulation programme compared to the normal two. The existing IT system simply could not support this level of activity, so Rover implemented a full review of its modelling systems.
Rover looked at a number of hardware platforms. A Silicon Graphics system was already being used to perform complex crash analysis tests at BMW’s Munich design site. It had proved to have specific technical advantages over other hardware platforms.
Rover updated its workstations to include two Silicon Graphics’ O2 workstations with 256MByte of memory, 9GByte of storage and MIPS R5000 processors; six Indigo workstations with 512MByte of memory, 13GByte of storage and MIPS R10000 processors; and 17 OCTANE workstations with 512MByte of memory, 13GByte of storage and R10000 MIPS processor.
Rover also implemented one dedicated Power Challenge XL server supercomputer at Cowley with 2GByte of memory and 24 MIPS R 10000 processors, plus one Onyx graphics supercomputer. The files for this system were served by a Challenge DM 60GByte drive.
At the Gaydon Design and Engineering Centre, an Onyx graphics supercomputer with 2GByte of memory and 24 MIPS R10000 processor was installed. At the end of 1997, Rover added a 24 processor Origin 2000 CC NUMA server with 2GByte of memory, 45GByte of storage and 24 MIPS R10000 processors, plus an Origin 200 Filer Server with 150GByte of storage and a DLT stacker. The server meant Rover could guarantee an overnight turnaround.
Rover also changed software from Dynda 3D code to Pam-Crash code. BMW prompted the change to Pam-Crash because it was already using it with its existing Silicon Graphics hardware.
“We were aware of the work that SGI has done with ESI so we were confident about the move to Pam-Crash,” says Hemmings. It has taken several steps out of the processing procedure. The data still has to be turned into a model before it can be analysed using Pam-Crash, but the data that comes back can go straight into the post processor. The data is also automatically archived.
Rover also changed from SDRC I-DEAS Master Series IV software to Hypermesh, which has a direct translator into Pam-Crash. The translation of the data into the correct format is now a lot quicker. In the past, Master Series IV had to be manually edited, so errors could be built into the deck which could potentially cause it to stop functioning overnight. Using Pam-Crash with Hypermesh meant that analysts could write from the pre-processing package straight into the Pam-Crash code. Pam-Crash could also translate data directly into Pam-View for visualisation.
The system has helped Rover to remove one phase of physical prototype crash simulation. Rover has also moved from 70,000 element models to 250,000 element models which show greater detail on the components expected to fail in the crash. This allows the crash analysis team to model the entire structure of the vehicle and occupants whereas they could previously only simulate individual parts.
Visualisation is key
No analysis can be 100% accurate. Data from simulated tests has to be tempered with the analyst’s own experience of physical crash testing. Because of the level of human input, there is a need for effective communication at all levels of the design process.
Communication and collaboration between teams has been improved using Rover’s 3D visualisation centre – a 20ft wide by 8ft high screen using a dual projection system to display car designs full size in stereo running on a Silicon Graphics Power Onyx. Rover is already using this facility to conduct large group visual design and assembly reviews, which, until now, were only conducted on individual workstations. An important part of the analyst’s job is to make information accessible to the designer.
A crash test is a very dynamic and chaotic event. Elements move around and are fluid. It can be difficult for a designer to appreciate analysis unless it is presented in a visual form. The visualisation centre has space for a large forum where designers and engineers from different areas can view the implication of crash data as it is analysed.
The two O2s and 17 Octane workstations can also be used to drive portable projectors for remote presentations. Silicon Graphics technology allows Rover to showcase its designs on CAD software away from GDEC. John Hemmings, senior manager of crash simulation at Rover, says: “Visualisation is critically important to us. It is likely to become more important as we change the way we transmit information to the user. We plan to develop a server-based web environment that will allow anybody to pull up the crash results for a particular vehicle and to visualise those results. Test engineers may want to reference past analysis and compare it with their tests and visualisation is critical for the communication of design change between analysts and designers,”
Silicon Graphics Tel: 0118 925 7500