There is no clairvoyance in industrial design. Engineers create designs based on current knowledge, and when technology leaps forward, a chasm appears. Bridging this chasm involves kludges, compromises and promises. For a generation after indoor plumbing was invented, the pipes were bolted on the exteriors of houses. It took that long for the discipline of architecture to integrate the discipline of plumbing.
When it comes to mechatronics' development kits, the industry is at that bolt-the-pipes-to-the-wall phase. If the industry had known electronic, mechanical control systems and software disciplines were going to interweave, it would have built the design tools differently. Now the industry stands on the edge of both compromise and promise, waiting to make a prodigious leap.
When it comes to mechatronics' development kits, fixing the technology is certainly an issue, but process and people create their own stumbling blocks, as well. Even so, the future is not necessarily bleak. There are nascent efforts afoot to help spawn the mechatronics' design tools the industry would have built had it been clairvoyant.
Disciplinary Issues
Let's start with the technological issues. At its most fundamental, the challenge of mechatronics' design comes from the need to combine and accommodate two different domains — one that uses code and one that uses equations. “If one domain is a parametric model and the other is a hardware description language that is purely code, how do they understand each other?” asks Pawel Chadzynski, vice-president of product management for PTC®, a Needham, MA-based developer of product lifecycle management (PLM) tools. “That is the key for bridging those domains.”
No one knows this more than a mechatronics' engineer working for a large consumer manufacturer, who asked not to be identified in this article. “The ultimate design package isn't 3-D CAD, because rather than modeling complex designs, they just do an exploded drawing,” he says. “But the interfaces to the other elements need to be clearly designed. If I have a 12V power supply, what is it providing power to? What kind of power is it?” In his electrical schematics, he might have seven circuit breakers, each with a different function and a unique device ID. “Distinguishing one from another is implicit in the real-world, but in the 3-D CAD design, they're only separated in space.”
“Say I want to do a vibration analysis on a 3-D CAD model of a gear train. I have to model the geometry to use a finite element analysis tool. But it's the same geometry,” he adds. “I want to have the geometry defined where I have a parametric model that I can instantiate in the CAD model. We're all working on the same design, so why can't there be a data model that we all work with and can add value to?”
It doesn't help the cause of mechatronics' development, either, when development tools have evolved from different disciplines, such as MCAD, ECAD and motion control systems. In many cases, development tool vendors strove to create proprietary clusters of design and simulation products. Because they're theoretically designed to work together, the transfer of information from one phase to another is supposed to be seamless.
Building The Interfaces
That's not always true in the real-world, though. Sometimes when companies add tools to their design chains through acquisition, the results can be problematic. The mechatronics' engineer quoted earlier describes one design tool for electronics that was offered by a mechanical design vendor as “a toy.” “It was like going from Microsoft Word back to a text editor,” he says. “I'm not willing to accept less capability in an electrical design tool, because then I have to accept less capability on the mechanical side, as well.”
Alternatively, companies are working hard to develop interfaces between their design tools and simulation tools. For instance, SolidWorks' MCAD tool logically interfaces with its simulation tools. But you can also connect a design created in The MathWorks' Simulink or National Instruments' LabVIEW to interface with SolidWorks' simulation tools.
But even those interfaces don't fulfill all needs. One of the hardest parts of the puzzle is the integration of motion control software, according to Brian MacCleery, senior product manager for industrial embedded design at Austin, TX-based National Instruments. “With motion control, I need an environment that can simulate the design before I build it to test how it's really operating,” he says. “That helps me move toward virtual prototyping, which encompasses the behavior of the actual device.”
It's at this point in the design process, he says, that true mechatronics' issues come up, such as code flaws causing mechanism crashes or improperly sized components. The machine may be overdesigned, so it's not only too slow, but it's using more power than it should. “Once you can connect control software with simulation and modeling software, then you can really be in business in terms of simulating different conceptual designs,” says MacCleery. “You can compare them, resize them, make the parts lighter or stiffer, increase the size of the motor and setup the control code to do more in parallel in order to reduce cycle time.” He acknowledges it's a “hard problem to solve,” adding that LabVIEW won't be offering such a capability until the middle of next year.
While these specific interfaces between tools help, they don't create a perfect system. One of the key breakthroughs in collaboration in the broader world came when most computer vendors standardized around the TCP/IP communications' protocol. “There is no TCP/IP for mechatronics,” says Keith Curtis, technical staff engineer for Microchip Technology, a Chandler, AZ-based manufacturer of microcontrollers and associated design and simulation tools. “Nobody's screaming for it and mechatronics is just a little too new to push it.”
Among the vendors who've created their own product clusters, there is no motivation for such a thing among vendors who want to maintain their software licensing revenues. And among users, there may not be any motivation among those who shy away from learning new tools. That brings us to the people problem.
“It's a rare engineer that has the expertise to span code, electronics and mechanical components,” says Fred Stolfi, a lecturer in the mechanical engineering department of Columbia University. “The tools have been so specialized, as well and the different members of the engineering team all speak different languages. On a development team, there's usually no one leader who speaks everyone's language.”
“There can be a cultural problem as much as a tools problem,” adds MacCleery. The companies that do mechatronics well have a lot of human-oriented processes in place. “Sure, the tools need to have workflows built in that don't involve throwing it over the wall to the next group, but a lot of the human factors can't be solved with a tool. How well does your team cooperate? Do you have regular discussions and do they talk to each other?”
On the positive side, engineers sense there's a problem that needs to be solved. As Aberdeen Research Analyst Michelle Boucher (see Q&A, page M19) noted in a 2008 report, half of the respondents to a survey cited “difficulty finding and hiring experienced system engineers” and “the lack of cross-functional knowledge.”
But even people who have the desire can be stifled. “Engineers who know programming can learn controls and mechanics, but they won't be comfortable in them until they have experience,” says Microchip's Curtis. “And if they're not comfortable, they're not going to find the most efficient solutions. Only someone who is a true synergist will build truly elegant solutions.”
Driven To Abstraction
What's the prognosis for all this confusion? The destination is clear, even if the path isn't.
“Even among the well-established machine design customers, there's a strong desire for better tools that help them analyze multi-domain issues,” says MacCleery. “I'm seeing a transition from the old world of very low-level, math-oriented simulation where you take equations and run them through Laplace transforms.” Because that involves a lot of effort, he says, engineers end up with just a few physical elements and hoping they're the right ones. “It's not a realistic model of the system,” he says.
According to MacCleery, to solve this mechanical problem the industry needs to create something along the lines of what's been done on the electrical side. When you buy an electrical component the vendor provides a SPICE model for it. “We've seen a lot of interest from the mechanical component vendors in providing these kinds of models,” says MacCleery. “These are ideal for assembly drawings, but the industry needs to solve the simulation problem, as well as the modeling problem.”
For instance, SolidWorks has created a community website called 3D ContentCentral®, from which designers can download models. The MathWorks created the MATLAB Central website and began to offer models that represent topologies of physical systems, whether it's semiconductors, motors or drives.
But what's truly needed, sources say, are tools that abstract some of the underlying complex mathematics into a higher-level capability. Modelica, for instance, is an object-oriented modeling language for systems containing mechanical, electrical, electronic, hydraulic, thermal, control and other elements. It's been around since 2001 and Version 3.0 was released in March 2008.
“It's pretty neat in terms of having tools that natively embrace a mechatronics' view of the world,” says MacCleery. “You can make not just a SPICE simulation tool, but one that encompasses both SPICE and hydraulics in the same tool. You can drop down a model that looks and acts like a resistor, rather than doing the equations yourself. It's not that the math isn't important — you can still get to it under the hood. But you don't have to start with the math.” Because the Modelica models are based on symbolic math, they can do symbolic reductions of equations, which speed up the time it takes to run a simulation.
Striving For Synthesis
PTC®'s Chadzynski concurs, hearkening back to the early days of integrated circuit design for a comparison to the abstraction idea. “Where engineers once manually pushed polygons and then used RTL, they now work in a language like Verilog, which has a much higher abstraction level. You have synthesized detail without manual intervention. With less data, you can control more complex problems.”
But for customers to take advantage of that kind of data, Chadzynski says he believes vendors are going to have to work toward a more unified solution “as opposed to pieces of technology that the customers are going to have to integrate.”
For the final piece of the mechatronics' design tool puzzle to fall into place, tool vendors will have to do some collaboration themselves that mirrors the kind of collaboration their customers are trying to accomplish. “It's going to take more maturity from the tool vendors,” says MacCleery. “As great as we think we are at helping engineers solve problems, mechatronics by its very nature is a multi-domain problem, so we must invest in data exchange and conversion tools to make sure the problem can be solved.”
Tweet This
1 
