The Crash Test Dummy Is Kicking the Bucket

The overall goal of simulation should be similar to my personal goal for engineering—making the world a better place. The goal of a simulation company is to give engineers better answers in a shorter time frame. Faster results with more fidelity enable designers and manufacturers to make better decisions further up the development stream. Digital twins are relatively new on the scene and complement the data and results obtained from simulation, helping us to ensure that the right prototypes are built before production begins.

Have simulation results and digital twin studies advanced to the point where engineers can eliminate prototypes from the design and development process altogether? Altair’s 2022 Digital Twin Global Survey Report is pointing toward the elimination of physical prototypes and the retirement of crash test dummies. The report surveyed 2,007 professionals in the fields of engineering, research science, information technology and management. Respondents were from 10 different countries in North America, Europe and the Asia-Pacific region. Companies that participated in the survey had at least 100 employees.

For the purpose of this study, digital twin technology is defined as “the process of using data streams to create a digital representation of a real-world asset to improve collaboration, information access, and decision-making.” Digital twins can be traced back to NASA during the 1960s and the Apollo 13 mission. When the spacecraft suffered damage to its oxygen tank and main engine, NASA engineers on the ground modeled the systems using digital and physical representations. NASA is still a huge proponent of digital twins for big-picture projects like rovers and Mars expeditions. The risk of building a Mars rover and sending it to another planet is huge, and it’s not an undertaking that can handle iterative design builds and launches. If you’re going to make a spacecraft and send it to another planet, you only want to do that once.

Digital twins have widespread use today. According to the survey, 69 percent of respondents said that their companies are already using digital twin technology, compared to 23 percent who indicated their companies are not. Out of the companies that are not currently using digital twins, more than half said that they expected to bring the technology onboard in the next two years. The term digital twin on its own has grown to a large nebulous cloud size, and several people can mean different things when talking about the technology. Survey responses indicate that engineers want to better understand the difference between data-driven and physics-driven digital twins, learn more about the use cases for product design, and 37 percent of professionals wanted “a straightforward standardized definition that explains the meaning of digital twins.”

The companies that participated in the study use digital twins for a variety of reasons. For instance, 42 percent simulated products that were not yet tied to physical objects, while 50 percent monitored objects that already exist. Calculating the future state of systems using predictive analytics, controlling the behavior of physical assets, and creating smart digital objects were other uses noted in the study.

The benefit of using digital twins was evident throughout the report, but one of the most unified responses was the 92 percent of professionals who said that the technology helped to make more sustainable products and processes. This is a promising statistic, as sustainability and environmental concerns are becoming increasingly prevalent. However, sustainability is a phrase like digital twin that means different things to different people. When asked about the most significant benefit of using digital twins, the respondents had a wide array of answers. Among them: the product development timeline is shortened, the number of prototypes needed during development is reduced, the number of simulations required is reduced and overall costs are reduced. These are all great reasons to enter the digital twin arena or consider moving more activities there.

In the near term, the product lifecycle management aspects of digital twins look to be growing increasingly important. Data from production control, manufacturing and design can all come together and create a fully informed twin of a system or process. The challenge with these huge groups of data will be ensuring that accurate information is contained in the data fields and that the information is updated as often as possible.

In the study, only 4 percent of respondents said that digital twins could never replace physical prototypes. That number is surprising to me, because this shift to all-virtual validation would be a huge change from 20 or 30 years ago. My first automotive component experience was with a Tier 1 supplier to an assembly plant in Oshawa, Ontario, Canada. In the two years before production started, we built dozens if not hundreds of prototype components, both for the customer and internally. The steering components were sent to the customer and built into instrument panels to test fit and function. Design release engineers and the development team took several drives across the country to test a small fleet of vehicles. Internally, we built prototypes to send to vendors to test their machines, built prototypes to validate our manufacturing and assembly processes, and still more prototypes to test the shipping containers.

My second development cycle five years later involved fewer prototypes, and the release engineer we had on site with the OEM didn’t get to take a cross-country drive with test vehicles. More confidence was placed on a smaller number of test components, and running validation tests for more cycles allowed for fewer prototype builds. The widespread use of 3D printing helped to move fit and assembly configurations higher up the development stream, which then reduced function issues downstream.

All of this becomes easier as you introduce more and more digital information into the system and work toward a digital thread. When an assembly has more than one hundred components and there are multiple engineering teams working to make changes and validate designs, change control is an unruly beast. Changes made in response to validating testing for mounting points or ergonomic factors can ripple through an entire system, and when different revisions of components come together and don’t properly fit, as an engineer you can become immensely popular extremely quickly. The widespread use of product lifecycle management and the digital thread remove some of these issues. Digital systems now tell us where our parts are and what change level we can expect. Human error is taken out of the equation, as long as the human inputting numbers into the system does so correctly.

The engineering community loves technology and using new tools, but there’s a part of human nature that is also hesitant to dump a system that’s already working. Society is currently moving forward in several areas where it feels like leaps of faith, or at least educated guesses of faith, are required—along with huge batteries of tests. Autonomous vehicles are going to require several more years—if not decades—of testing before self-driving mobility is the standard method of ground travel. The adoption of electric vehicles is on the rise, and alternative fuels are in development as well. Machine learning and artificial intelligence are pushing their way into the simulation and product development fields, and the more they are used the more the engineering world accepts them as proven design tools.

The National Highway Traffic Safety Association has a full array of crash test dummies of different sizes and weights, designed to simulate the full population in the event of a crash. Personally, I find it hard to believe that the near future will see us building cars, planes or boats without prototypes and crash tests. The objective of crash tests is to make vehicles safer, and shutting down that phase of engineering validation will be hard to justify if any recalls occur that are related to crashworthiness. One option might be to run crashworthiness tests later in the design cycle, when early production builds are available, saving money on the builds headed for the crash.