• Nenhum resultado encontrado

8.4 The incremental innovation method

8.4.1 Initiation, current concept analysis

Incremental development focuses on the product improvements through conceptual changes in product sub-concepts and implementation in sub- or supporting functions.

Concepts, which have passed several improvement or cost reduction activities during their lifetime, may show up with various functional problems. The typical appearances of these are:

• Vibrations or displacements due to weight optimization, inertia or operating speed changes or dimensional growth.

• Increased noise, wear or temperature due to increased power utilization or component volume.

• Slow response time to the activation of a function due to increased size or inertia.

• Breakages due to high or alternating stresses caused by materials, complicated design or ignored loading cases.

Once the problem has been identified, the initiation of an incremental innovation method is directed to analyze the existing system. Rather often many of these are the consequence of partial optimization within one technology or discipline (Liedholm 1999).

The analysis begins by describing the problem with the experienced behaviour and continues by recognizing and defining all systems and technologies involved in a function

99 execution chain. This includes the functional structure, mechanical system with mechanisms, energy and power train system and control system.

The focus of the analysis is on the status and/or mode changes of a function, which is used to identify the function execution chain in the transformation process. The modelling of this execution chain enables the development team to identify the impacts and integrations between different sub-systems and technologies, which finally, in combination, accomplish function.

The modelling of the function execution chain may be first visualized by using a modification of Function Analysis System Technique (FAST) introduced in the 1960’s for the systematic organization and representation of the functional relationships in a technical system. The technique was later successfully adapted and applied with value engineering [Figure 8.6] (Bytheway 2006).

Figure 8.6 Visualization of function execution and its decomposition into secondary and enabling functions. Adapted and modified from FAST-diagram principle (Bytheway 2006).

With the original FAST, a logic hierarchy was introduced and provocative questions were directed to each level to better understand system function. Each logic level was challenged with questions (Bytheway & Administrator 1975):

• Critical path logic: How is the function actually accomplished? How is it proposed to be accomplished?

• Higher level logic: Why must the function perform? What is really meant to happen when the function is active. What higher level function caused the function be active?

• Support logic: When is the function performed? If the function is executed, what else must also happen?

• Basic function determination logic: If the function is not executed, would other functions perform? When a function is executed in the manner conceived and does it cause each apparent and dependent function to come into existence?

Bytheway & Administrator (1975) argue that function shall be split and distinguished into smaller sub-functions with the purpose of determining the basic function, specifically the function that caused all the other functions to come into being or existence. The principle is analogous with functional decomposition (Hubka & Eder 1988, Pahl & Beitz 1996), but the specific questions are directed more towards execution order and relationships.

100

The same principle may be applied first while analyzing the existing concept and functional structure, but identifying a function execution chain requires a deeper evaluation of the transformation process [Figure 8.7].

Figure 8.7 Transformation from the design domain to the reality domain, the change of concretization from requirements and planned state towards execution and feedback.

The transformation process model in the design domain can handle all relevant parameters to describe the execution process as long as the function can be described within a single discipline’s structure.

An addition of disciplines (or technologies) into a function creates a series of events, which have consecutive and parallel impacts on a function activation process. With multi- disciplinary products, the concept analysis aims to identify:

• What initiates the function?

• How is the initiation indicated to the control system?

• What are the other indications, interlockings and events which are coupled with the function?

• How are the function status or mode changes modelled in the control system?

• How does the control system initiate the power train system?

• How does the power train system initiate the mechanism?

• What measures or consequences can be identified during the execution process, which differ from the ideal design transformation process?

• What are the physical static and dynamic characteristics of the mechanism and power train systems?

The transformation process in the design domain describes how the operand transforms from an existing state to a desired state. However, during the execution process in the reality domain, it is possible to identify how the state change is actually realized.

The function execution chain may be visualized as a consecutive event chain connected with coupled or uncoupled effects [Figure 8.8].

101 Figure 8.8 Function execution chain from initiation to the concrete mode of action with

interactions between disciplines, effects and active environment.

A specialist, dedicated to design within one technological discipline according to specification, often ignores the modes of execution and focuses only on the design properties and characteristics. The visualization of a consecutive function execution chain provides an extended view for the development team of what systems actually influence the function. An example of partial function execution chain during gantry acceleration in the case study presented in Chapter 8.3 is presented in Table 8.1.

Table 8.1 Example of the function execution chain events and their correspondent disciplines during gantry acceleration.

The presented event listing of the function execution chain includes at this stage the main events which are in interaction to or with other disciplines. Further detailing of these events penetrates deeper into each discipline thus enabling the development and optimization within the discipline.

The listing of the events enables communication between practitioners and allows them to acknowledge interactions that cross the borders of the disciplines. The concretization of the isolation between disciplines and the need for communication may be described with the

102

practical work scopes of different specialists; the mechanists follow the specification derived from requirements as “gantry travel speed is 45 m/min and acceleration time from zero to full speed is 5 seconds”. Once the required acceleration force has been defined and converted to motor torque, the electricians choose the correct sizing for the power supply and inverter. Finally, the automation specialist programs the PLC code for particular function and related interactions.