The Expert's View: Finding the Balance Between Automation, Simulation, and Inspiration in Engineering Software

excerpted from  

Full article is available for a fee

Peter Thorne of Cambashi Ltd., April 1, 2008

Engineering applications -- by which I mean the full range of design, analysis, simulation and data management tools used to handle engineering information -- must strike a balance between what they expect people to do, and what they can do without manual intervention. But where should the boundary be? What should the architects of engineering applications be aiming for?

The underlying challenge is the substantial range and diversity of engineering tasks. Select any discipline from product and process development and maintenance, then, within this discipline, select just one technology, market sector, or product type. Engineering activities still come in all shapes and sizes.

For an engineering application to automate the equivalent piece of design, it must either have found a way to bypass the snag, or it must do what people do -- select a few promising candidates from all the possible ways to satisfy a requirement, then iterate, developing each candidate a little bit, assessing the results, and deciding which of the candidates to take through to the next stage.

One place to look for clues, pointers and insights into what is going on is in the work that has been done on systematic design methods. Many academics and practitioners have come up with frameworks and workflows designed to replace an engineer’s instincts with well-defined, step-by-step processes. At the heart of many design methods is a top-down, divide-and-conquer strategy. A requirement can be solved with a set of functional modules. If the interaction between modules is kept to a minimum, then each module can be developed almost independently. This makes the next iteration simpler.

"Divide and Conquer" strategies may not identify commonality across sub-modules.

Of course, divide-and-conquer strategies introduce a risk of duplication because every ‘divide’ stage aims to create well defined, standalone sub-modules. This makes the process unlikely to recognize that one of these sub-modules could be shared with other modules.

The full article is available for a fee at CADCAMNet.