March 2006 Mechanical Engineering: Editorial

editorial

Open Integration

By
John G. Falcioni,
Editor-in-Chief

During a product's development cycle, nobody believes an analyst's results more than the analyst; and nobody believes test results more than the test engineer. But there is growing support for physical testing ever earlier in the product development process.

Supporters of such a movement, right now mostly on the test side—though the list of converts among analysts is growing—say that such a process could greatly speed overall product development. Certainly any new process that makes this promise is worth a close inspection.

Automakers, for example, have reduced development cycles from about five years to 18 months, with a goal of producing working models on the first attempt. This practice incorporates simulation into the design cycle, thus creating a need to calibrate mathematical models with test data earlier in product development.

The automobile industry is also increasing the complexity of vehicles by replacing mechanical structures with electronic components. As a vehicle's electronic content increases, most of the testing, which had been primarily mechanical, incorporates an overlay of electronics. "We now see a strong need for a common test platform that scales seamlessly between mechanical and electronics test environments," James Truchard, president and CEO of National Instruments, told us recently.

"The bidirectional flow of information between these two functions [simulation and testing] is critical for success. For instance, engineers can compare test data from previous models or components against simulation results and calibrate them to increase confidence in their simulation predictions for current designs. They can also use test data as inputs into their simulations to improve the fidelity of their results. In return, simulation can provide engineers insight to minimizing and optimizing their test, such as determining the optimum location of sensors, actuators, and exciters. Even prior to testing, simulations can help engineers identify the best designs to prototype," Truchard said.

Designing mechatronic structures such as antilock brake systems, for example, involves seamless "connectivity between the controller design and the hardware-in-the-loop test functions" and added real-time capabilities, Truchard added. "With the requirement of taking the control design to an embedded target, the process requires a unified, open platform that spans the entire embedded control development cycle," he said. "The separation between design and test blurs in this environment where engineers need to switch between them seamlessly."

An open approach, albeit different from the kind that Truchard advocates, is at the heart of this month's cover story, "The Free Range," by Robert LaMarca. At its core, the open-source software movement enables users to examine source codes, which companies typically guard tightly. The similarity between the two is the promise to make product development faster and more efficient.

In an online survey we conducted last year on how readers felt about open source, 45 percent of the respondents believed that the concept of open-source software is a "great idea." And while it may be naove to think that developers will embrace an idea that opens up their proprietary code vault, LaMarca tells how IBM has developed a profitable strategy.

Creating open-source infrastructures that encompass the software industry, and using physical test data to validate FEA simulations on the front end of product development are both novel approaches with potentially significant upsides to the development process. They deserve a close look.