Scratch the Patch

Unless you're in the software business, or your needs are so specific they only apply to you, you may be wasting time, energy, and money when you write your own patches for off-the-shelf codes. Better to get your software vendors to do the work for you.

They'll balk, for sure. Not at fixing bugs, of course. Most software companies jump on those fast. But adding new features to solve what they may perceive as one-off problems is different. They get thousands of change requests. They want justification—market potential, where it fits in their strategy, and whether competitors have the feature. It can cost them $50 million to develop a brand new release, so they would rather have you write your own adaptations than tinker with their code.

But, don't give in without a fight. You just might win, like the following companies did.

Size Matters

A group of jet-engine manufacturers used their size—and the market potential they represented—to convince one software company to add special features to its flagship code that the manufacturers for years had been writing themselves.

Boeing, GE Aircraft Engines, Pratt & Whitney, Lockheed Martin, and Rolls Royce each had their own individual, proprietary codes for simulating rotor dynamics. They wrote those codes because the über software they used for overall analysis—MSC.Nastran, the leading FEA code in the aerospace industry—didn't cover in any depth the design and analysis of struc-tures with rotating components. Nor did other software packages. Each company would patch its individual code on top of Nastran to perform their analyses.

It was an expensive proposition for the jet-engine manufacturers—possibly $10 million per year for each when you add up the personnel commitment, the testing, and the fact that they had to re-do their individual codes every time MSC released a new version of Nastran. Plus, it distracted them from their day jobs—designing jet engines.

And then there were the problems of interoperability. Their models didn't talk to each other, a major problem since the engine manufacturers often worked on the same projects and had to exchange files. Complicating that situation further was the fact that many did subcontract work for Boeing, which would have to reconcile all the different models itself and correlate the analysis results. 'The equations were the same, but the implementations were different and the results didn't always correlate,' says Dave Bella, senior development engineer at MSC.Software. That had implications for government certification.

MSC knew of their problems and wanted to help, but writing software to include rotor dynamics in the massive Nastran code would be expensive and the market appeared pretty small—maybe too small for the company to recoup its investment. So, MSC reached out to NASA for a hand.

At the same time, the jet-engine manufacturers, who by now had found common ground and banded together for the effort, reached out to NASA's other hand for assistance in helping to prove their case that there indeed was return-on-investment potential for MSC. NASA, in its role as technology incubator, linked the engine manufacturers to the software developer and provided initial funding for the development effort, thus lowering MSC's financial risk.

The first step, says Chuck Lawrence, of the structures and acoustics division of NASA's Glenn Research Center, was to find the common needs that the engine manufacturers shared. 'We got them to lay out the kinds of analyses they did to see where the similarities were,' he says. Once they found the commonalities, they wrote a requirements document that clearly defined the problem and objectives and gave it to MSC.

At the same time, the manufacturers worked on convincing MSC of the market potential. They reminded the software company that they were among the biggest aerospace companies in the world and that the features they wanted would be of interest to their counterparts in Europe too. MSC then did its own return-on-investment calculations. Convinced it was a money maker, and aided by NASA and Boeing, MSC turned its programmers loose on the project.

That over-simplified description of what was a long process leaves out details of the many time-consuming steps MSC, NASA, and the engine manufacturers took, including getting the requirements right, developing the documentation, writing the software, and validating it through numerous tests. The process began in 1998, but MSC's programmers didn't start their heavy lifting until 2000. 'It was a tortoise effort,' says GE Engines Engineer Richard Schmidt, 'but we were all persistent.' You can find a description of one major test of the features at the URL in the Web Resource box at right.

Little Guys Can Win Too

The keys to success were the openness of MSC, willingness of the engine manufacturers to join together, the leadership of NASA and Boeing, and the demonstration of the large potential market for MSC. Can little guys win a similar victory? The answer is a resounding 'maybe.' Jason van Hal, an engineer with the 20-person consulting firm Pow Technologies, didn't have the financial clout of the jet-engine manufacturers, but he did have a similar problem. By being persistent—and a little angry—he got his software vendor to make code changes he needed.

A long-time user of COSMOS finite element analysis software, he needed to analyze the transfer forces between two parts connected by a pin, as well as the shear forces and axial forces in the pin. 'The capabilities weren't in the software and there was no clever way around the problem,' he says. After a three-month campaign of polite, then angry letters he got the company's attention. 'I put together a spreadsheet of what I wanted and gave an example of the way they should do it,' he recalls. He didn't team up with anyone and didn't put together an ROI. 'I just ran out of patience,' he says. The company responded and he got the features he wanted. Key to his success: his persistence in continually pressing his case to the developer in letters and phone calls. Timing also helped. SolidWorks had recently taken over development for COSMOS. That company is very responsive, he says.

Of course, sometimes a software developer will automatically see the broader market and actually go beyond the wishes of a customer to incorporate even more features. That was the case with UGS PLM Solutions. Recently, a large customer (who asked not to be identified) asked UGS PLM to write software that would enable its engineers to manage the design of large products and to compare different configurations visually outside the CAD system before the design was fixed. UGS PLM made it clear that it would want to sell the new features to everyone and not restrict them to the original customer. The customer agreed. The end product is in the company's NX CAD software and Teamcenter PLM product.

Advice from the Front

Several general strategies for success jump out of these examples: identifying the larger market, partnering where possible, and sticking with it. Says van Hal of Pow Technologies, 'You have to be a squeaky wheel.' GE's Schmidt adds, 'You may have to share a few proprietary ideas with competitors, but it's worth it in the end.'

As for the vendors: Brean Shepherd, PTC's senior vice president of product management, says you have to show where the changes fit in with the software developer's strategy. 'We love it when customers tell us what they really want,' says MSC's Todd Evans. 'We're not in the business of creating cool products just because we can.'

WEB RESOURCE

To read an in-depth report of one validation test for MSC's rotor-dynamics features, go to www.designnews.com/contents/PDF/mscnastran2004.pdf