Introducing Design Descriptions on Different Levels of Concretisation in a Platform Definition

. Product platforms has been widely accepted in industry as a means to reach both high product variety while maintaining business efficiency. For suppliers of highly customised products, however, the development of a platform based upon pre-defined modules is a challenge. This is due to the large differences between the various systems their products are to be integrated into and the customer's individual preferences. What is common for most platform descriptions is the high level of concretisation, such as predefined modules, they are built upon, but how can companies act when that is not possible? Are there other principles that can be used for the definition of a product platform? This paper presents a concept to incorporate other types of descriptions of different levels of concretisation into a product platform. Parts of the concept has been realised in a computer support tool and tested at a case company in order to improve their quotation process.


Introduction
Systematic investments in technology development (TD) has been pointed out as a strategy for companies in industry to gain competitive advantage.This is a paramount challenge for suppliers since their products are to be integrated into different systems introducing several complex interfaces, markets, product uses and individual preferences.In past research a large emphasis has been put on splitting TD from product development (PD) since they differ in prerequisites, technical maturity, time horizon, need for competence, process repeatability, completion point and deliverables [1].It follows that by separating TD from PD one can reduce risk in PD projects [2].
For a sub-supplier developing and manufacturing engineer-to-order (ETO) products, this becomes even more challenging due to the uncertainty regarding future customer requirements and needs.The challenge lies in conducting long term TD, developing the "right" technology for a future market that is ready to be introduced in a product when the time comes.At the same time a sub-supplier must fulfil the customer individual preferences, introducing a demand for customisation which often has, compared to TD, a much shorter timeframe.This stresses for strategies covering both long term and short term perspectives.Product platforms has been suggested as an enabler for efficient customisation.However, the platform definition that builds upon pre-defined modules and components has been shown to not be applicable to all companies working with an ETO business approach [3].This article elaborates how such a company can describe the outcome of TD and PD by introducing descriptions on different levels of concretisation.This is discussed in connection to a platform approach as a means to increase reuse of design knowledge.In order to support the presented concept a novel computer tool has been developed.The research question can be stated as: How can a platform be described in order to support customisation in a company working with an ETO business model?
The work presented in this paper has been conducted in close collaboration with an industrial company.The information about the presented case has been gathered from meetings, demonstration of applications, reviews of documents and in-depth interviews.A systematic literature review was made.The frame of reference presented in this paper is a condensed version of the complete literature review made for this work.The overall research approach used is the one proposed by Blessing [4].This paper can be positioned in between descriptive study 1 and the prescriptive study.

Frame of Reference
Customisation refers to the ability and strategy that aims towards designing and manufacturing tailored products for an individual customer.Simpson [5] proposes product families as a main enabler and describes two basic approaches for the design of product families in order to achieve efficient customisation, top down and bottom up.Hansen [6] divides specification processes into four levels in the following way: (1) Engineerto-order, (2) Modify-to-order, (3) Configure-to-order and (4) Select variant.
Platforms in engineering design.Several definitions of product platform can be found in literature and depending on which definition is used, a product platform can be many things.The existing definitions ranges from a platform consisting of components and modules [7], a group of related products [8], a technology applied to several products [9], to a platform consisting of assets such as knowledge and relationships [10].This is also reflected among sub suppliers, as shown in [11], where the company platform description is categorised on four levels of abstraction and compared to their customisation strategy.A risk emphasised in literature is the trade-off between commonality and distinctiveness [10].Another trade-off is the one between increased development efforts for the initial platform and the uncertainty whether the right platform is chosen in order to develop a sufficient number of derivatives to gain back the extra expenses [12].Platforms are generally described to be of one of either two kinds: Module based (discrete) or scale based (parametric) [5].Cooper [13] suggests that one deliverable from TD can be a technology platform, this is further investigated by Högman [14].Johannesson [15] questions if companies have a choice regarding implementing a platform or not since platforms can exist on several levels.
Product models can serve as a way to describe some parts of a platform.The Product Variant Master (PVM) is a method that have been described in several scientific articles and books, and can be used to model some aspects a product platform [16].The "Part-of" structure specifies the generic product architecture and the "Kind-of" structure describes the different kind of variants.CRC (Class Responsibility Collaboration) cards are then used to map all variants.Another methodology that has been used to model platforms is the "Configurable Component" (CC) concept.Here the connection from functional requirement to design solution is mapped.Levandowski et al. [17] proposes a methodology to model a platform in early phases of development using the CC concept and set-based concurrent engineering.
Reuse of design knowledge.The reuse of design knowledge has been studied by many researchers throughout the years.Haug et al. [18] emphasises knowledge acquisition where the knowledge of the domain experts is gathered and formalised.Stokes [19] presents a complete framework and in detailed described methodology, called MOKA, aiming to collect and formalise knowledge in order to create knowledge based systems.Huang et al. [20] describes the methodology for developing a knowledge map and also the implementation in a case in the automotive interior business.Baxter [21] considers knowledge as actionable information and problematizes that many previous design knowledge reuse systems exclusively focus on geometrical data which is often not applicable in early stages.The author also emphasises that in order to reuse design knowledge, several factors must be met: reusability, availability and relevance.Regli et al. [22] defines design rationale as the explanation of why an artefact or some part of an artefact is designed the way it is.According to [23] the access to design rationale can support the development of new products, modification of existing ones or reuse of an existing one in a new context.When it comes to computer support, research has pointed out that three important factors are crucial for system success: Visualisation [20], usability [24] and a concurrent working approach [25].

Summarisation and research opportunities.
A platform approach has been shown to be an enabler for efficient customisation, reuse and production standardization.There is however a lack of research investigating how a platform definition can be described in order to support sub-suppliers working with an engineer-to-order customisation strategy.There is not many examples of supporting tools that aid the work of design engineers in combination with such a platform definition.This stresses for methods based on a real industrial needs.An important step in design knowledge reuse is the knowledge acquisition process consisting of collection and formalisation.There is not much mentioned however of what design knowledge descriptions actually supports a platform definition of this kind and how these descriptions can be structured in order to improve reuse.

An intermediate Design Platform description
As stated, earlier research has shown that it is beneficial to separate TD from PD. TD has a fuzzy timeframe and no direct targeted customer and is triggered by the future market opportunities, possibilities, trends and needs (Fig. 1).This is where the company takes the risk that needs to be taken in order to spur innovation developing new technologies, products and processes.The separation of TD and PD introduces an interface between the two that needs to be managed.The main concept that is presented in this paper is to use a platform approach to handle some aspects of this interface (Fig. 1).The paper also argues that this platform definition, as will be presented, is an enabler for customisation for companies working in an ETO business model.The aim of the platform approach is to enhance the reuse of the technologies and designs developed in a company.Reuse goes hand in hand with platform thinking as a way to keep the design effort efficient and at a manageable level.What often is lacking is a platform description to support the development in order to draw the benefits from platform thinking to a higher degree.However, it is not seldom that sub suppliers does not focus the development towards a platform, but rather develop single instances every new project.This is especially true for companies developing and manufacturing ETO products and where a module-or component based product platform is not possible.This challenge of using a module-or component based product platform can have several reasons such as unknown and ever changing interfaces to the system the product is to be integrated into, different markets, different product uses, individual preferences and a relatively low number of developed and manufactured products.To manage the interface between TD and PD, the Design Platform approach is introduced.As opposed to the top down and bottom up approaches described by Simpson [5] where the platform is the focus of the development, the focus in the Design Platform approach is on the instances with the Design Platform as a support for reuse.The descriptions of the instances is what creates the platform definition which means that the platform evolves as the instances are successively created.When a number of instances has been created it can be seen as a discrete set that spans a design space, i.e. what designs are feasible.The description of this design space is what builds up the Design Platform.
The ultimate goal of PD is not the product as such but a product description.The final product description is what is considered most important and is of course the focus of PD.These descriptions (e.g.CAD drawings) are concretised to a high level which also usually means a narrowing of the design space.Due to the narrowed design space the product instance will have limited possibilities to adapt to a new situation when the prerequisites or requirements change, i.e. the possibilities to reuse the instance will be restricted.If design knowledge is captured, structured, saved and can be retrieved, it can be reused in future development projects as a natural part of the platform definition.By being proactive and exploring a design during TD and PD, this knowledge could be saved and reused by the addition of descriptions on different levels of concretisation.It is here investigated and presented how this can be achieved by saving and structuring blocks of knowledge, here referred to as Design Elements (DEs).These are more elaborated in a subsequent section.These descriptions that now are a part of constituting the platform realises something other than the component and module based product platform (i.e. the highly concretised product description).The platform is now not just composed by the physical elements that is the product but also the elements that supports the designing and constructing of the product.Therefore the name "design platform" is more suitable than "product platform" since it refers the activity as well as the thing, design.

The proposed concept
The proposed concept is based on an object oriented way of thinking.The idea is to see the generic product description as a class, when instantiated becomes an instance (object).There are different levels of classes in the concept whereas the top level is called "Design description class" and is composed by a product architecture class with subclasses, metadata model classes and DE classes.The generic product architecture is based on the theory of PVM [16] but is here tweaked to better fit the purpose.The main concepts of the PVM will be kept but will now also host DEs that also describe parts of the design process.The "part of" structure describes the class hierarchy of subsystems and components whereas the "kind of" structure describes the types of instances.Every class in the "part of" structure is described by a metadata model.Every object corresponding to a certain class is then coupled to this metadata model.Each type of DE is a class of its own.The generic set of DEs is inspired by the ICARE forms [19].An explanation follows: (1) Entity is a description of a specific component or subsystem and includes e.g.function and behaviour.(2) Activity is a task or process and basically describes how something is done including inputs and outputs.(3) Rule describes a valid relation for the designer to use, usually described by a mathematical formula.(4) Constraint describes a limitation usually based on some boundary condition e.g.manufacturing equipment.
The design description is a living document during PD and TD and is continuously filled in with the knowledge and relational descriptions as the product is developed.

Fig. 2. Design description class
The case company is a sub supplier within the automotive business.The company site in focus develops e.g.subsystems for the interior of the car where comfort is essential.Information about the case company was gathered by meetings, demonstration of applications, reviews of documents and in-depth interviews.The focus of the case study is to investigate how the quotation process can be supported by a platform description that contains both product and design process knowledge on different levels of concretisation.
As of today the case company sees possibilities of improvement when it comes to speed, accuracy and level of reuse in the quotation process.However, today there is no existing support for this.

The product
The product in focus is a system to provide a dynamic seat support for a car by the use of pneumatics.The system enables a highly customised pressure distribution on the body which can increase the comfort and the ergonomy eccentially.The system consists of a number of components and subsystems.The carrier plate, seen in Fig. 3, is mounted to the car seat and is the base for the rest of the pneumatic seat support system.The product architecture can be configured to feature from simple lumbar supports to highly dynamic full back massage systems including lumbar, side and cuchion supports.The system consits of pump, valves, hoses and inflatable elements that interfaces the human body and provides the varying pressure distribution.The valves and the pumps are connected to a PCB with hosting software that controlls the pressure, air flow and valve opening and closing sequences.
In order to receive a common generic view of the product the PVM method was used.Through a set of interviews and studying of the product documentation the common structure could be identified and validated.The following activities consisted of identification of metadata to describe and judge the applicability of the bottom most elements of the PVM.The metadata consisted of attributes that was a mix between: (1) given parameters that was customer quantifiable requirements or derivatives of requirements, (2) limitations of the component or subsystem, (3) geometrical dimensions, (4) characteristic features and (5) general information.

The quotation process
The process was mapped from a designer point of view and focus was put upon identifying crucial given parameters (e.g.requirements) going in to the process, what design Fig. 3.The carrier plate with the system mounted on it variables (variables set by the designer) they affected, and in turn what components and subsystems (items) that affected.
The quotation process of the company is similar to the standard case.It starts with an inquiry from customer or by a demo performed by the case company.An inquiry can be received either as a subjective question or with quantifiable requirements.The process is specified from a manager's point of view but does not support the designers to a large extent.The process might differ based on if the customer is experienced with the type of pneumatic system or not.It was discovered that the overall the quotation process can be divided into two parts.The first part is the configuration stage where already designed pneumatic systems are used as a first try in order to make an early judgment of the quotation feasibility.If the quotation continues, it moves into the design stage.This is where the components that are engineered to order is designed.Often a number of systems is offered, ranging from simple to high end, in order for the OEM to be able to offer products to a large customer segment.The first step in the subsequent PD is therefore to identify if commonality can be achieved between the different systems offered.
When mapping the quotation process it was identified that the company combines two different specification processes [16] when customising the system.Complex sub systems that have predictable interfaces or interfaces towards the own system is developed in the TD projects (Fig. 1).The subsystems and components developed within these projects are then configured upon customer (configure-to-order).The other types of components and subsystems are the ones with complex or unpredictable interfaces towards the customer product that the system should be integrated into.These components and subsystems are designed upon customer order making them engineer-to-order.A figure describing the principal relationships between specification processes and interfaces is shown in Fig. 4.

The identification of Design Elements
The Dependency Structure Matrix (DSM) tool was used to identify connections between parameters, design variables and items.Item refers either to a component or a subsystem.By combining the DSMs, mapping matrices was created to not only see the connections inside one matrix (e.g.parameters) but also between the matrices (parameters, items and design variables).This was done in order to ultimately map the given parameters to items and in that way cluster what parameters that will be the input to designing an item or configuring a system.All three DSMs play a part in defining DEs.Since both parameters (input to the DE) and design variables (output from the DE) are coupled to a generic item class, they will partly define the DE.Some parameters and design variables will be isolated to a specific item, some will span several items and some will only be on the architectural level.When evaluating the result of the DSM Fig. 4. Specification processes and interfaces one could see that the parameters mapped to one specific type of item as well as the type of system architecture.It could be concluded that these two were the parts of the product that were customised upon customer order.
A novel computer support system.A computer application called "Design Platform Manager" (DPM) was created to aid working with the presented concept.The application manages DEs and is created using the scripting language Visual Basic.The object structure is created as the above explanation.The DEs are created on templates using MS Excel for user simplicity.A controlled nomenclature is used to guarantee DE consistency.When a DE has been created by filling in an Excel template, the DPM indexes the Excel file and puts it into a file vault.At start up DPM reads a selection of contents from each DE and presents it in order for the user to search among DEs.When a DE is selected it is opened up in MS Excel to be edited or read.Fig. 5 shows a screenshot of the computer support system user interface as well as four Design Element templates.Upon quotation a class can be searched and the user is presented with the saved design elements that is valid for that specific class.This way the user will have a better foundation for making decisions and judge what labour that has to go in to the subsequent PD and in turn approximate the cost of a product.This enables the designer to have access to some of the design rationale in the beginning of PD that can support the development.

Discussion
To reuse knowledge created in the design process is an ever challenging task in industry.Past research has not been successful in covering the whole issue, rather small pieces have been covered to aid in specific situations, artefacts, processes and types of knowledge.This paper tries to add a piece in the unfinished puzzle by the use of a platform approach in order to support companies working in the ETO business.The presented concept uses Design Elements that are pieces of knowledge about the design Fig. 5. Screen shot of the "Design Platform Manager" user interface and Design Element templates process or the product.The definition assumes that the design knowledge can be discretised and formalised.By introducing DEs in the platform definition one introduces knowledge descriptions that can be on different levels of concretisation which also can constitute parts of the design rationale.This way, relevant design knowledge descriptions for each instance is captured, structured and coupled to a generic architecture to be browsed in the future.In the case of the development of a component where there are no finished designs, these DEs will create a base-line for the designer to start from, describing what entities, activities, rules and constraints that are valid for a specific class of component or subsystem.With the use of the DEs the development can start at a higher degree of concretisation due to the bandwidth of descriptions introduced.
The validation of the concept and proposed computer support system has been done as far as early testing at the case company.The design engineers are positive about the level of support it introduces for knowledge reuse, especially in the quotation process.

Conclusions and future work
The approach presented here addresses an area in platform based development where not much has been explored.The bodies of knowledge in the areas of component and module based product platforms as well as knowledge reuse is vast, but the combination of the two with a focus on sub-suppliers in the ETO business is lacking.
The paper describes how companies in industry can use a platform definition, consisting of both process and product knowledge, as a means to practice reuse to a higher degree.The approach is realized in the novel computer support tool called Design Platform Manager and applied in a case with a company active in the automotive industry.
The future work will consist of continuing the development of the Design Platform Manager in order to fully support the presented concept in terms of modelling design instances, searchability, visualisation of connections between DEs and between DEs and design instances.An ontology is also planned to be developed to better guarantee DE consistency.Evaluation of the concept and computer tool will continue as well.

Fig. 1 .
Fig. 1.The Design Platform is fed with descriptions created in both TD and PD.These descriptions can then be used in future development project.