Formalisation of margins

Design problems are often vaguely defined by comparison with analysis problems where there is only one answer. When conducting the case study in the company one of the engineers stated “We know how to do things but it is challenging to describe it in an abstract way”, also “If I

have a problem I know how to solve it or I don’t have a clue, I know at least whom to ask to solve it”(P.G). The research carried out at Volvo GTT, which is described in Chapter 4, indicates

that the knowledge about the way design is carried out is tacit.

Different teams are typically working in parallel on different aspects of design, which are integrated through several loops of convergent iterations ((Eckert et al. 2001). During these design iterations, key requirements and key parameters can still change significantly requiring others teams to accommodate these changes. Anticipating potential changes during the design process is a key element of managing the risks associated with those changes. The work presented in this thesis addresses this problem in terms of design margins and argues that design margins are an active mechanism to improve the efficiency of the development process. The design activity of a system or a component can be described with regards to four main concepts described as follows:

Constraints: the values parameters should not exceed. Constraints are the controlling elements which define an envelope for the total design activity.

Capability: the value a design parameter could reach regardless of a specific requirement or constraint (what the system/component can do).

Requirements: the values parameters must meet in order to get the desired solution. (what the system/component should do).

Technical solution: the final values parameters will have at the end of the design process. This represent the solution that will be implemented for a particular design problem. (what the system/component will do).

Margins in the design process can be defined in relation to these concepts. Margins can refer to a simple parameter p or vectors of parameters P = <p1, p2… pn >. This gives the pattern of

margins in a component or a system, which is described below. The following discussion will refer to a “must be exceeded” scenario, i.e. the capability of the system must exceed a certain value. For example, the truck must carry at least a load of X kg. In practice, many requirements are phrased as “must not exceed”. For example, the engine temperature must not exceed Y Celsius. The two cases are analogues and only the must be exceeded case is dealt with here for simplicity. The first type of margin M(P) on the parameters P, represents the difference between capability of a design and the requirements it is intended to meet.

M1 (P) = Cap (P) - Req (P)

The margin of a component or system is expressed as the difference between the values of the parameters representing the capability (Cap(P)) of the component and the values of the parameters Req (P) which would enable the component to meet the requirements. This is illustrated in Figure 5-3.

96

Figure 5-3 Margin M1 between requirement (Req) and capability (Cap)

The second type of margin recognises that parameters are subject to constraints. If the product parameters are constrained to exceed the values for the constraints Const(P) and the product actually has capability represented by values Cap(P) of the parameters, then this margin M2(P)

represents how much the capability exceeds the constraints as shown in Figure 5-4 M2(P) = Cap (P) - Const(P)

The third type of margin considers the case when there are not-to-be-exceeded constraints. In this case, not all of the capability can be used and the margin is reduced to the difference between the values for the parameters Const(P) and the values corresponding to the requirements Req(P). M3 (P) = Const (P) – Req (P).

In situations where the component or the system is subject to both requirements and not exceed constraints on the performance, the usable margin of the system lies between the requirements and the constraints. This is illustrated in Figure 5-5.

Figure 5-5 Margin M3 between constraint (Const) and requirement (Req)

If we consider a simplified example. In the design of a computer desk, suppose we assume that the desk can carry a load of 100kg and the customer requirement is for a desk that can carry 80kg. The margin in this case will be M1 (P) = Cap (P) - R (P), M1 (P) =100-80=20kg. The same

design can be constrained by the choice of the material used to build the desk. If the customer prefers to have a light desk that he or she can move easily, the designer will have to choose a material which is light but strong at the same time so it can carry 80kg.

98 The way different parameters combine depends on the nature of their relationship, most of which will be governed by the underlying physics in the product. However, we can detect recurring patterns of margins

Min/max margins, where the overall relationship is governed by the smallest or largest member. This applies for example to clearances, where one would intuitively think of the clearance of a component or system as the smallest values.

Additive relationships, where all the parameters accumulate and only the total is more important. This applies to weight for example.

Key equations, where many parameters influence the final outcome, the overall value is basically the result of a small number of key parameters that can be expressed in relatively simple equations.

In any system the margins are interrelated, performance margins arise from the relationships between different parameters, which each have their own margins arising from either constraints or requirements. System margins results from components and sub-systems being put together, which in turn have their own margins. However, the margins do not decompose or aggregate in a linear way as implied by the nature of the different relationships among the parameters. In particular, as margins are hierarchically composed or decomposed, margins can be gained or lost through the ways they are combined.