2015.01.09 11:13

design:divide_and_conquer

A problem which seems difficult can sometimes be handled by breaking into a series of subproblems such that the solutions of those subproblems can then be put together to solve the original, difficult problem.

Examples of this abound even in everyday life. The trick to this approach is that many people divide the problem badly. For example, a robotics company divides the design of a new robotic manipulator into segments based on the classical engineering disciplines: mechanical, electrical, controls, etc. This is not a good way to divide the problem since in the final product all these elements are very strongly coupled, and the coupling will be difficult, and therefore there is increased chance of error, unreliable product manufacture, and difficult operation. On the other hand, if one divides the design according to the nature of the problem (e.g. base, manipulator, end effector, and so on), one uses the natural division of the product type, which leads to a lower overall level of coupling between elements, and thus an easier design that ends up being more effective and efficient.

So *divide and conquer* works best when the division is made in terms of kinds of product function. For a robotic manipulator, three sub-teams could be developed: one for the end-effector, one for the base/mounting/shoulder areas, and one for the upper- and fore-arm sections of the manipulator. Each team would have a mechanical engineer, a controls person, a manufacturing specialist, etc. to make sure that at every point of the process, all the possible engineering issues are treated.

To use *divide and conquer* successfully, you need examine the problem carefully, and look for dividing lines that occur naturally *in the problem*, not in your team, or your organization, or what your boss thinks you should do.

This method is, however, not a hazard-free solution either. Consider the design of the Sikorsky S92 Helibus (see Sikorsky S92 case study). This is a good example of how function modeling could have been useful. Had a computer model of the wiring (including a model of the functions of wiring) been available to the engineers, then we can imagine that some automated consistency checker would have been able to determine that the fuselage did not provide the passages needed to let the wiring reach both ends of the helicopter.

It also depends on knowing enough about the problem, and other, currently available designs, that you can look for the natural dividing lines of the problem. If you are developing a highly innovative design, then it will be nearly impossible to find those dividing lines.

design/divide_and_conquer.txt · Last modified: 2020.03.12 13:30 (external edit)

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International