New computer-based tools will help product designers capture their design decisions and rationales, take the entire product life cycle into account up front, and facilitate collaborative design
Sara Reese Hedberg
Today's global economy is pushing companies to get better products to market more quickly at reduced cost--and, increasingly, with the least environmental impact. The old sequential, linear style of operation is fading. The days are past when design engineers brewed up a design entirely on their own and then ``threw it over the wall'' to manufacturing. The barriers between different parts of the organization are dissolving as manufacturers think more holistically in terms of integrated business processes such as the introduction of new products.
``Manufacturers must evaluate as a
n integrated whole activities such as sales, order processing, design, assembly, shipment, invoicing, installation, and service,'' according to Mark Fox, director of the Enterprise Integration Laboratory at the University of Toronto's Department of Industrial Engineering. ``Today's solutions span organizational boundaries. By integrating the components of each process, companies will be more competitive because they can get better quality products to market faster and take advantage of the economics of globalization.''
Design--A Multidimensional Task
A new emphasis is being placed on design as the first step of manufacturing. Design engineers must take into account up front the entire life cycle of the envisioned product. Under this life-cycle approach, designers must meet the requirements of all the activities that are downstream from design--such as manufacturing, distributing, servicing, and recycling. But it's not even that simple. Design engineers must make trade-offs among competing requir
ements.
For example, the top of a soda can is made from a different aluminum alloy than the rest of the can. The top is slightly tapered to reduce the amount of this different alloy and simplify recycling processes. But if it's tapered too much, then fewer cans can be packed into a truck, and distribution costs increase. So a balance must be struck.
Today the design process is further complicated because it is often a collaborative effort, involving many engineers with different skills and responsibilities. The design team may be in one location or in various locations in the same city or around the globe. It may have members from more than one organization working for a ``virtual company''--such as a consortium formed to build a complex product (e.g., an airplane). For large, complex products, there may be hundreds of design engineers involved. ``It's physically impossible to get 200 automobile design engineers together,'' notes Fox. ``So what technology or technologies can be used to achieve d
esign integration?''
The U.S. DoD (Department of Defense) faces the problem of collaborative life-cycle design in-the-large. To develop and produce an airplane, for example, many vendors must cooperate in an international virtual manufacturing complex. How do you integrate the design work of two contractors working on different parts of a plane--say General Electric designs the engine, and Boeing designs the airframe--when each uses a different CAD tool? How can the two companies' designers collaborate so that their respective parts fit together?
Needed--New Modeling Tools
Several major technical issues must be addressed if computing tools are to help designers balance the multidimensional requirements of the entire product life cycle, as well as support collaborative long-distance design by different teams. One of the primary issues is how to represent not only a solid model but also the design decisions and engineering judgments that shape a design. This requires a rich means of represe
nting information--often at high levels of abstraction. One area of research that is addressing this challenge is called ontological engineering.
Groups at Stanford University, the University of Toronto, and others are working to build rich ontologies (i.e., shared reusable knowledge bases) for representing highly complex data structures that can be shared among the different parts of the organization. The Enterprise Integration Lab has developed an experimental ontology of products using first-order logic that provides the ability to represent parts and assemblies, features associated with parts, and parameters associated with features. For example, a part may be a length of pipe, a feature is a bend in that pipe, a parameter of the bend may be the number of degrees it angles through. This ontology also includes the ability to represent design versions, revisions, requirements that lead to design decisions, design rationales, and more.
Closely related to modeling is the issue of finding and cap
turing the information that goes into the model. ``We have to cross the barrier between what is in engineers' notebooks, and what is in the computer systems,'' notes Fox. ``We're taking for granted that the information is already in the computers.'' But this turns out to be a wrong assumption. Fox's Center for Enterprise Integration analyzed where aerospace engineers at one large company spent their time and found that about 50 percent of engineers' time is spent creating or looking for information. At most, only about 35 percent is actually designing, and much of that is spent re-creating information they couldn't find. ``So the issue of capturing the information that goes into these systems and accessing it is absolutely critical,'' concludes Fox, ``because that's where all the time is spent.''
Communicating Among Groups
Another issue closely related to rich data models is that of having a mechanism for sharing a model among different parts of the organization. In many cases, different operati
ng groups have their own databases, as well as different terms for the same object. ``Is a part called a part in the manufacturing database,'' asks Fox, ``or is it called a product, or is it called a piece, or is it called an SKU? Design and manufacturing may use totally different terminologies.'' So there needs to be a way to translate terminology among all the various groups that share the product model.
``It's just as if you were speaking French to somebody, and you're a native English speaker,'' continues Fox. ``You would think about it in English and translate in your head into French and then communicate in French. And if another person you are speaking to is a native German speaker, he would take the French and translate it into German and then figure out what you had said. It's the same idea here.'' So at the very minimum, integration requires a shared language for communication. In most organizations, this means getting different CAD tools--such as AutoCad, CadKey, and Unigraphics--to talk to
each other or getting a CAD tool to talk to a CAM tool.
``You may want the designers to ship the model to manufacturing, but each has a different system,'' explains Richard Fikes, professor of research at the Computer Science Department of Stanford University and coscientific director at Stanford's Knowledge Systems Laboratory. ``Everyone is using their own languages in their systems. So we need to translate in and out of these standard languages. We need to define standard interlinguas for device models--common interlinguas with translators at both ends.''
Coordinating Tasks
As if the rich modeling-language, data-acquisition, and model-sharing issues mentioned above aren't enough complexity for the life-cycle design problem, there is yet another layer--the need to coordinate the various requirements of the product life-cycle during design. This is a difficult proposition, because there may be complex interdependencies among parts and systems.
Take a simple case: for example, the d
esign of a door handle, where you have a handle designer and a door designer. The handle designer decides that the handle will be 4 inches long. However, the door designer has been assuming it will be 3 inches long, so he or she needs to find out quickly that the other designer has changed the length of the handle. And what if the door designer has already designed a door that cannot accommodate a 4-inch handle?
The job of handling these types of problems is left to coordination technologies that are being developed to represent design-decision responsibilities and constraints. Design constraints can originate in the laws of physics or come from downstream processes in the product life cycle such as transportation. For example, there might be a requirement that the depth of the handle depression should equal the handle width. ``Whenever one parameter changes in a design,'' explains Fox, ``the effects of that change have to be propagated across that constraint to related parameters, and people have to t
hen be made aware of the fact that there is a constraint conflict, or there's a change in that parameter.''
Constraint technology is one of the most important technologies that is needed to support integrated design, Fox concludes. ``It lets you represent how different parts of the design interact with each other. Based on that, we can do design-decision propagation and alerting. We can even automate part of the integrated-design process, because as one part of the design changes, we can propagate that change into other parts and make that change automatically.''
In recent years, research at places like the Concurrent Engineering Research Center and the University of West Virginia has spawned research tools that can enforce design constraints and allow data to be shared among geographically dispersed teams. The Product Design for the Environment Research Consortium at Carnegie Mellon University (Pittsburgh, PA) has been prototyping green engineering-design tools that look at the full life cycle
of a product, from raw materials through use and ultimate recyclings. These tools will help engineers design products that balance environmental and economical constraints.
Technology Transfer Under Way
In recent years, ARPA has supported considerable research in the design process under its MADE (Manufacturing and Automated Design Engineering) technology program. MADE tools will enable communication among different stages in the life cycle so that knowledge can be shared. ARPA has also taken an active role in transferring this research out into the industry (for more information, see the text box ``MADE in the U.S.A.''). The University of Toronto's Enterprise Integration Lab, for example, is using MADE tools for the Supply Chain Management system it is developing and is adopting pieces for its Concurrent Engineering Design-in-the-Large projects that Spar Aerospace plans to use on an experimental basis by the end of the year.
Enterprise Integration Technologies (Menlo Park, CA) has begun
offering MADE networking services on a commercial basis. So far, they have directory services available and expect to provide security and payment services later this year. The company is also working with RSA Data Security (Redwood City, CA) to market modules that allow Web users to speak Secure-HTTP (Hypertext Translation Protocol) for secure transactions. Enterprise Integration Technologies is also trying to peddle MADE-developed authoring tools, such as an engineering notebook.
Through efforts like these, the next generation of life-cycle design tools is beginning to see the light of day. But how long will it take these new technologies to percolate down into widespread use? After all, it took 25 years for the Internet to make the cover of Time magazine. However, the pressures of modern times and new transfer infrastructures will undoubtedly accelerate the adoption of MADE and related tools and technologies. Indeed, most experts guesstimate that this new generation of life-cycle design tools will h
ave significant impact among major U.S. manufacturers in the next two to five years.
Sara Reese Hedberg, a freelance writer based in Issaquah, Washington, specializes in emerging software technologies. You can reach her on the Internet at
hedberg@halcyon.com
or on BIX c/o ``editors.''
Design Of A Lifetime
