Joel N. Orr
Vice President of Business Development
KollabNet Inc.
Lancaster, Pa.
|
A project for an inkjet printer shows constraints and requirements. The inset shows the chassis as a project. It may have been used on previous projects but holds guidelines that apply to the printer. |
Engineering practice has evolved from a craft to a collection of separate activities, such as mechanical, electrical, and structural, each with its own way of doing things. The interfaces among these activities are poorly defined, so decisions in one area often have effects on other areas that are not realized until long after their consequences have propagated.
A systems engineering approach assumes every aspect of a design is connected — nothing takes place "in a vacuum." Another assumption is that the design-model is not deterministic. That is, it does not contain a set of formulas that model reality well enough to say, "Do this, and the following 42 things will happen."
A recent engineering program, however, addresses such challenges. It's a system simulation program called KollabNet that lets designers capture requirements from diverse documents, link them together in diagrams, and record design decisions without having to write out every word or detail. Many actions require only clicking buttons and checking boxes. This engineering-information modeling (EIM) program creates a coherent symbolic engineering model in the form of a simple diagram.
This diagram, called a DesignMap, tells the story of a design's development as the designer records changes along with chosen and rejected alternatives.
In addition, the map is not passive. It flags new elements that introduce inconsistencies in a design, thereby reducing the likelihood of "stupid" mistakes. So if an automated calculation finds a hot spot, for example, the software warns the designer and other stakeholders of it. DesignMaps track choices in a graphical format, preserving decisions and explorations of alternatives in ways that are easy to recall and reuse, so know-how applied to one design challenge becomes available to future applications.
Traditional projects often start with a document stack of requirements, pen, and notepad for marking, copying, arranging, and identifying a design's " constraint envelope." Designing begins by making choices, doing research, and rejecting alternatives. Eventually, an initial design emerges.
But the problem is, the only result is an initial design and a rapidly fading recollection of the constraints. Where, for instance, is the document that said the product has to endure temperatures of 140°F for up to 3 hr?
Software for EIM follows similar workflow, but it's all online. Users mark constraints and link them together as DesignMaps take shape. This new way mimics the paper trail, but the maps record it all. A two-second search would locate that elusive temperature requirement.
EIM addresses the complexity of a project, but pulls details together in a way that is easy to recall and reuse on future projects. For example, if a change causes the design to stray outside its envelope, say adding a part to a printer puts it over a weight limit, a "violation" icon pops up on the affected DesignBlock. Teams need not wait for a physical prototype to find that something is wrong.
To uncover effects of a proposed change, right-click on the DesignBlock that would be modified and select, "Who do I affect?" Affected Design-Blocks immediately change color. Likewise, to find which DesignBlocks, if changed, would affect this one, just right-click and select, "Who affects me?" The software responds immediately and graphically.
Users can work equally well by designing from the bottom up, starting with detailed components and generalizing to more comprehensive modules.
What's more, to focus on a printing mechanism, for example, the designer might designate the print-mechanism DesignBlock as the "root." The software will rearrange the map with that block at the top (or side, or bottom), to make it easier to see its relationships.
Modern systems out of control
Swedish engineer Boris Smeds' clear-systems thinking in the face of strong institutional resistance saved the Huygens portion of the Cassini/Huygens Saturn probe mission. It's a classic yet modern example of a misunderstood system. Smeds discovered that there had been insufficient testing of the communications between Huygens, the European Space Agency lander, and Cassini, an orbiter and relay station. The Huygens craft landed on Saturn's moon Titan after a seven-year flight.
Smeds proved that the Doppler effect was insufficiently considered in the relative speeds of the devices, and that Cassini would receive useless telemetry data after launching Huygens. Once he was believed, the mission team devised a course alteration that circumvented the problem. Read more at www.spectrum.ieee.org/WEBONLY/publicfeature/oct04/1004titan.html
MAKE CONTACT:
Kollabnet Inc., kollabnet.com