Keywords

1 Introduction

Many companies base their business strategy on customised products. To enable such a strategy they make use of advanced application systems for automating the work of generating product variants based on different customer specification, i.e. they develop and use design automation systems. This technology then becomes not only a means of improved efficiency but also a method for drastically reduced lead times, improved offer precision, quality assurance, performance and a higher degree of customer adaptation. The establishment of a design automation system is a significant investment in time and money which is expected to give revenues over many years. For a design automation system to maintain its usefulness over time, frequent updating of design rules and execution control will normally become a necessity. Experience indicates that significant efforts are required for adapting an established knowledge based system to changes in product technology, new product knowledge, production practices, new customers and so forth. Reuse of the system encapsulated generic product family descriptions, for example design rules, when developing a new product family is perceived to significantly increase the efficiency in system development and is a means to reduce the market introduction lead time. The focus of this paper is a case study carried out at a company with long experience of systems for automated variant design. The objectives are to provide an understanding and insight into a real industrial case and more specifically study the documentation and management of product related knowledge for the purpose of revealing problems related to the current state of practice at the company to identify areas for improvements.

2 Supporting system development and knowledge documentation

For this work the contributions in the domains of product configuration, design automation and knowledge based engineering (KBE) are most relevant as they are focused on specific applications. Hvam et al [7] describes a complete and detailed methodology for constructing configuration systems in industrial and service companies. They suggest an iterative process including the activities: analysis of product portfolio, object-oriented modelling, object-oriented design and programming, among others. Every activity results in a description of the problem domain with different levels of abstraction and formalisation. Two strategies are proposed for system documentation, either by using a product variant master and associated CRC (Class Relationship Collaboration) cards or by using the class diagram of a formal model and associated CRC-cards. The original content and structure of the CRC-cards have been further developed by Haug and Hvam [6]. The layout of the CRC-card has been revised and the content has been extended. Haug et al [5] have developed a prototype system for the documentation of the CRC-cards, the product variant master and the class diagrams. A procedure for development of design automation systems has been outlined by Rask [8] where issues about documentation and maintenance are addressed by emphasizing the need and importance of routines regarding versioning, verification and traceability. A possible means to support the updating of the knowledge-base proposed by Rask et al [9] is to strive for a design automation system implementation that allows the revision and the documentation to be executed at system runtime. Stokes [10] describes a methodology for the development of knowledge based engineering applications called MOKA, Methodology and software tools Oriented to Knowledge Based Engineering Applications. Two central parts of the methodology are the Informal and Formal models. The Informal model is used to document and structure knowledge elicited from experts, handbooks, protocols, literature etc. The Formal model is derived from the Informal model with the purpose to model and structure the knowledge in a fashion suitable for system specification and programming. Claesson [1] have introduced and developed the concept of configurable components for supporting platform-based product development. One element of the configurable components is a function-means model set including functional requirements, constraints, and design solution. The purpose with the inclusion of a function-means model is to provide design rational for the encapsulated design solutions. This could support the understanding of the system and thereby enhance system adaptation and maintenance.The issue with providing traceability and design history documentation for products generated by the use of executable design algorithms is discussed in Sunnersjö et al. [11]. A system is proposed to be based on files incorporating design knowledge and executable statements. These files are managed by a PDM system and they are manually executed for the creation of design variants based on different customer specifications. Principles for an automated execution using a predefined workflow based on the Dependency Structure Matrix (DSM) method is presented by Sunnersjö et al. [12]. A model for management of manufacturing requirements is presented by Elgh and Sunnersjö, [4]. The subject was further explored and Elgh [2] introduce principles for the modelling and management of manufacturing knowledge in design automation systems with an associated information model. The information model incorporates default links and runtime created links between manufacturing requirements, manufacturing resources, knowledge objects [3] and product items. The knowledge objects include pointers to the implementation of the knowledge (e.g. a spreadsheet file or a parametric CAD file). The principles have been applied and used when developing a prototype system for automated variant design.

3 Case study

Information about the case company was gathered by meetings, demonstrations of applications, reviews of documents and in-depth interviews. Eight respondents with different positions were interviewed in total using a standardized questionnaire with open-ended questions. The result from the case study includes a description of the company’s means of providing special products at the cost of standard products. Further, the documentation and the management of product related knowledge at the company are revealed followed by an analysis and a problem discussion.

3.1 Business model and means for custom engineered products

The company develops and manufactures products for the mechanical industry. It is a global company represented in many countries worldwide. Manufacturing is located at several production units and for customer support there are a number of productivity centres. The product catalogues with standard products contains ten thousands of articles. Each individual product structure is not complex but a large number of variants exist and the catalogues contain only the most frequent variants. It is of vital importance for the company to, beside the standard products, provide special products based on different customer demands. These custom engineered products represent an essential part of the delivered products. Custom engineered products are customer specific and a request for quotation of a custom engineered product is guaranteed to be replied within 24 hours including design drawings and a final price. All the necessary documents and manufacturing programs are automatically generated when the bid is accepted by the customer. Besides the standard and custom engineered products, the product space includes products that are supported by manufacturing and special engineered products.

Automation of different activities started at company in the late 80’s. The automated activities include: process planning (workflow in production), design with CAD (3D-models and drawings), production preparation with CAM (tool paths’ to CNC machines), steer information to production cells, and measuring preparation (creation of programs to CMM machines). The automation of these different activities has resulted in a stream-lined process for quotation and order preparation, from customer specification to NC programs, Figure 1.

Figure 1
figure 1

Automated process for quotation and order preparation

Full size image

By means of in-house developed applications, the process is executed automatically requiring no manual interaction. This enables the company to provide custom designed tools rapidly and efficiently in the same way as standard tools. For custom engineered products the quotation and order process includes:

  • Automatic calculation of price and delivery time based on situation in the production units for each quotation.

  • Automatic generation of CAD-models, drawings, NC-data and process planning for each order.

3.2 Development process and its main tasks

The principle development process deployed at the company, from marketing to application programs, differs from a traditional product development process as it is aimed at describing a product space by rules and digital models, Figure 2.

Figure 2
figure 2

Company development process

Full size image

In the development task, individual instances of a planned product family is developed and verified, including for example structural analysis, functional tests, CAD modelling and building prototypes. Based on these instances, a design space of the product family is defined and described by rules and associated 3D solid models. The rules are documented and structured as expressions, tables and figures. The rules are required input to the design programmers who prepares the 3D models with information (e.g. geometries, datum features and named surfaces) to be used when creating programs for product design as well as programs for CAM and CMM. Design programming includes the adaptation of the product family description for the system used for application development, actual coding in that system and verification of application. The principles are the same for CAM and CMM programming. CAM and CMM programming are preceded by CAM and CMM preparation. The three applications of executable product and manufacturing descriptions, describing a solution space – not just single instances – are loaded into a main system that manages the execution process of individual quotations and orders.

One essential means used in the quotation and order preparation is the design programs for the different product families. The outputs from the design programs includes variant specific: 3D models configured for CAM preparation and CMM preparation; quotation drawings, assembly and manufacturing drawings; customer data (e.g. drawings and 3D model). A design program consists of a number of rules that are executed in a sequence resolved by an inference engine. The design programmers have during the years used different systems for rule specification. The current environment is developed at the company and includes a rule engine. Currently, the company is working on the next generation of programming environment which will be base on an object oriented approach.

3.3 Documentation and management of product related knowledge

In this case study the identified documentation was classified as either product related or process related. Product related documentation includes: object documentation describing the result of an activity (e.g. a description of a parametric CAD model), object process documentation which describes the work related to the object (e.g. considerations, tests, analysis, decisions, assumptions etc.), and guide lines regarding the product design considering some specific aspect (e.g. manufacturing and environment). Process documentation, on the other hand, is related to a specific product development project including documents for project management, meeting protocols and other documents used for sharing information between project members. Process documentation is stored and managed using a project database. Object documentation and guidelines are stored, managed and published on a company internal portal. The design engineers provide the material regarding the product design that is to be published on this portal. No central system for storing and managing object process document exists to date. Some individuals make notes in documents or in programming code for personal use or to be used by other group members. An overall summary of the in-depth interviews gives that:

  • The purpose of documentation in general and project documentation in specific is not seen by all company employees.

  • The quality of the documentation is very varying.

  • The corporate project database is used for finding work prerequisites and to learn from earlier projects.

  • It is perceived, by the respondents, hard to find project documents for non project members.

  • The information in the corporate project database is coarse and not easily accessible for non project members, especially when the project has been closed. The system is mainly used to find specific individuals for consultation regarding, by example, reuse of product descriptions.

  • The documents are weakly connected to the different product families.

  • Specific geometries, CAD models, are reused to some extent but design rules and principles are seldom reused.

  • It is difficult for individuals who has developed good solutions to share these solutions. The reason given for this is that there is no present system for such documentation.

  • The access to information is seen as most difficult by design engineers and design programmers.

  • Actual testing is used as method for checking validity and quality when reusing different types of product descriptions in an application.

  • A general view is that reuse could be augmented at the company and improved documentation could support this. However, it is important that documentation can be easily done.

4 Discussion and concluding remarks

The objectives with this work were to provide an understanding and insight into a real industrial case regarding documentation and management of product knowledge in a system for automated variant design. Further, the work was intended to reveal problems related to the current state of practice at the company to identify areas for improvements. Current documentation at the company is mainly focused on describing the final results of different activities answering “What?” questions. To reuse a rule in a new context (another product family) requires more information, for example scope, range, simplifications and underlying assumptions. Such information might be enough if the rule is to be used as it is, but if the rule has to be modified and adapted to specific circumstances even more information is required to support the adaptation while ensuring the validity of the rule. In general, there is a need of principles and methods to travel in the reverse direction through the different knowledge layers in the development process, from the final utilised (and system implemented) knowledge, to its associated background knowledge, Figure 3.

Figure 3
figure 3

Different knowledge layers in the development process.

Full size image

Documentation is commonly, by both researchers and practitioners, considered as an important enabler to support maintenance, adaptation and reuse of product descriptions encapsulated in systems for automated design. On the other hand documentation is a wide term and is commonly viewed as a non-value adding activity. The reason for this could be that the purpose, objectives and users of specific documentation is not defined and communicated. Two aspects that affect the value is time and organizational context, and the long-term corporate value can be difficult for individuals to understand if it is not clearly communicated. Further, it is important to support high quality documentation by providing systems, templates and guide lines to enable traceability, facilitate the work, focus on the purpose, ensure the completeness and prevent information overload. The searching possibilities and access to documentation are very limited at the case company to date and have to be improved. To support maintenance, adaptation and reuse of rules constituting a design automation system requires conceptual models, principles, methods, and tools for documentation, traceability and validation. This will be subject for future work. However, the initial strategy is to introduce two new concepts for describing design rational, one for the product instances (PIR) and one for the product family (PFR). These concepts are associated with templates consisting of predefined fields, keywords and headings for effective and efficient entering of information. PIR can be linked to decision supporting documents (e.g. computations, simulations, protocols, standards and guide-lines). PFR is linked to PIR as well as to relevant decision supporting documents. Utilised UDFs (user defined features), generic CAD-models and design rules are also linked to PFR. The program code is to be divided into blocks or objects pointing at associated UDFs, generic CAD-models and design rules. The intention with the templates is to facilitate and support high quality documentation, while the links provides traceability. The infrastructure for system realization will be built upon an information model and the technology provided by a data base.