LEARN MORE

Related Suppliers

Siemens PLM

Zones



Click Image to Enlarge

Chuck Grindstaff, Siemens PLM president & CEO, says that they’re working to develop a master model methodology so that people doing development would be able to get information about what they’re working on when they need it and in a way that they can understand it, information that would leverage their own knowledge, having been based on the knowledge of others who had faced similar challenges or who have associated information.

Siemens PLM & Creating the Master Model

 Chuck Grindstaff joined what was then Unigraphics Solutions in 1978.

 Chuck Grindstaff joined what was then Unigraphics Solutions in 1978. He was 22. Grindstaff is now the president and CEO of Siemens PLM (siemens.com/plm), the company that absorbed Unigraphics along the way.

 
This thumbnail history is relevant because Grindstaff has an idea that goes back to that time, an idea that he is making manifest in products like the company’s Teamcenter 9 product lifecycle management (PLM) software suite.
 
It was the idea of a “master model.” “I thought that it would be done in 10 years,” he says. “Today, I think we will continue to evolve this environment and provide additional capabilities.”
 
The model doesn’t exist. At least not wholly, as he’d imagined. But he thinks they’re getting there. “It will be a 15- to 20-year journey to get to the bottom of all these problems,” he now says.
 
Back in the day, there were, he recalls, disparate models for different disciplines. For example, there was a mechanical model for a vehicle, then a separate electrical subsystem model. The master mechanical model would have all of the information relevant to developing the product; it was, he says, to be “a disciple-specific central source of truth.”
 
But now what’s important has changed, and the electrical subsystem model, for example, is undoubtedly as important in the development of a car as the mechanical model. What’s more, Grindstaff points out, there are a variety of other considerations relevant to vehicle development that has an effect on a current master model. He notes that nowadays, a platform is undoubtedly more global from a standpoint of how it will be deployed, which means that it is important to understand that if a version for the North American market has features X, Y and Z, it will be necessary for the model to indicate whether the platform will also accommodate features A, B and C for the European or Asian market. Grindstaff says that a question that has to be answered is, “For all possible buildable configurations, is this design decision going to work?”
 
Another consideration related to the master model now goes to the restructuring of the auto industry. Back in the late ‘70s, the OEMs were still fairly vertically integrated. Now there is considerably more outsourcing, which means that suppliers have larger portions of the vehicle under development. Their input must be reflected in the model.
 
Although Grindstaff thinks that they’re going to “get to the bottom of all these problems,” he also acknowledges that the situation is not unlike that in physics: there were atoms identified, then the electrons, protons and neutrons, then quarks and gluons, then . . . The bottom continues to drop out.
 
One of the challenges that Grindstaff thinks needs to be further refined is that of knowledge capture and reuse. While there is much to be said of reuse of designs (of components or systems), he thinks it would be valuable to be able to codify and reuse, or codify and promote the thinking and methods used to get to a design. He explains this by describing what happens when you buy a book on Amazon. Say you buy a copy of The Hunger Games. Amazon has compiled the clickstream of other people who have bought that book, then uses that information to promote some other books that you might buy because it has the data that one set of activities leads to another activity. This would not only be the sequels, but books or other items that are related, based on the analysis of the data collected. So what he thinks would be helpful is to be able to capture all of the information related to a specific development—who talked with whom, who did what when during the development of a component or system—in order to synthesize useful behaviors that could be applied to consequent developments by other people.
 
What he thinks can be achieved, however, is the ability to observe what happens, identify successful behavior related to accomplishing a particular goal, and then bringing that to the attention of others who are involved in similar product development programs. What’s more, sticking with the Amazon/Hunger Games metaphor, he points out that there are companies that use the information about who bought the books to position their products. In the product development approach Grindstaff is working toward developing, engineers might promote their solutions to others who are dealing with particular concerns. 
 
Grindstaff says, “What I am hypothesizing is beyond structured information: a company would know every network transaction.” If it is determined that there is a correlation of given transactions with successful development, which would be determined via analytics, then that would be promoted for future use.
 
Today, he says, while there is a wealth of structured data, it is important to capture the information around it and to syndicate it with the structured data. That will help facilitate insight for the designers and engineers. “That data is not in one system. It is spread all over the place.” So it must be integrated into the model.—GSV