Review of “Development of a Functional Basis for Design”
In 2000, Robert Stone and Kristin Wood wrote about the development of functional models with a special focus on incorporating a standard nomenclature for use [1]. Functional models allow engineers to convert designs into standard descriptive language. This standardized language promotes the ability of engineers from different backgrounds to create similar models for the same system.
Whenever considering a product, the general architecture is of vital importance. This architecture can be best defined through functional block diagrams. As block diagrams should share a common language, the functional modeling system promoted by Pahl and Beitz provides an excellent starting point for conceptualizing the overall product structure [2].
Sufficient abstraction must exist in order to create a generalized functional model. Functional models which incorporate high levels of detail run the risk of defining the solution in the problem space. This artificially constrains engineers to one line of thinking when, in reality, numerous options may exist for a specific problem.
One example of artificial constraints imposed by specific functional models would be the cognizant engineer for a project defining a block diagram portion as belonging to an electrically driven caster wheel. This presupposes a solution without allowing for an alternative idea. In this case, a rail system may be a superior alternative. By artificially constraining the solution space, the functional model becomes a less useful tool for the engineer using it.
Functional models allow for improved product lifecycle management. As some documentation may be lost over the product’s lifetime, functional models allow for engineers to maintain a high-level overview of the product using a common language that does not require special knowledge of the product to understand. This allows for the re-creation of documentation to be improved in the event it is necessary. One particular description used by Stone and Wood is that functional model language is “timeless” [2]. This statement demonstrates that a standard vocabulary is necessary for product functional model creation.
Along with product lifecycle management, design engineers may wish to create design catalogs. By using standard nomenclature and language in functional models, design engineers may easily categorize solutions to be stored in a design catalog. By utilizing a repository structure that allows for database queries, design solutions may be easily recovered using common search terms that relate back to functional model nomenclature.
Another benefit of using a standardized nomenclature in functional modeling is that it allows for the rapid sharing of problems in design. With a common language comes the improved ability to communicate problems with a product. A functional model that deconstructs product functions in terms of generic block diagrams allows for sharing problems across functional teams without worrying that department-specific jargon will interfere with rapid communication. As each problem can be placed in a standard format based on a generic function, engineers may use design catalogs or solution charts to arrive at a method to correct the problem with the product.
With common language comes common metrics. Without a common language to share metrics, design metrics may become obfuscated by confusing terminology. By sharing a common language, product functions may be benchmarked against each other. Additionally, competitor products may also be easily broken down into manageable functions that also allow for benchmarking. This may be combined with other design engineering techniques such as House of Quality to drive new product development towards innovative solutions.
One downside of using functional models is the same advantage previously discussed: the broad system description. As a product lacks a clear definition, there is a frequent inability for engineers to reach the same functional model design independently. This results in design teams requiring frequent collaboration to ensure workflows are benchmarked together.
The functional modeling process is initiated by defining the overall purpose of the product. The overall function can then be deconstructed into subfunctions through an iterative process. Once each subfunction has been sufficiently broken down into lower levels, the functional model can then be created from these lowest-level solutions.
As functional models may vary wildly from engineer to engineer, a common language is required. Stone and Wood propose a generic verb-object pair list of functions to incorporate into functional models. By using these specific phrases, functional models may be standardized across industries.
Overall, the functional model system discussed by Stone and Wood meets all criteria for applicability to the design process. The information contained in the article in question is both timely and topical. Through regular use of the proposed nomenclature, standardized functional models become a more realistic goal for design engineers to create.
[1] Stone, R. B. and Wood, K. L., 2000, "Development of a functional basis for design," Journal of Mechanical Design, Vol. 122, p. 359. - 370
[2] Pahl, G., Beitz, W., Feldhusen, J., Grote, K., 2007, Engineering Design: A Systematic Approach, 3rd ed., Springer Science & Business Media, London.
Member discussion