Staffan Sunnersjö

Requirement-driven Design Processes with integrated Knowledge Structures

Customer requirements provide objectives and constraints for all phases of the product development process. For complex system products with a high degree of customization, it is no mean task to ensure that the right persons at the right time have ready access to the selected requirement specifications that they should adhere to and strive to satisfy. In the present work a systematic sequence of development phases associated with computer implemented information structures for requirements, functions and systems have been studied at three companies with widely different products and business scenarios. Although individual adaptations are required, the overall processes for requirement decomposition and propagation appear surprisingly similar. To fully exploit the potential of such information systems, many companies would benefit from also including knowledge structures in their product models. Fundamental product and process knowledge often evolves slowly over time, can be gradually upgraded and be reused many times. It also constitutes one of the company’s most valuable assets and should be carefully maintained and enhanced. In the work presented here a few different approaches to integrating knowledge structures into the total product information structure have been developed and exemplified for the three companies studied.Copyright

An Ontology Approach to Collaborative Engineering for Producibility

With today’s high product variety and shorter life cycles in automobile manufacturing, every new car design must be adapted to existing production facilities so that these facilities can be used for the manufacturing of several car models. In order to ensure this, collaboration between engineering design and production engineering has to be supported. Sharing information is at the core of collaborative engineering. By implementing an ontology approach, work within domains requirement management, engineering design, and production engineering can be integrated. An ontology approach, based on an information model implemented in a computer tool, supports work in the different domains and their collaboration. The main objectives of the proposed approach are supporting the formation of requirement specifications for products and processes, improved and simplified information retrieval for designers and process planners, forward traceability from changes in product systems to manufacturing systems, backward traceability from changes in manufacturing systems to product systems, and the elimination of redundant or multiple versions of requirement specifications by simplifying the updating and maintenance of the information.

Problem Structure and Knowledge Processing

To solve a computable design problem a sequence of operations (arithmetics, data storage, evaluation of conditional statements and so forth) will be performed. There are cases where this is a straightforward task, the sequence of operations are well known or can be clearly established. Often this is the case for processing associated with analysis. Such problems are said to be well-structured, implying that the program code has a predefined path of execution, which it is up to the programmer to clarify and specify.

Planning a Design Automation System

When product variety is a driving business factor success relies on skilful creation of: (1) A family of products that are modularised and/or parametric, (2) A production system with a high degree of flexibility (3) Standardised design procedures implemented in supporting computer systems.

Computerised Methods to Design for Variety, DFV

In the previous chapter we discussed which design tasks that might be candidates for design automation from a technical feasibility perspective but also how a sound business case for such automation could be identified.

Industrial Products and How They Are Developed

In our everyday life we are surrounded by and dependent on man-made systems and products. These are sometimes referred to as artifacts. We live in an artificial environment, we breathe air that comes heated and humidified out of the ventilation system, we use electronic equipment to communicate at distances out of hearing and we use transport systems to travel around the globe.

Representation and Processing of Implicit Knowledge

Design tasks where all design rules can be derived and formulated stringently from basic physical principles are based on insight, understanding and control. This desirable situation implies that it is possible to compile a knowledge base that explicitly and completely describes the knowledge required to design a specific product. Such is the case for some engineering products, e.g. the automatic balancer previously used as example, and the representation and processing of explicit knowledge was described in the preceding Chapter.

Representation and Processing of Explicit Knowledge

Assume that we have clarified and compiled the specific domain knowledge and problem structure required to perform a certain task of variant design. This knowledge, i.e. understanding of information and methods to be used, must then be transformed into a format that can be coded as a computer program. This is not primarily a matter of conversion to specific language syntax, but rather a matter of being able to express subtle real world knowledge in the standardised formats that the computer will accept.

Clarifying, Idealising and Modelling of Engineering Knowledge

As human beings we think and reason without paying much attention to our own mental processes. Human intelligence appears to be a collection of mental abilities that are partly complementary but also overlapping, creating a degree of redundancy. The challenge when setting up a design automation system is to transform knowledge in a form that has been satisfactory for the workings of the flexible and resourceful human mind into facts, rules and methods that can be programmed for execution by a rigid and stringent computer processor. This includes processing explicit and implicit knowledge or, when possible, making implicit knowledge explicit, to device methods to bridge knowledge gaps when such occur or, conversely, to mediate when design rules are contradictory or overlapping. This chapter will discuss the most important aspects of this process.