Release-Engineering - An Approach to Control Rising System-Complexity

G. Schuh
Laboratory for Machine Tools and Production Engineering,
Aachen Technical University, Aachen, Germany
Submitted by W . Eversheim ( I ) , Aachen, Germany

Abstract
This paper presents an innovative approach to augment RBD effectiveness and manage increasing
system complexity. Release-Engineering is a principle of software engineering which can be transferred
to complex automotive systems. Simulations based on features show significant reduction of internal
complexity. Without reduction of necessary marketwise diversity, a time wise bundling of component
changes exponentially lowers system complexity. The approach represents a major step towards more
significant innovation programmes through suitable, dedicated RBD efforts on system variants. Another
meaningful implication of Release-Engineering is its impact on innovation frequency by providing
significant increases in innovation rates.
Keywords
Optimisation, Productivity, Complexity Management

1 INTRODUCTION
Growing product diversity and increased customization
will continue to be essential drivers in automobile
markets. As a consequence of declining market shares
per model, the challenge is to balance between unique
innovations and the amortisation of attended RBD
accomplishments, with the goal of leveraging mutually
contradictory
aspects-the
market
benefits
of
customization and the cost of providing variety [ I ] .
Release-Engineering of (mechatronical) systems can
generate a trade-off in the dilemma between efforts to
capturing market niches and the overwhelming internal
complexity of the product life-cycle. RBD processes in
the automotive industry are essentially constrained by
too many and possibly unnecessary design changes
among different and highly interdependent components
over their life-cycle. Present design change processes
are suitable in early stages of the Product Development
Process (PDP), while relocating design changes to
former developing stages of the product.
In fact, such a procedure offers enormous benefits in
efficiency for a current RBD project but increases
complexity and necessary RBD efforts after start of
production (SOP). Since more than 50% of the overall
number of variants in the automobile industry are
generated after SOP [2], a PDP is required that can at
least maintain efficiency achieved in the RBD stage prior
to SOP but additionally provide more effectiveness and
complexity reduction in the (residual) life cycle.
Two hypotheses motivate the following discussion:
1. Automobiles can be understood as complex
mechatronical systems [3, 41.
2. The Release-Management approach from Software
Engineering can be carried forward to automotive
( mechat ronical) systems and significantly reduce
unnecessary product complexity.
2

OPPORTUNITIES AND NEEDS IN AUTOMOTIVE

INNOVATlON
Variety is generated dynamically. In particular, with rising
software shares it will be even easier to create intended
and also unintended variants [5]. Uncoordinated RBD
activities can reduce OEMs and supplier profits.
Managers have begun to realized that they have not
thoroughly enough examined what kind of customization
their customers really value [6, 71.

Complexity leads to exponential increases in RBD costs

due to the exotic status of most of the resolving
variants [8]. The demand for new solutions to handle
increasing system complexity is induced mainly by rising
interdependencies
among
single
modules and
components.

Quantity price
costs

Differentiated

Jallocation
>f mts

Exotics

Standard

Figure 1: Unintended Exotic Variants Generate Losses.

Engineering in releases could feature a sustainable way
to control and leverage emerging complexity. In
particular, those components for which cyclicity of
technological evolutions comes into the fore, e.g.,
telemetric, engine-electronic, active chassis frames, are
predestined for a Release-Engineering approach. These
components and their interfaces can benefit from early
coordination of adoptions and innovations in derivatives
or contiguous product families. The best possible
functionality could be combined with the best possible
robustness of the entire system.
The automotive development process is already well
defined by gateways and milestones, but only from the
perspective of a single project and only on a generic
level. Many product adoptions and changes obviously
have to be inserted to cover development faults during
the development phase or to shape product
innovativeness over the product lifecycle. Due to
distributed
development
responsibilities
towards
suppliers as well as towards wider product ranges, this
isolated approach is no longer feasible.
The long-term impacts of necessary and unnecessary
changes as well as reactive changes must be taken into
consideration. Automotive innovation frequency, another

reason for necessary changes, is determined by a mix of

innovation rates, e.g. for engine, body and mechatronicsl
electronics [9]. But innovation cycles
have major
differences: electronic products rarely last longer than
18 months, with performance doubling from generation
to generation [lo], while power train cycles can exist
several years. Decoupling in Releases is the solution to
manage the dichotomy between rising RBD effort for
product or component changes and necessary
economies of scale of the entire product [ I I ] .

are provoked by an intended change but do not

represent any added value.

PERSPECTIVES OF RELEASE-ENGINEERING
WITHIN NEW AREAS OF APPLICATION
Software development is already engaged in a Releasedriven development approach and proactive changemanage ment procedure. Proactive bundling of changes
and building up of determined Releases seems to be the
only way to manage highly interactive and
interdependent software projects.
Software developers should coordinate software
development in Releases for two major reasons.
Releases differ in their temporal domain-proactive
complexity reduction over the life-cycle, as well as in
their ability to enhance RBD efficiency during various
development stages.
In general there are no harmonised hardware and
software cycles, either by generating or by voiding of
innovations. An active Release-Engineering thereby
sup ports contin uous improvement and innovativeness
over the software lifecycle. In the personal computer
business, software always has to be adapted on new
hardware specifications or devices. Without ReleaseEngineering, either the software would always be
obsolete or none of the sophisticated hardware
components could be installed.
On the other hand, Software-Engineering in Releases
supports interaction within the highly dependent product
development process. The coordination of decentralised
development teams would be impractical without clear
development
stages
and
determined
changespecifications on stated points in time. The design and
development process of Windows 2000, for example,
was entirely characterised by a Release-Engineering
approach. Here one Release equals typically up to 250
software changes [12].
Release-Engineering benefits could also be achieved for
auto motive mechatron ics develop ment .
Therefore, Releases for mechatronical systems should
provide the following benefits:
1. Release-Engineering should significantly reduce the
effects of interdependencies due to a bundling of
changes within releases. The number of examinations of
single
interdependencies
should
reduce
RBD
bottlenecks.

part
Link (Interdependency between parts)

khentional change
eadive change

Figure 2: Abstract Model for Release Units and Parts

Interdependencies.
Figure 2 shows the bundling of three independent
changes into one Release. The number of intended
changes remains constant at five (highlighted by a dark
background). The number of reactive changes, however,
(bright background) drops from ten to three, thus
clarifying the engineering potential of releases.
The underlying formula for development of the change
effort as described above is
LChnnge,renct

=zx(uxx-K)

with the parameters being

LChange,react- Effort induced by Reactive Changes,
z - Number of change steps,
u -Average Number of Links per Parts,
x - Number of Parts to be changed per Step,
K - Reduction Factor for Reactive Parts to be Counted
Seve raIf0Id .
According to this formula, the effort induced by reactive
changes increases arithmetically along with the number
of intended changes minus a reduction factor. This
reduction factor expresses the number of reactive
changes shared by two or more intended changes.
Figure 3 illustrates this effect. The matrix illustrates the
interdependencies within a Release unit containing n
parts.

2. New innovations can be facilitated by reducing

variant-specific RBD efforts by means of ReleaseEngineering. Free capacities could then be used to
generate new product innovations.

4 RELEASE-ENG INEERlNG MODEL

An abstract model can illustrate the bundling of parts to
releases and the interdependencies between these
parts. The Release unit as such is symbolized by a
composition of individual interlinked parts that illustrate
interdependency (Figure 2). One composition could e.g.
represent a cars front end or a steering column module.
As aforementioned, a differentiation is made between
intended changes and reactive changes, i.e. those that

Reduction Factor K captures Common Interdependencies.

Multiple intended changes are likely to share several
Common Interdependencies.
In above example, Parts 4 and 12 do not interdependence
directly but share several common interdependent parts.

Figure 3: Capturing Common Interdependencies.

When two or more intended changes are performed,
these parts may not be directly interdependent.
However, depending upon the degree of linking, these

parts
are
likely to
have
several
common
inte rdependencies . This effect , capt u red by the
reduction factor K , represents the synergy potential in
bundling changes and causes the growth of reactive
changes to slow down considerably.
This coherency is valid up to a turning point when the
number of reactive changes can merely consist of the
parts left within the unit. Once the number of intended
changes reaches into this zone, the entire unit will
ultimately undergo a complete change, regardless of the
precise number of intended changes.
This basic logic can be illustrated most suitably by
considering the coherence between the number of
intended changes and the number of reactive changes
in Figure 4.

PI

,:, . Savings Potential

0
I

Straisht Line: #of /Mended

Changes times # of
lnferdependeni Park of each

4.

different stages of a product life cycle while freeing up

RBD efforts and thus creating room for other activities.
The product development process is marked by various
stages and gateways. Up to a certain point, all changes
applied to a product can still be referred to as purely
developmental efforts that do not cause physical
rearrangements or modifications other than those
regarding prototypes. Subsequent to this stage,
gatewayX (cf. Figure 5) displays the point within the
development process where production of necessary
tools, casts, dies and manufacturing facilities in general
is authorized.
Bundle
Synchronize Changes
Changes within
of Releases with
Releases
other Product Lines

--

n
n

-1
GW

x,

---+

SOP,

nI

--

Straight Line: # ofParfs

**.-.

/ i n Release unit minus

arts with Intended

- + -

Major
GW XI.,

SOP,.,

Change

Figure 5: Economisation Effects through ReleaseEngineering.

Figure 4: Coherence of Intended/ Reactive Changes
When only a very low percentage of parts within a
Release unit is changed, the number of reactive
changes is still almost linear to the number of intended
changes. However, when proceeding to a higher
percentage of intended changes, as is the case for the
planned bundling of changes, the mentioned synergy
effects appear. A turning point for this development
applies when the number of intended changes reaches a
status at which each part of the Release unit that was
not considered an intended change turns into a reactive
change. An extreme is reached when 100% of the parts
within the Release unit are considered intended
changes, since no reactive changes will remain.
The essential aspect of this model is to clarify where
potential savings are generated through ReleaseEngineering, resulting in a bundling of changes. This
was illustrated on a general basis. The potentials
achieved in concrete cases depend on the degree of
linking (i.e. interdependencies) within a unit.
APPLICATION OF THE MODEL
To assure the applicability of the Release-Engineering
model in praxis, the requirements and demands of a real
mechatronics development project have to be taken into
consideration. Thus, examples are based on
experiences of two first-tier automotive suppliers, both of
which produce mechat ronics components .
5

5.1 Practical Reference of the Model

Automakers introduce innovations in a very specific way.
The frequency of changes and their economic
consequences depend on the current stage of
development of a product, resulting in the need to adjust
the concept of Release-Engineering to the various
development stages of a product.
Release-Engineering enables companies to make
changes and introduce innovations in profoundly

The determination and relative position of this gateway

may differ among different industries; however, it can be
referred to as the point at which product-related changes
begin to induce physical change efforts with respect to
manufacturing resources and equipment. Thus, changes
after this point primarily need to be considered very costintensive .
By means of bundling components to releases, ReleaseEngineering implies the prearrangement of change
cycles so that each individual modification or change will
not be implemented unless its time frame will not allow
for any delay. Over the course of such a pre-planned
Release cycle, changes and innovations will be retained
until put into action as releases. As a result, changes are
bundled within each Release. The effect is twofold:
certain changes which would have been reversed later
on are never going to be realized. Most of all, however,
the bundling of changes to pre-planned cycles will
reduce efforts induced by reactive changes. These
changes occur variably, depending upon the degree of
cross-linking within the Release unit.
Once the frequency of changes to a particular product
decreases with its further proceeding product life cycle,
Release-Engineering still enables reduction of change
efforts. During this stage, a rollout of derivatives typically
takes place. When derivatives are based on a common
architecture strategy, as is the case today, many
Release units are shared between the original product
and its derivative. Thus, pre-planned innovation cycles of
releases also need to be adjusted towards derivative
products. As illustrated in Figure 5, the synchronization
of changes and introduced innovations also enables
changes to be bundled. As a result, unnecessary change
processes can be eliminated. An example would be a
change process within product 1 that would become
obsolete soon thereafter due to a related modification of
the derivative product 1.1. The underlying effect is the
same as aforementioned - reactive changes are reduced
by consolidating multiple changes.

5.2 Example
The concept of Release-Engineering can be exemplified
by means of a large, first-tier automotive supplier. A
typical showcase product is its steering column module.
The module is characterized by high production quantity
and a large degree of mechatronics components, and is
a very complex module in general. It consists of 80 parts
that are potentially all subject to changes. With the PDP
of this module, the findings of chapter 5.1 can be
verified. During a 9-month period between the
authorization of means of production and SOP, the entire
module is marked by an average change index of 3 3 .
Multiplying by its quantity of parts results in a total
quantity of 280 part changes during the described
period. Automotive modules today have to cover a wide
range of variance; the exemplified steering column
module for a particular type of car is sold in 90 variants.
The changes typically have to be executed individually
for approximately 10 percent of all variants, so the 280
part changes have to be multiplied by 0 , l times 90. The
resulting total of 2520 changes is subject to our
considerations. Assuming a share of 60% of reactive
changes, this number divides into 1512 reactive changes
and 1008 intended changes. Conducting five intended
changes on average per change process, the company
needs to carry out approximately 202 change steps in 39
weeks. Bundling changes and releasing them only e.g.
every second week would lead to approximately52
intended changes per step, assuming a fixed number of
intended changes. As per the course of the particular
graph according to Figure 4, the number of reactive
changes per step sums up to approximately 30. Thus,
the resulting number of executed reactive changes totals
585 (vs. 1512 before!) and the total number of changes
now equals 1170 (vs. 2520 before). Looking at
percentage changes, this means a 61 % (54%) reduction
in reactive (total) changes.
6

CONCLUDING REFLECTION

6.1 Conclusion
Release-Engineering increases RBD efficiency and
creates room by adopting this development principle
from software engineering and introducing it to the fields
of classical mechanical engineering. By enabling
bundled changes within releases during particular stages
of product develop ment , Release-Engineering u ncovers
and utilizes large savings potentials regarding change
efforts.
The main effects when bundling changes within releases
are threefold. First, processing of unnecessary changes
that are not consistent over time is likely to be
eliminated. Moreover, an even greater potential can be
uncovered by reducing the number of reactive change
effects, as explained in section 5.1.
The third major effect is the significant reduction of
system complexity. The anticipatory planning of variants
will become a proactive leverage within ReleaseEngineering.
6.2 Research Extensions
In order to realize the full potential of ReleaseEngineering, a new method of modularisation should be
introduced. Other than modules, Release units will have
to be arranged according to criteria exceeding mere
functional or spatial considerations. Two very important
aspects of forming Release units will be the optimisation
of interdependencies as well as the dedicated planning
of innovation cycles.
The well-directed control of attributes added by a
component to an entire product will become an
increasingly crucial factor [13]. Thus, one focus will be

on enabling control of the innovation contribution granted

by a current Release. At the same time, the common
mistake of sequentially developing different components
of a complex product when simultaneous consideration
would facilitate shorter development cycle times [I41 can
be avoided by synchronizing innovation cycles of
Releases. Automobile innovation rate, for instance, is a
mix of mainly engine, body and electronics innovation
rates. Release-Engineering is a promising approach to
enable the automotive sector to avoid the engine or body
innovation rate determining the entire industry and to
introduce
individual
rates for
every Release.
From a long-term perspective, Release-Engineering also
supports the idea of marketing product bundles in order
to better exploit profit potentials [15].
7

REFERENCES
Jiao, J., Tseng, M., 2003, Customizability Index
Based on Information Content, Annals of the CIRP,
52/1:121-124.
Schuh, G., Schwenk, U., 2001, Produktkomplexitat
managen, Hanser, Munchen, Wien.
Clark, K. B.; Fujimoto, T., 1991, Product
Strategy,
Development
Performance
Organization, and Management in the World Auto
Industry <German: Automobilentwicklung mit
System>, Harvard Business School Press, Boston,
Massachusetts.
Roland Berger 8 Partner GmbH, 2000, Nine MegaTrends re-shape the Automotive Supplier Industry A Trend Study to 2010, Roland Berger and Partner,
Munich.
Graessler, I., 2003, Design Management for Mass
Customizing Mechatronic Products, Production
Engineering, Vol. X/lw:87-90.
Pine, B. J., Gilmore, J., 1997, The Four Faces of
Mass Customization, Harvard Business School
Press, Boston, MA.
Milberg, J., 2002, Erfolg in Netzwerken, Springer,
Berlin.
Anderson, D. M., 1998, Agile Product Development
for Mass Customization, McGraw-Hill, New York.
Fine, C., 1998, Clockspeed - Winning Industry
Control in the Age of Temporary Advantage,
Perseus Books, Reading, MA.

[ l o ] Kipferler, A,, Monti, R., 2000, How Electronics will

Revolutionize Innovation in Autos, The Boston
Consulting Group, Stuttgart, Milan.
[ I l l Eversheim, W., Schuh, G., 2003, Standard,
individualisiert - individuell, in: Reinhard, G.,
Zah, M. F. (editor), Marktchance Individualisierung,
Springer, Berlin: 55-63.
[I21 Freeman, E., 1999, Building Gargantuan Software,
American Scientific, Winter 1999:28-31.
[I31 Karsten, H., Wolters, H., 1999, lnnovationsdynamik
und Knowledge-Management in der Automobil- und
Zuliefererindustrie, Das innovative Unternehmen,
June 1999:05.02.
[I41 Suh, N. P., 2001, Axiomatic Design: Advances and
Applications, Oxford University Press, New York.
[I51 Fuerderer, R., Herrmann, A,, Wuebker, G., 1999,
Optimal Bundling - Marketing Strategies for
Improving Economic Performance, Springer, Berlin.