Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Design Process and Its Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Life Cycle of Electronic Products . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Design and Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Guidance for Product Planning, Design and Development . . . . . . . 8
2.3.1 Planning Development Work . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Feasibility Study During Product Planning . . . . . . . . . . . . 12
2.3.4 Task Definition and Conceptual Stage . . . . . . . . . . . . . . . . 12
2.3.5 Functional Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.6 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Technical Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Circuit Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Computer-Aided Design (CAD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 System Architecture and Protection Requirements . . . . . . . . . . . . . . . 31
3.1 Introduction—Terminology, Functions and Structures . . . . . . . . . . 31
3.1.1 System Characteristics of Devices . . . . . . . . . . . . . . . . . . . 32
3.1.2 System Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.3 System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.4 System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 System Design Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 System Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 System Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.3 System Integration in Environment . . . . . . . . . . . . . . . . . . 38
3.3 Electronic System Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 System Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 CE Designation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

ix
x Contents

3.4.2 Protection Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4.3 IP Codes of Enclosures . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Reliability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Calculation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Probability Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 Reliability Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.3 Reliability Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Exponential Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.1 Reliability Distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Reliability Parameters and the Exponential
Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4 Failure of Electronic Components. . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.1 Drift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.2 Reference and Operating Conditions . . . . . . . . . . . . . . . . . 57
4.4.3 Failure Rates of Electronic Components . . . . . . . . . . . . . . 58
4.4.4 Derating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.5 Accuracy of Failure Rates . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Failure of Electronic Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.1 Calculation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.2 Network Modeling—Serial and Parallel Systems . . . . . . . 63
4.6 Reliability Analysis of Electronic Systems . . . . . . . . . . . . . . . . . . . 64
4.6.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6.2 Availability of Repairable Systems . . . . . . . . . . . . . . . . . . 65
4.6.3 Electronic Systems Without Redundancy—Serial
Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... 66
4.6.4 Electronic Systems With Redundancy—Parallel
Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... 68
4.6.5 Service and Maintenance of Electronic Systems . . . . .... 71
4.7 Recommendations for Improving Reliability of Electronic
Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... 72
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... 73
5 Thermal Management and Cooling . . . . . . . . . . . . . . . . . . . . . . . .... 75
5.1 Introduction—Terminology, Temperatures, and Power
Dissipation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1.2 Important Parameters in Thermal Management . . . . . . . . . 79
5.1.3 Temperatures of Components and Systems . . . . . . . . . . . . 82
5.1.4 Power Dissipation in Electronic Components . . . . . . . . . . 83
5.2 Calculation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.1 Electrical and Thermal Networks. . . . . . . . . . . . . . . . . . . . 84
Chapter 1
Introduction

Electronic systems design is the subject within electrical engineering that deals
with the multidisciplinary design issues of complex electronic devices, such as
smartphones and computers. The subject covers a broad spectrum, from the
development of an electronic system to assuring its proper function, service life,
and disposal. Major advances in technology, the increasing multidisciplinary nature
of the development process and the use of electronic devices in all aspects of our
daily lives pose immense challenges for every design engineer.
The book covers all aspects of the development of electronic systems by pre-
senting the theoretical knowledge required for their design and fabrication. This is a
discipline that spans electronics, physics, mechanics, and other topics. Designers of
electronic circuits, on the one hand, often lack the necessary manufacturing and
overall system’s expertise, while, on the other hand, (electro-) mechanical designers
are hindered in their work by their lack of knowledge of electronic components.
This is where this book comes in; it aims to marry the various disciplines involved.
The goal is to convey the knowledge and skills necessary for designing and
developing electronic systems and an understanding of the myriad engineering
approaches and tasks involved. The reader should learn from the book how to work
as a designer and fabricator of these products and acquire the necessary knowledge
of all relevant aspects. The key issues encountered in the development of electronic
systems are pictured in Fig. 1.1 along with references to the respective chapters in
the book.
The principle topics covered are the design process, packaging issues, and
associated system levels, extended with special requirements for the development
and fabrication of an electronic system. These requirements include protection
issues, reliability, thermal management and cooling, shielding, and recyclability.
The layout of the book is detailed below:
Chapter 2, Design Process and its Fundamentals, presents the steps involved in
the design process for electronic systems as well as the use of technical design
documentation, such as technical drawings and circuit diagrams. It also provides an
introduction to computer-aided design (CAD).
© Springer International Publishing AG 2017 1
J. Lienig and H. Bruemmer, Fundamentals of Electronic Systems Design,
DOI 10.1007/978-3-319-55840-0_1
2 1 Introduction

Design Process
(Chapter 2)

System Definition Technical

Drawings,
Circuit Diagrams,
Preparatory Study Functional Specification CAD
(Chapter 2)

Circuit Design

System Protection System Architecture

(Chapter 3) and Packaging Issues Electromagnetic
(Chapter 3) Compatibility (EMC)
(Chapter 6)
Discrete Components
Reliability
Integrated Circuits
(Chapter 4)
Multi-chip Modules
Printed Circuit Boards
Power Supply Recycling
Heat Dissipation Enclosure Requirements
External Interconnects (Chapter 7)
(Chapter 5)

Fig. 1.1 Requirements for the development of an electronic system and the matching book
structure

Different packaging methods for the system-level and for individual components
as well as system protection are described in Chap. 3, System Architecture and
Protection Requirements. Particular emphasis is put on protection classes and IP
codes which stipulate how a system should be designed with the protection of
persons and the device interior in mind.
Critical reliability parameters and their use are introduced in Chap. 4, Reliability
Analysis. The reliability requirements for system-level and package design can thus
be met and the overall reliability of a system calculated from the known reliabilities
of individual components.
Losses and heat transfers associated with components and the overall system are
covered in Chap. 5, Thermal Management and Cooling. Thermal characteristics
can be determined at the design stage and suitable elements selected and deployed
for heat dissipation and meeting thermal criteria.
Chapter 6 in the book, Electromagnetic Compatibility, deals with EMC issues
when designing electronic systems. It also covers conceptual solutions comprising
shielding and protection measures against electrostatic discharge (ESD).
Chapter 7, Recycling Requirements and Design for Environmental Compliance,
presents material that may be new for many engineers and will certainly increase in
importance as industry continues to evolve. The chapter describes critical environ-
mental considerations during the design and development stages that have tremen-
dous impact later in the product life cycle, in particular at the tail end during product
1 Introduction 3

disposal and recycling. The challenge for designers in today’s waste-disposal-aware

society is to produce environmentally compliant systems. Waste and energy con-
sumption should be minimized during manufacture, use, and disposal, and system
materials should be fully recyclable after use.
The appendix (Chap. 8) presents rules of technical drawings, preferred numbers
(Renard and E-Series) and schematic symbols for electronic components, including
their labeling with colors and characters.
Chapter 2
Design Process and Its Fundamentals

In this chapter, we describe the basics of the development process for electronic
systems. We will see how service-proven standards and norms along with standard
drawings and computer technology can be used to break down the design process
into separate activities, which are then more easily performed. Every research and
development engineer needs to be familiar with these design activities and with the
requisite technical documentation (technical drawings, circuit diagrams, CAD
models) in order to produce successful electronic products.

2.1 Life Cycle of Electronic Products

The electronics industry is an exciting place to be these days, and indeed most
technical innovations today come from this industry. Fifty percent of many com-
panies’ sales come from products that are less than five-years old. These products
need close attention not only just when they are first designed but also through their
entire life cycle. Figure 2.1 shows the typical life cycle of a product from a business
standpoint. The product life span can vary. In order for a product to be economi-
cally viable, a business must establish whether the development costs can be
recouped and, if yes, over what time period.
The different stages in a product’s life, also known as the product life cycle,
typically consist of development (development stage), use (marketing stage) and
disposal (covered in Chap. 7). The development stage consists of the following
steps:
– product planning,
– design and development, and
– first production run with prototype build and pilot series.
As we can see in the middle of Fig. 2.1, the growth rate is high at the beginning
of the marketing stage and then the product matures. The market for the product and
© Springer International Publishing AG 2017 5
J. Lienig and H. Bruemmer, Fundamentals of Electronic Systems Design,
DOI 10.1007/978-3-319-55840-0_2
6 2 Design Process and Its Fundamentals

Recovery

Sales
Sales,
Profit Profit

Costs Loss

Time

Product Design/ Production Roll Growth Maturity Saturation Decline

planning Development out

Development stage Marketing stage

Fig. 2.1 Development and marketing stages for a product [1, 2]

the competition are known. The maturity stage is superseded by the saturation
stage, where there is only low or no growth. As more players enter the market, the
sales price comes under increasing pressure. Direct costs are driven down by
increased productivity. But, despite this, the relationship between sale price and
direct costs is increasingly reduced. Finally, during a period of decline, the product
is typically forced from the market by the competition or by the other substitute
products.
The development process for an electronic system described in this book begins
with the product planning stage. During this initial planning period, ideas for
products are generated and assessed, and project tasks are formulated. The subse-
quent design and development stage uses as input the functional specification
developed with the product proposal. At the end of the design and development
stage, the complete product documentation containing all instructions for product
fabrication, use, maintenance, and disposal (including recycling) is produced.

2.2 Design and Development Process

The design and development of an electronic system or device is a key element of

the preparations for manufacture; in essence, function, quality, and costs are defined
at this stage. The design process encompasses all creative, manual, and technical
activities necessary to define the product and which need to be carried out to
2.2 Design and Development Process 7

convert a system definition to a sufficiently detailed system design specification for

product manufacture and deployment.
Before we proceed, it is helpful to clarify a bit of terminology. The term “de-
sign” typically covers the first prototype for a system or a device, while the term
“development” generally includes the production of the documentation (e.g., circuit
diagrams for electronic modules, drawings for mechanical components) necessary
for fabrication. As it is often difficult to differentiate these two terms, they are
considered as synonyms throughout this book.
Design and development can be divided into four stages, each with different
definitions [1]:
– task definition (informative definition),
– conceptual stage (cardinal definition),
– design stage (formative definition), and
– implementation stage (manufacturing definition).
Information is gathered on the requirements for the product to be developed
during task definition. The result is an informative definition in the form of a
requirements specification. These requirements are then transformed into an optimal
technical principle at the conceptual stage. The cardinal definition of a solution is
thus formulated here along with proof of functionality.
A system design based on the conceptual solution is presented at the design
stage. The objective is to determine the best overall design for the product taking
technological and economic constraints into consideration. Finally, fabrication and
usage details are set out at the implementation stage to facilitate manufacturing and
deployment.
Engineering guidelines usually define seven steps for the design and develop-
ment process, which add further details to the four stages above:

1. Detailing the system definition and the requirements specification Task definition
2. Establishing functions and their structures
Conceptual stage
3. Searching, assessing and selecting solutions
4. Splitting the systems to be developed into
individual modules
Design stage
5. Designing the individual modules
6. Designing the entire system, including installation plan
7. Developing the fabrication, use, maintenance and disposal Implementation stage
details, building a prototype (optional).

Figure 2.2 shows the steps involved in the overall product design process.
A number of variants, which subsequently need to be optimized and streamlined,
are produced in several of the steps. Design teams often use creativity techniques,
such as brainstorming, to produce these variants. Variants are optimized and
eliminated with the help of selection and assessment methods, such as weighted
lists [1].
8 2 Design Process and Its Fundamentals

Product Technical Documentation

requirements requirements for fabrication,
document document use,
(product- (functional maintenance
proposal) specification) and disposal

Create Eliminate Create Create Eliminate

variants variants variants variants variants

Search Product System Require- System Functional Working Principal System Product
fields ideas definition ments spec function structures structures solutions design documentation

Task Design Implementation

Conceptual stage
definition stage stage
Product planning

Design and development

Fig. 2.2 Steps and results of the product planning and development processes. Development
effectively begins with the system definition based on the product proposal. The development
work is divided into the task definition and the conceptual, design and implementation stages. How
variants are produced and eliminated is also shown

At the end of the design and development process, a prototype is typically

produced. This first prototype should be tested under conditions that replicate as
closely as possible the conditions that will be encountered later in real-world
scenarios.

2.3 Guidance for Product Planning, Design

and Development

In today’s consumer-driven industry, development departments must respond

rapidly to market changes. They need to draw up a work schedule along with cost
estimates to ensure optimal use of resources. This is particularly critical for more
complex systems, where knowledgeable specialists from a wide range of back-
grounds are often involved. As a prime example of a complex system, we shall
examine a “vending machine” whose block diagram is shown in Fig. 2.3. The
vending machine example will illustrate key concepts and steps that design teams
will use for a broad range of consumer and industrial products.
2.3 Guidance for Product Planning, Design and Development 9

Fig. 2.3 Block diagram of a

Master controller

Data acquisition
vending machine

Power supply
Subsystem 1

Subsystem 2

system
Panel
Data and control bus

In our vending machine example, the user selects an item via a panel with
keyboard and screen which also displays the price. Coins are identified and their
values determined by the cashier unit (subsystem l). The coins are stored in the
device. The machine gives change if needed on a command from the master
controller.
The development of an electronic coin validator with high detection reliability
for counterfeit coins and other currencies requires a team of qualified electronic,
mechanical, and test engineers, drawing upon their specialized knowledge. The
system definition needs to be precisely formulated; duties and responsibilities
should be clearly set out so that there is very little wasted capacity. The same
applies to the merchandise storage space (subsystem 2) and associated output unit
with actuator.
The master controller checks all operations in the vending machine. When a
button is pressed and an item is selected, the price is read from an electronic price
register and displayed. When payment is received, the controller calculates the
difference between the sale price and the value of the inserted coins and displays it
on the screen. If change needs to be given to the customer, the cashier unit returns
the largest coins possible. The master controller controls all drives in the vending
machine, calculates the values for data acquisition, and outputs an alarm message in
the event of a fault in a module.
The data acquisition system stores sales transactions over a longer period and
gathers statistics. The power supply unit powers circuits, screens, and actuators.
All functions and subfunctions must be accurately defined when designing such
a system, to ensure correct operation. Even in this introductory example of the
vending machine, we can see how complexity grows as our requirements become
more detailed and specific. We manage this complexity by defining high-level
functions, subfunctions, and interactions with which we will implement these
requirements. The specification also depends on the type of components and cir-
cuits to be used; for example, conventional digital logic or a computer could be
deployed as master controller. The project engineer is therefore required to inves-
tigate and define the system early in the project. As the number of people involved
10 2 Design Process and Its Fundamentals

in the project grows, so too do costs and coordination issues. It is therefore

imperative from a business perspective that joint activities within the team be
effectively scheduled.

2.3.1 Planning Development Work

The argument is often made that development work cannot be planned. However,
this is not correct, as the truly creative work only takes on average 10–15% of the
total project time, with the remaining time taken up with well-defined tasks that will
transform these creative ideas into a viable product. Workflows and planned times
for such tasks should be defined by the engineers involved in the project, as they are
the only people with the necessary knowledge.
First, as much information as possible should be collected on the project. The
mission should then be formulated. Subsequently, different solutions will be
developed and evaluated. Once the best solution based on the requirements spec-
ification has been selected, the system to be developed is defined, the engineering
work is set out, and projected costs are calculated.
The timetable for the design process should not be seen as a restriction on the
work of the development engineers or as pressure on them. Rather, its purpose is to
make the complex decision process more transparent and get superiors involved.
Indeed, management has to take responsibility for decisions. More often than not
they have a better understanding of how the overall system fits in the marketplace
and of customer concerns, but have less detailed system knowledge.
Project planning increases the likelihood of success by preventing false starts; it
permits the development engineer to start a project only after all solutions have
been examined and assessed; and the design criteria established as per the
requirements specification. The project engineer should study all technical details
before starting any development work.
He/she should document all his/her reviews and investigations as well. This is
very important, so as to allow others to participate in decision making for certain
solutions or for the entire project, and to understand later why and how certain
decisions have been made. In addition, as new engineers join the team, they can
quickly come up to speed by reviewing such documentation and understanding key
decisions.

2.3.2 Information Flow

The development engineers should work closely and continuously with the cus-
tomer right from the start. The customer is the company’s customer in the case of
stand-alone, customized devices. Sales, i.e., the marketing department, often
assumes the role of the customer for standard, mass-produced products. Typically,
2.3 Guidance for Product Planning, Design and Development 11

they know the problem to be solved, but not the deployed technology. The opposite
is true for development engineers. Hence, unnecessary delays and costs will be
avoided when there are competent contact persons on both sides, working closely
together in an iterative, collaborative manner.
Knowledge of certain merchandise groups and understanding the requirements
restricting the system to these merchandise groups is pivotal in the case of the
vending machine example introduced earlier. For example, overall costs can likely
be significantly reduced if very large or heat-sensitive items of merchandise are not
offered by the machine. Customer options to adjust the price register, the statistical
data gathered, the UX/UI (User Experience/User Interface), and the system design
are other topics that must be considered.
Direct contact between customer and the company’s development engineers will
facilitate a speedy and seamless system handover. Costs for the proposed solutions
should only come from sales people as they are the only people who know the valid
cost plan. The development team should be in close contact with the fabrication
department, as the manufacturing technology used in a company typically has a
major impact on product design.
Companies are often organized as per Fig. 2.4. The term “development” often
stands for the development department with its own R & D laboratory and design
departments and may be used to describe research laboratories as well.
All electrical, electronic, physical and chemical investigations, and experiments
needed for system development are typically carried out in laboratories in many
companies. Circuit diagrams and documentation, used, for example, for IC and

Management

Head of
Head of Head of general
development Head of testing Head of sales
fabrication administration
department

Development
Design
R & D lab 1 planning, schedule
department 1
monitoring

Design
R & D lab 2
department 2

Design
Test lab
department 3

Fig. 2.4 Organization chart of a company

12 2 Design Process and Its Fundamentals

PCB layout design and packaging, and technical drawings for mechanical com-
ponents are produced during these tests. Prototypes are also assembled and tested in
test areas at this time.

2.3.3 Feasibility Study During Product Planning

The system to be developed is first roughly described in a feasibility study during

product planning, in preparation for system development. It may also be possible at
this stage to determine the features a system should not have if system character-
istics cannot yet be clearly defined. The feasibility study typically contains details
on the application and the customers, an analysis of competitor systems (rival
products), and a rough estimate of the sales targets and required total investments.
The purpose of the feasibility study is to help the company decide whether or not
to go ahead with the project. The feasibility study need not be carried out if the
company executives decide to go ahead with the project for other reasons, such as
marketing.
A typical feasibility study for a vending machine, for example, would address
the following questions:
– What customers and what merchandise groups should the system be designed
for?
– What characteristics does the system need to have?
– Is the system an economically viable proposition for the customer considering
price and performance? Has the customer expressed maximums or minimums
for price or performance, respectively, and/or trade-offs between them?
– What is the expected sales volume for each customer group?
– How high are the maximum development and manufacturing costs for the
assumed price?
– What capital investments are required to manufacture the system?
– What is the competition, and what advantages and benefits should the system
offer over competing products?
– Are some of the system components, like the coin validator or the fully
assembled cashier unit in the example, available as purchase items? This might
be an option to eliminate development risks or cut development costs.

2.3.4 Task Definition and Conceptual Stage

The development process starts when a product requirements document is produced

during product planning or there is a definite customer order. First, the system
definition will be detailed (task definition) by collecting all necessary data from all
available sources. Among the topics covered are: establishing the state of the art of
2.3 Guidance for Product Planning, Design and Development 13

the given technology, standards and norms, legal issues, the protection of utility
models and patents, and any necessary authorizations.
The task definition reduces the level of abstraction for the design solution, and it
becomes more concrete. At the same time, it defines the functional specifications for
the development process.
The task definition produces the functional specification based on the customer
product requirement document (Sect. 2.3.5). This functional specification thus
contains, from the developers’ view point, the company’s specifications for
building the system.
An intermediate report should be produced after the task definition. A decision
will be taken about continuing the project based on this report. Solution options will
then be identified for the proposed system, and standards for selecting the optimal
solution will be formulated as well. The following tasks will then be carried out:
– Drafting the definitive functional specification (Sect. 2.3.5).
– Further detailing of the selected solution for identifying any major problems and
drawing up a project structure plan (Sect. 2.3.6).
– Defining the reliability data and the maintenance intervals.
– Performing trials for components that have not been proven yet. These tests may
continue until the end of the development period. Alternative solutions may be
needed.
– Drawing up a training program for service personnel and producing service
documentation for the course.
– Determining criteria (e.g., functions, costs, and time) whose compliance is
required for securing the project. These criteria should be reviewed regularly
during the project.
– Drawing up a development time schedule (Sect. 2.3.6) and a report with rec-
ommendation (or disapproval) to continue with the project.
The design stage should only start if the solutions submitted after the conceptual
stage have been successfully verified. Junior engineers often make the mistake of
ending the conceptual stage too soon, i.e., they start designing components too
quickly before all solutions have been identified and assessed.
The project work described here is often affected by modifications to the system
definition after the functional specification has been drafted and before the system is
deployed. These changes could be caused by market changes, by rivals, or by other
technical requirements from the customer. The impact of such changes on delivery
dates and costs can be more accurately estimated if sufficient design and engi-
neering documents are available when such a situation occurs.
Executing the project as described above brings transparency to planning and
decision making for higher management, and increases the chances of technically
and commercially successful project completion.
14 2 Design Process and Its Fundamentals

2.3.5 Functional Specification

The design and development process starts with a functional specification, typically
outlined in a technical requirements document. This is a list of requirements the
system has to comply with, along with the technical definitions of the operating
environment. These requirements are the technical response to a matching
requirements document, the product requirements document, created from a user’s
point of view by the contracting party or the product planning department. Hence,
the functional specification contains engineering details for developing the system
based on the product requirements document from the customer.
Requirements should be ordered according to their priority:
– Requirements that the system must fulfill for the targeted customers,
– Features that could attract a wider group of customers if the price is not
increased at all or is only marginally increased, and
– Low-priority requirements that do not necessarily have to be complied with
(“nice to have”).
A typical functional specification will contain the following:
– Precise description of the system definition (what is the purpose of the product
or system?),
– Description of the interfaces to the environment, such as other technical systems
and humans,
– Size and weight definitions and installation conditions,
– Definition of the operational and environmental conditions,
– Standards of precision,
– Functional safety,
– Service life duration,
– Maintenance and repair requirements,
– Standards and regulations, such as mandatory standards,
– Storage conditions, transportation requirements, and packaging,
– Sales volumes,
– Approved development and manufacturing costs, sales price, running costs at
customers, and
– Deadlines.
By asking product-specific questions, such as “Does the customer have expe-
rience with similar devices or components?” “What characteristics should the
product not have?”, additional information is often obtained that should be defined
a priori.
2.3 Guidance for Product Planning, Design and Development 15

2.3.6 Scheduling

Scheduling the design process can be a major challenge. There is no question that it is
needed; management rightly demands specification and compliance with deadlines
and costs from engineering departments. Proper scheduling helps avoid frustration
and costly delays, which can adversely affect both management and engineering
“enthusiasm” for the project. As the saying goes, plan the work, then work the plan.
A number of requirements must be fulfilled to create a useful planning system.
The activities of different employees and departments in product development must
be coordinated and scheduled. A network plan is particularly useful in this regard
for large projects. This type of time schedule shows all project activities and their
mutual dependencies in graphic form, as will be explained later. The following
conditions need to exist for a successful network plan:
– The planning system must match the organizational structure;
– A competent member of staff should be responsible for planning and
scheduling;
– All employees should be familiar with the planning system and should endorse it; and
– Sufficient time is allocated for the preparatory study and planning.
There is a difference between the planning system and its data. A lot of publi-
cations are available on different planning systems and techniques [1, 3].
A project structure plan (Fig. 2.5) is typically drafted when preparing a pro-
posed development solution. This is a simple and self-explanatory schematic

Vending machine

Master Data
Power
Level 1 controller Panel Subsystem 1 Subsystem 2 acquisition
supply
and bus system

Detailed
Arithmetic / Data and Error control
Level 2 Master clock Interfaces PCB design integrated
logic unit control bus unit
concept

Quarz Frequency
Level 3
generator divider
No.
Task,work

Department
responsible

Scheduled project Materials and

duration other costs

Fig. 2.5 Section of a project structure plan for the vending machine depicted in Fig. 2.3
16 2 Design Process and Its Fundamentals

representation of the work needed to complete the project. The individual levels in
the project structure plan indicate the different subtasks and their relationships to
higher- and lower-level tasks. The subtasks, representing the final items of the
schedule, are called work packages.
The project structure plan is not yet the network plan. The former should always
be drafted to ensure that no critical items are overlooked in the latter.
The work packages should be small enough to allow accurate time estimates for
their completion. Practicable time units, such as hours, working days or weeks,
should be used. The more detailed the work description, the more accurate the
scheduling. And the more detailed the information available on the tasks, the better
the resulting plan will be. One of the purposes of the preparatory study is to
examine the less clearly defined topics and to gather as much information as
possible on them. The work will need to be divided into smaller packages if some
issues remain unresolved. A review will then be carried out at the end of each work
period, and work rescheduling may be necessary.
When estimating times, remember that development engineers are often sidelined
from their design work such as they may spend up to 40% of their time at meetings,
talking on the phone, writing e-mails, and doing other works.
When the project structure plan has been drawn up, the work packages are
divided into processes. A process is a time-consuming activity with a defined start
and finish. Another process attribute is that it incurs costs. Additionally, a process is
performed without a break from start to finish.
Individual processes in a project cannot be performed in any order. It may be
necessary to start a given process only when other processes are complete. This
gives rise to relationships and dependencies.
The logical project plan is defined and the network plan can be drawn up when
the predecessors and successors for individual processes have been established
(Fig. 2.6). It is sometimes easier to draw up the network plan starting with the
project end date and “work backwards.” This is because it is often simpler to

Detailed
Data and
Start integrated Interfaces
control bus
concept

Master clock

Arithmetic /
Panel
logical unit

Fig. 2.6 Section of a network plan (activity-on-node network) based on the project structure plan
for the vending machine in Fig. 2.5
2.3 Guidance for Product Planning, Design and Development 17

No. Calendar week

7 8 9 10 11 12 13 14 15 16
Description

1 Detailed integrated concept

2 Data and control bus

3 Interfaces

4 Master clock

5 Arithmetic / logical unit

6 Panel

Fig. 2.7 Section of a bar chart

establish what needs to be done before a process is started than to determine the
steps needed after its completion.
The earliest and latest start and end times for individual processes are calculated
from the relationships and time estimates. There will be many free periods (buffer
periods) available for many processes. The path from the start to the end of the
network plan, where there are no buffer periods, is called a critical path.
Finally, the time units used for planning are converted to calendar dates to build
a bar chart or Gantt chart (Fig. 2.7). The following must be known for calendar
planning:
– the project start date (calendar date),
– holidays during the project period, and
– the planning unit (days, weeks).
A bar chart can be produced without creating a network plan with projects that
have very few processes and very few mutual dependencies.

2.4 Technical Drawings

All parts have to be uniquely and adequately described for fabrication in the pro-
duct documentation generated at the end of the design and development process [4].
Freehand sketches of components, modules, and systems in compliance with
standards should be read and produced at the conceptual stage. Typically, devel-
opment engineers are required to deliver complex, often computer-based, technical
drawings.
In order to communicate all needed information from the development to the
fabrication process, a technical drawing must include the following critical
information:
18 2 Design Process and Its Fundamentals

– geometry, i.e., the shape of the object, how the object will look when it is
viewed from various angles,
– dimensions, i.e., the size of the object in accepted units,
– tolerances, i.e., the allowable variations for each dimension,
– material, i.e., what the object is made of, and
– finish, i.e., the surface quality of the object.
Using such standardized illustrations ensures global understanding and porta-
bility of the specifications and avoids misconstructions. A set of drawings for a
system is made up of a number of items:
– main or general drawing (mandatory),
– group or module drawings (if required),
– detail part drawings (mandatory for all parts to be manufactured),
– bill of components (contains all system parts, also standard or purchased parts; it
is mandatory), and
– assembly drawing (optional).
The right-angled parallel projection as per ISO 128-30 [5] has established itself
as the benchmark for parts drawings. It has the advantage that all views can be
displayed undistorted and true to scale with all dimensions. The front and side
views are produced by the orthographic projection, which is the standard technique
for drawing a physical object in different plan views (Fig. 2.8).
An object can have six views, whose defined location and orientation to one
another are derived from the orthographic projection (Fig. 2.9):

Bottom view
Side view from the right Front view Side view from the left Rear view
Top view

Fig. 2.8 Orthographic projection of an object for representing the front and side views. All visible
object edges and the silhouette are shown in the viewing angle for each view
2.4 Technical Drawings 19

Fig. 2.9 Six views of an object are generated by projecting in the respective planes of a
rectangular expandable projection box. The side view from the right, for example, is located on the
left of the front view (see Fig. 2.8), and the bottom view is located above it

For engineering documentation, the views drawn are typically a subset of all six,
namely only the ones needed to uniquely render the object. As an example,
Fig. 2.10 pictures an object in all six views and Fig. 2.11 shows only the necessary
views to be drawn.
The size of a drawn object when it is increased or reduced in size with respect to
the original is indicated with a scale. While a scale of 1:1 represents the original
size, enlargements may be represented by scales of 2:1 (20:1, 200:1, etc.), 5:1 (50:1,
500:1, etc.) and 10:1 (100:1, 1000:1, etc.). The same applies to size reductions that

Bottom view

Side view Front view Side view Rear view

from the right from the left

Top view

Fig. 2.10 Six possible views of an object and their orientation to one another
20 2 Design Process and Its Fundamentals

Fig. 2.11 Object in Fig. 2.10 can be uniquely shown in four views (front view, side views from
left and right, bottom view)

can be drawn in the scales 1:2 (1:20, 1:200, etc.), 1:5 (1:50, 1:500, etc.) and 1:10
(1:100, 1:1000, etc.) [6]. The scale is specified in the title block on the drawing [7].
Sectional views, also known as sections, are used to illustrate features inside an
object or to reduce the number of views (Fig. 2.12) [8]. Cut surfaces are shaded,
and cut surfaces for the same part are shaded in the same way. Every sectional view
is based on a non-sectional view of an object. The location of the sectional view on
the unsectioned object may be indicated by a dash-dotted line for clarity purposes.
The viewing direction is marked with arrows. Note that complete workpieces, such
as shafts, pins, and screws, remain unsectioned in a sectional view [8].

Fig. 2.12 Sectional views from front and top views for the object in Fig. 2.10 illustrate the
locations and orientations of the holes, in particular
2.4 Technical Drawings 21

If the depicted object is drawn for manufacturing or testing, it must be uniquely

dimensioned (Fig. 2.13). There are different types of dimensioning: function-based
(functional dimension, i.e., the dimension is essential to the function of the piece or
space), production-related (the dimension is relevant for manufacturing), and
test-related dimensioning (inspection dimension). A functional dimension is spec-
ified only when needed. Functional dimensions should be specified first in a

Fig. 2.13 Object in Fig. 2.10 with production-related dimensioning. There is no need to specify
tolerance for the individual dimensions as general tolerances are specified in the title block (“ISO
2768–mK”, not shown in the figure here). Solid surface specifications that specify an average
surface roughness of 6.3 µm to be achieved by material abrasion are given bottom right. The
bracketed expression indicates that there are also surfaces with different tolerances (individually
labeled in the drawing)
22 2 Design Process and Its Fundamentals

drawing, followed by the production-related dimensions and the inspection

dimensions. Inspection dimensions are typically used in inspection drawings only.
Every dimension should be quoted with a tolerance value as no part can be
perfectly manufactured. General tolerances, which apply to all dimensions in the
drawing and which are specified in the title block, should be preferred (see
Fig. 2.13). Other options include (1) the ISO system of limits and fits which is a
worldwide coordinated system of hole and shaft tolerances, and (2) manually
specifying tolerance limits (see Chap. 8.2).
In recent decades, technical drawings have increasingly been prepared using
computer technology with its CAD systems. Software programs for 2D drawings
that provide different views of an object were initially developed, which essentially
replaced paper-based drawings with digital ones. Today’s CAD packages add new
functionality to technical drawings; not only can objects be represented in 3D, they
can also be optimized with comprehensive 3D modeling (Sect. 2.6).
Chapters 8.1 and 8.2 contain the most important instructions and guidelines for
technical drawing; Chap. 8.3 contains preferred numbers and dimensions to be used
in the design process.

2.5 Circuit Diagrams

Modern systems contain mechanical and electronic components. Circuit elements

and their interactions must be represented in circuit diagrams, also known as circuit
schematics. Development and design engineers need to understand circuit diagrams
and know how to produce them. A circuit diagram is a symbolic description of a
circuit showing the circuit elements and the links between them. The layout of the
components in the diagram is not the same as the position of the elements and the
connections in the actual implementation. The main purpose of the circuit diagram
is to show the logical and electrical functions and interconnections of the circuit. It
contains the following elements (Figs. 2.14 and 2.15):
– symbols
– device labels (ID letter with consecutive numbers),
– device type or rating,
– electrical connections (interconnects, bus systems),
– back-annotation data (optional), and
– frame and title block.
The symbols found in a circuit diagram can be either elementary symbols for
resistors and other component symbols, or block symbols, e.g., subcircuits.
Each symbol has a unique label composed of a letter, which defines the com-
ponent type, followed by a serial no. (C4—capacitor no. 4, D1—digital gate no. 1,
R12—resistor no. 12). The component type (e.g., gate 74ACT04D) or value (e.g.,
resistance 10 k) should be written beside the symbol as well. The engineering unit
2.5 Circuit Diagrams 23

Fig. 2.14 Section of a circuit diagram with digital components (AND gates, OR gates, two
inverters) in IEEE/ANSI/IEC standard format (left) and traditional schematics format (on the
right). The letters A or B added to the labels D1, D2, and D3 indicate copies (instances) of a library
element. Elements D2A and D2B are copies A and B of inverter 74ACT04D in the library in this
example. Both gates are contained within the chip package D2

Fig. 2.15 Exemplary circuit diagram (with no frame or title block) with an operational amplifier
and different analog components (resistors, capacitors, connectors, photodiode, Zener diode, LED,
transistor). Each symbol is followed by a letter with a serial no. and the type and/or value of the
component. The engineering unit (e.g., ohm or X) is not cited

(e.g., ohm or X) is not written with the values. Pin numbers are specified where
necessary to avoid ambiguities (e.g., with integrated circuits, connectors) and when
they are not already defined by the symbol (as with the transistor).
Digital elements are typically located in a common IC package despite being
drawn individually in the circuit diagram. This assignment can be indicated in the
schematic view. For example, D2A and D2B are two copies A and B of a type
74ACT04D inverter, which are contained in package D2 (Fig. 2.14 and Chap. 8.4).
The following connections are deployed in a circuit diagram:
– lines: of no electrical significance, for decorative purposes only, e.g., borders;
– wires: pin-to-pin interconnects of signal paths, signal name is optional; and
– bus systems: bundling many signal paths, signal name is obligatory, every signal
has the same name and a different index.
24 2 Design Process and Its Fundamentals

Back-annotation data are details gathered during the design steps that follow
circuit design, e.g., layout design, which you “write back” in the circuit diagram to
consider them in the future. Current values for specific interconnects calculated in
the layout could be inscribed in the circuit diagram, for instance.
A completed circuit diagram is used in the design process for electronic circuits
to generate a net list. This net list, along with device information loaded from
libraries and technology information, is then used to produce the implementation
arrangement, the layout, for the integrated circuit (IC) or the printed circuit board
(PCB).
Please refer to the end of the book (Chap. 8: Appendix) for more information on
circuit diagrams and components. Nominal values for devices based on the pre-
ferred numbers are defined in Chap. 8.3. Chapter 8.4 contains a list of symbols for
devices for use in the circuit diagram, and Chap. 8.5 introduces labeling options of
electronic components (colors, characters).

2.6 Computer-Aided Design (CAD)

Computer-aided design (CAD) is the application of information technology to aid in

the creation, modification, analysis, and optimization of a design. CAD features
include:
– producing and using computer models for different disciplines (e.g., mechanics,
electronics, heat transfer, fluid mechanics, magnetics) to find suitable and/or
optimized solutions;
– deriving direct production information (e.g., rapid prototyping, CNC
(Computerized Numerical Control) fabrication); and
– generating product documentation (e.g., technical drawings, production docu-
ments, manuals).
A CAD model is typically seen as a computer model of a device or a system that
includes its geometric and material properties. That said, it can also reflect and
optimize the different requirements that need to be considered in the design and
development process of a device or a system (Fig. 2.16).
The CAD model represents the system design status at a specific time in the
design process. The first version of a CAD model is typically produced at the end of
the conceptual stage in the design process, modeling the geometric and material
properties of the conceptual solution.
Additional numerical “special-purpose models” cover selected requirements
based on the current state of the CAD model. Among these extra models are
finite-element models for heat issues, structural mechanics, and electromagnetism
as well as electrical and timing circuit models.
For many decades, computer-aided design has played a key role in the design of
complex VLSI circuits with millions (and now, billions) of gates.
2.6 Computer-Aided Design (CAD) 25

Environmental protection Reliability Elektromagnetic

- design for recyclability - durability compatibility (EMC)
- failure rate - shielding
- ESD

Heat dissipation
- thermal
management CAD model Design, ergnomics
- cooling - color, material
- UX/UI

Device protection System configuration

- protection class - geometric-material Pricing,
- IP code - functional cost efficiency

Fig. 2.16 CAD model at the heart of the system design process. Besides modeling the geometric,
material and functional device/system configuration, other special-purpose models, such as
finite-element models for optimizing heat dissipation, can be built for specific requirements in the
design process

Geometric-material aspects of the electronic circuit are taken into consideration in

the CAD model, e.g., as external interconnect and pad dimensions for the associated
electronic devices. “Special-purpose models” form the basis for the following
activities:
– producing a circuit diagram from a digital logic description,
– simulating and verifying the circuit function(s),
– automated design of the layout for the substrate (IC and PCB), and
– verifying the layout against the design constraints.
Simulation runs based on these “special-purpose models” are typically used to
analyze the system for improvement with respect to individual requirements. The
results of these analyses lead iteratively to an optimized CAD model for the system
to be developed, whereby the geometric and material design characteristics are
modified. CAD models thus assist the engineers in iteratively optimizing the
technical solution throughout the design process.
We will show how a detailed analysis can be performed based on the
geometric-material CAD model with an example of a simple mechanical rubber
stop. The rubber stop consists of two carbon steel disks, with a rubber sleeve
between them, acting as a resilient and damping element (Fig. 2.17).
The CAD model of this rubber-stop assembly is made up of the CAD models of
two identical carbon steel disks and a rubber sleeve (Fig. 2.18). The relationship of
the components to one another is described in the assembly model with parame-
terized assembly dependencies (e.g., “Insert” for parallel and concentric orientation
of circular surfaces).
26 2 Design Process and Its Fundamentals

Fig. 2.17 Rubber-stop

assembly made of a rubber
sleeve with two carbon steel
disks at each end

Fig. 2.18 Assembly

dependencies in the CAD
model of a rubber stop

Suppliers usually provide CAD models for purchase parts. The CAD models are
available in the libraries of CAD systems for standard parts (e.g., screws and nuts).
CAD models need to be generated for custom-designed components only.
The user can gradually produce three-dimensional (3D) geometrical models of
parts from two-dimensional (2D) sketches with geometrical operations (e.g.,
extrusion or rotation about an axis). The sketched contour of the circular cross
section is extruded to create this rubber sleeve model (Fig. 2.19). The model could
also be created by rotating a rectangular sketch about the z-axis.

Fig. 2.19 Producing the

3D-geometric model from 2D
sketches (volume of rubber
sleeve)
2.6 Computer-Aided Design (CAD) 27

In addition to this example, CAD systems feature the following options:

– Complex geometrical shapes can be created from basic elements with Boolean
operators (e.g., union, difference, average).
– Standard form elements (e.g., holes, screw threads, bevels) are supported by
features in CAD systems. All you need to do then is place a form element (e.g.,
bore hole) at the desired position and configure it (e.g., with a screw thread or
counterbore).
– Dimensions used in the geometrical operations and form elements in the 2D
sketches can be modified at any time in the design process. All dependent
dimensions will automatically change as well, including the component
arrangements in the assembly, for example.
In addition to utilizing these capabilities for creative design, development
engineers still also use CAD systems for generating sets of drawings from the 3D
geometric models. The required dimensioned, scale views can be semi-automatically
generated in the part drawings (Fig. 2.20).
So-called exploded views can be produced as well. They are especially suitable
for highly complex structures at the component level to illustrate the assembly of
parts and subassemblies. Figure 2.21 shows an example of the basic rubber-stop
assembly with a semi-automatically generated parts list.
Besides using CAD systems to produce a set of drawings, they are also applied
in finite-element simulations (FE simulation) to analyze the mechanical character-
istics of components. The finite-element models are automatically generated based
on the 3D-geometrical models. The example in Fig. 2.22 shows the vonMises
equivalent stress distribution in the rubber sleeve when external compressive forces
are applied only on the hole edges of the carbon steel disks. We can determine
where the maximum stress occurs by means of mechanical finite-element simula-
tion. The shape of the part can thus be optimized at these critical locations based on
these simulation results.
A dynamic simulation of mechanical assemblies can be carried out as well as the
static loading on the parts with finite-element models. The behavior of elastic
materials in real time can be investigated. This typically requires long computation
times. Simplified analogous models based on network analogies are often used for
this purpose:
– Body masses are modeled as point masses placed at the center of gravity of the
real object.
– Body elasticities are modeled as springs with a parameter for the spring rigidity.
– Damping characteristics of bodies are modeled as damper elements with a
damping constant.
The decay response of the oscillation after an excitation can be analyzed for the
exemplary rubber stop in Fig. 2.17 with the following dynamic analogous model
28 2 Design Process and Its Fundamentals

Fig. 2.20 Dimensioned drawing view of a part (rubber sleeve)

PARTS LIST
OBJECT QUANTITY PART NUMBER DESCRIPTION
1 1 Rubber 128713 Rubber sleeve
2 2 Disk 357518 Carbon steel disk

Fig. 2.21 Exploded view of an assembly (rubber stop) with parts list

(Fig. 2.23). The carbon steel disks are simplified as rigid elements and the rubber
sleeves as massless elements. Some of the required concentrated parameters for the
network elements, such as the masses of the individual objects, can be taken from
the CAD model. Other parameters, such as the spring rigidity as a quotient of the
pressure force and deformation, can be determined from the static finite-element
simulations. The damping constant of rubber has to be obtained from the material
data or the measurements.
The geometric and material properties of the CAD model are iteratively modified
with the results of these simulations. The future characteristics of the entire
2.6 Computer-Aided Design (CAD) 29

Fig. 2.22 A finite-element simulation where the stresses in the rubber sleeve are determined for
compressive forces at the hole edges

Rubber sleeve
Carbon steel disk 1
with additional mass

Rubber sleeve

Carbon steel disk 2

with additional mass

Fig. 2.23 Dynamic analogous model of the rubber stop in Fig. 2.17 with simulation results,
showing the decay response of its oscillations after an excitation

electronic/mechanical system can thus be determined using the CAD models, which
enables us to develop and simulate the desired optimal solution before undertaking
its actual physical implementation.

References

1. G. Pahl, W. Beitz, J. Feldhusen, K.-H. Grote, Engineering Design: A Systematic Approach,

Springer, 3rd edition. 2007
2. F. Kramer, Innovative Produktpolitik, Strategie—Planung—Entwicklung—Einführung,
Springer, 1987
30 2 Design Process and Its Fundamentals

3. H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling, and

Controlling, Wiley, 11th edition, 2013
4. ISO 29845:2011, Technical product documentation—Document types, online at www.iso.org
5. ISO 128–30:2001, Technical drawings—General principles of presentation—Part 30: Basic
conventions for views, online at www.iso.org
6. ISO 5455:1979, Technical drawings—Scales, online at www.iso.org
7. ISO 7200:2004, Technical product documentation—Data fields in title blocks and document
headers, online at www.iso.org
8. ISO 128-40, 44, 50:2001, Technical drawings—General principles of presentation—Part 40:
Basic conventions for cuts and sections, Part 44: Sections on mechanical engineering
drawings, Part 50: Basic conventions for representing areas on cuts and sections, online at
www.iso.org
Chapter 3
System Architecture and Protection
Requirements

Having dealt with the major steps in the development process and the necessary
drafting skills, we now move on in this chapter to the system itself, i.e.,
system-level functions and structures (Sect. 3.1), design variants (Sect. 3.2), and
various technological implementations (i.e., electronic system levels) for a design
solution (Sect. 3.3). These implementation options allow a development engineer to
identify opportunities for modularization early in the design process to reduce costs
and shorten the development timeline.
System protection issues should also be considered during development
(Sect. 3.4). Each module and the electronic system must be designed so that it
does not pose a risk to humans or to the environment. In addition, compliance with
statutory requirements, such as, protection against electric shock (protection classes),
protection against accidental contact, and protection against ingress of foreign
objects or water (IP codes), is mandatory.

3.1 Introduction—Terminology, Functions and Structures

Electronic systems are functional and technical units whose operation allows the
requirements of a technical system definition to be met. The primary characteristics
of such systems include information flow, comprised of information acquisition,
processing, transmission, storage, and output. There are also systems, consisting
primarily of energy and material flows, in medicine, laboratories, and in the
household, which are not typically classified under mechanical engineering (as
“machines”) due to their miniature size and, hence, are considered here.
Each system performs an overall function and typically is comprised of modules
and components. Modules are self-contained complex units that function largely
independently. On the other hand, components are parts that cannot be broken down
further during development.

© Springer International Publishing AG 2017 31

J. Lienig and H. Bruemmer, Fundamentals of Electronic Systems Design,
DOI 10.1007/978-3-319-55840-0_3
32 3 System Architecture and Protection Requirements

3.1.1 System Characteristics of Devices

Complex devices, such as smartphones, and modules, such as printed circuit

boards, are treated as generic systems to generalize the design process. By applying
systems theory, devices and modules with different operating modes and com-
plexities can be treated consistently and developed using common processes.
A technical system may be characterized by its relationships with the environ-
ment E, required functions F and a structure S.
– The system’s environment E is the totality of objects and physical quantities
outside the system that relate to the system. These environmental relationships
are implemented as inputs and outputs.
– The function F is a system property designed for a given purpose that converts
the necessary inputs into defined outputs under predefined environmental con-
ditions. A printer’s ability to produce a graphical image from binary signals is an
example of such a property.
– The structure S of a system is the totality of its elements and their
interrelationships.
Certain elements and relationships in the structure are activated by functional
inputs and outputs, which execute the required function based on their character-
istics. Hence, the technical function characterizes the relationship between the
structure and the environment.
The development engineer must clearly define the characteristics E, F, and S to
describe a product satisfactorily in the technical requirements document (functional
specification, see Sect. 2.3.5).

3.1.2 System Environment

An electronic system must engage with its environment to function properly.

Environmental relationships can be described by the general functional model
(Fig. 3.1).
There are three interface categories between the system and environment that are
keys for system functionality and configuration. The development engineer needs to
envisage different environmental scenarios and implement the resulting functional
and technical requirements accordingly.
Processing layer (interface 1)
The purpose of a system is to execute, effect, or communicate predefined technical
operations. The system performs these operations internally by converting inputs IP
into outputs OP. This activity is called the system processing function.
3.1 Introduction—Terminology, Functions and Structures 33

(2) (1)
IC OC

IP OP
Electronic system

ID OD
(1) (3)

Fig. 3.1 Schematic view of the input (I) and output (O) relationships between a system and its
external interfaces (processing quantities IP, OP; communication quantities IC, OC; and
disturbances ID, OD). Interfaces (1) to (3) represent three interface categories related to the
processing, communication, and security functions of the system (see Sect. 3.1.3 and Fig. 3.2)

Communication layer (interface 2)

An information exchange may occur between the system and humans or other
technical products in technical systems. This operation takes place with commu-
nication inputs IC for guiding or controlling the processing function, and with
communication outputs OC as feedbacks for monitoring this function. These
operations are performed by a system’s communication function.
Disturbance layer (interface 3)
All non-functional inputs that impact (typically negatively) the system as distur-
bances ID, and the environment as outgoing disturbances OD from the system, are
handled in this layer. These disturbances are treated as independent variables.
Suitable measures need to be put in place to counteract these quantities, to secure
the system processing function, as well as sustain the required environment con-
ditions. These operations are part of the system security function.

3.1.3 System Functions

The number of functions a system can perform corresponds to its number of useful
physical characteristics. If the system fulfills many technical functions, the devel-
opment engineer needs to consider the relationships between such functions. The
processing, communication, and security functions mentioned above must be
identified based on the interfaces between system and environment (Fig. 3.2).
– The processing function converts input functional quantities into output func-
tional quantities under given environmental conditions. The conversion is
executed via collaboration between hardware and software. Information, energy,
and material flows all play a role in this function; as stated earlier, the infor-
mation flow typically dominates in electronic systems.
34 3 System Architecture and Protection Requirements

Fig. 3.2 System functions IC OC

(I input, O output) with
processing quantities IP, OP,
communication quantities IC,
OC, and disturbances ID, OD. Communication
Quantities DI, DO are internal function
disturbances, C signifies
internal control quantities, and C M
M signifies internal
IP OP
monitoring quantities [1] Processing
function

DI DO

Security
function

ID OD

There are two types of processing functions: primary and secondary.

Information processing is generally the primary (main) processing function in
electronic systems, with a secondary energy and material processing function. If
we take a printer, for example, the primary processing function is the conversion
of electronic data into printed alphanumeric and graphical information (infor-
mation processing), while blank paper is transformed into printed paper
(material processing) and electrical energy into mechanical energy (energy
processing) by secondary processing functions.
– The communication function is the information link between the device and the
user or other technical systems to execute the processing function. The com-
munication function also monitors the processing function by converting
internal monitoring quantities into external supervisory and monitoring
quantities.
– The security function performs three tasks, namely (1) protecting the processing
function from possible environmental disturbances; (2) protecting it from
system-internal disturbances; and (3) protecting the environment from system
faults.

3.1.4 System Structure

The system structure, i.e., the device (system) configuration, is a prerequisite for
carrying out the system functionality. The structure consists of the system’s parts,
the so-called elements, which are not further decomposed within the system, and
relationships, which describe the relationships between the system elements.
3.1 Introduction—Terminology, Functions and Structures 35

The development engineer should decompose the system into complexity levels
depending on the specific design task. For example, when designing a system with
complex functions, the engineer should treat complex purchase parts as single
elements without breaking them down any further.
A structure comprises the following complexity levels:
– Complex systems, composed of various systems, e.g., a monitoring system;
– Single systems, comprising modules and components of varying degrees of
complexities, such as a monitor;
– Modules as stand-alone groups of components that are linked together (modules
can also be viewed as components if they are supplied fully assembled, e.g.,
integrated circuits or switches);
– Components: these are individual elements—such as resistors—that cannot be
broken down any further.

3.2 System Design Architecture

An electronic system, as explained in Sect. 3.1, is composed of modules and

components. Modules, such as printed circuit boards, are separate, stand-alone
groups of interconnected components. A system can be designed in a variety of
ways depending on the modules’ functional and manufacturing requirements and
the intended applications. The development engineer should define the design
architecture early in a project, typically at the system-definition stage.

Design architectures are influenced by

– The granularity of the system configuration, i.e., the number of different
elements in the system (Sect. 3.2.1),
– How the system is to be assembled (Sect. 3.2.2), and
– How the system is to be integrated in its environment (Sect. 3.2.3).

3.2.1 System Granularity

The following design architectures are available to suit the degree of system
granularity:
– No pre-designed modules are used in the custom-assembled or compact design
approach. In this case, the system is designed as a fully assembled unit using
individual, custom-designed components. Small and compact dimensions can be
achieved with this approach; however, the amount of work involved is much
greater than with the following approaches.
36 3 System Architecture and Protection Requirements

Table 3.1 Standard levels and applicable norms for the 19-inch rack system in electronics
Level Standard items Standard
Level 1
– Printed circuit Printed circuit boards: printed circuits, IEC 60097, IEC 60249, IEC
boards substrates, grids, holes, nominal sizes, 60297
PCB measurements
– Components Components IEC 60326
– Connectors Connectors IEC 60603
Level 2
– Modules Modules: PCB, cassette, plug-in package IEC 60297
Level 3
– Front panels Front panels: width 482.6 mm (19″), IEC 60297
subrack heights and mounting
dimensions,
rack installation dimensions
– Subrack Subrack: dimensions with indirect IEC 60297
connectors
Level 4
– Enclosure Enclosure: installation dimensions, IEC 60297
enclosure stack
– Racks Racks: installation dimensions IEC 60297
– Panels Panels: panel dimensions, frame row IEC 60297
pitch

– The device is composed of self-contained functional modules in the modular

design approach. This method provides significant design rationalization, for
example, specific standard modules can be deployed with different device type
series, and individual modules can be modified for rapid development as
required.
– Extending the modular design approach across multiple companies by means of
standardization allows industry-wide standard module development. Various
different systems can be built based on a limited number of such module types.
These standard modules are common, recurring system elements that are
optimized and streamlined for combinability and reusability.
The 19-inch rack system in electronics is a prime example of the latter stan-
dardized modular design approach that has seen widespread use in industry since
1934 [2]. Its key features, such as standard levels with underlying applicable norms,
are listed in Table 3.1.

3.2.2 System Assembly

The design architecture can also be classified based on how the system is to be
assembled (Fig. 3.3):
3.2 System Design Architecture 37

Fig. 3.3 Different assembly methods of an electronic system: the conventional layer, stack or
sandwich assembly techniques (top), the nested assembly technique (middle), and the box
assembly technique (bottom)

– Each component is put in place on the base or on the component that was fitted
last in the layered, stack and sandwich assembly techniques.
– Components are largely put in place side by side with the nested assembly
technique (also: chassis system). Components are usually placed in a frame or
base element (in a chassis or a printed circuit board) that holds them.
Components can be placed in any order in the rack with this system.
– With the box assembly technique (also: shell or form-fit assembly), components
are held in place in the base and secured in position and orientation by a main
connecting element (retaining element).

This list of assembly methods is not exhaustive and not only determines how a
system is assembled, but also how easy it is to dismantle (Sect. 7.5). It should be
noted that, due to their hierarchical structure, many electronic systems use a
combination of the above assembly methods.
38 3 System Architecture and Protection Requirements

3.2.3 System Integration in Environment

Systems can also be classified according to the way they are integrated in their
surroundings, for example:
– The panel-mounted or surface-mounted device has fasteners that enable it to be
fitted into a higher-level device.
– The desktop or floor-standing device is an autonomous, stationary device, often
with stabilizing support elements.
– The portable device is designed for mobile use.

3.3 Electronic System Levels

One of the stand-out features of the modern development process is its high degree
of modularization. This means that functional groups in a device are typically
designed and manufactured in parallel, which can significantly reduce the overall
development timeline. Therefore, a development engineer should identify modu-
larization opportunities early in the design process to save time and costs.
Electronic functional groups are functionally and technically separate,
stand-alone units, whose functional elements are primarily based on the effect of
electrical quantities, such as current and voltage. These functional groups have
made rapid progress in recent years as the development of their underlying tech-
nologies, such as at the circuit level, allows exponentially increasing functional
densities (Moore’s law).
System levels have emerged as a useful grouping in the design of a system or a
module. They characterize the respective level of complexity of the associated
electronic functional groups (Fig. 3.4).
Each system level contains different functional groups:
– Discrete components are self-contained units manufactured to perform an ele-
mentary electrical function. They include passive components, such as resistors,
capacitors, and inductances, and active components such as transistors.
– Integrated circuits (IC) are composed of many elements permanently connected
electrically and mechanically to form a functional unit. Integrated circuits may
come as packaged (with enclosure) or unpackaged (bare dies).
– Bare dies and discrete components are connected electrically and mechanically
to form a functional and technical unit in multi-chip modules (MCM).
Historically, multi-chip modules are derived from hybrid modules, whereby
unpackaged integrated circuits based on different technologies are combined
with discrete components to create new functions, which are too expensive or
cannot be built using (monolithic) integrated circuit technology.
3.3 Electronic System Levels 39

System levels
Wafer
Level 0: Bare die
Monolithic silicon die
(integrated circuit, IC)
Packaged chip
Level 1: and MCM
IC packaging and wiring
components and IC in multi-chip
modules (MCM) Printed circuit
board (PCB)
Level 2:
Wiring components and IC
on printed circuit boards (PCB)
Level 3:
Wiring between PCB
(backplane wiring)
Level 4:
Wiring between
subassemblies (cabinets)
Level 5:
Wiring between systems

Fig. 3.4 Different system levels in an electronic system [3]

– Different components, including integrated circuits and multi-chip modules, are

connected together electrically on printed circuit boards (PCB). Printed circuit
boards are typically comprised of a base material as substrate, with added
copper layers to connect components and integrated circuits electrically. In
addition to rigid printed circuit boards, flexible printed circuit boards are
increasingly being deployed.
– Power-supply elements are functional units for providing a custom energy
supply, typically involving energy conversion, such as voltage transformation or
rectification. There are three types of power-supply units: (1) grid-powered,
(2) non-interruptible, and (3) autonomous.
– The purpose of external electrical interconnects is to connect modules and
systems to enable energy and information flow between them.

3.4 System Protection

Interactions between the system (device) under development and the environment
should be considered early in the design process. Device reliability and protection
criteria are more challenging today due to the broad application of modern systems,
coupled with the potential for extreme climatic conditions that may be encountered.
The requirements for successful product development include protection against
electric shock, protection against the ingress of foreign bodies and water, protection
against high temperatures (climate protection) and radiation (electromagnetic
compatibility), protection against the effects of implosion, inadequate stability, and
40 3 System Architecture and Protection Requirements

injuries caused by moving parts, and protection against fire. Specialist knowledge is
required for protection classes, IP codes, and thermal stress (Chap. 5) and also
increasingly for protection in connection with electromagnetic compatibility
(Chap. 6).

3.4.1 CE Designation

A product may only be sold and put in operation within the European Union (EU) if
it complies with all applicable EU Directives. A conformity assessment as per these
directives must be performed for electronic systems. Compliance is indicated by the
vendor or importer with the CE marking (Fig. 3.5).1 The CE marking is also found
on products sold outside the European Union that are manufactured in (or designed
to be sold in) the EU. This makes the CE marking recognizable worldwide.
Every vendor or distributor of an electronic device within the EU, who puts the
device into service, declares, by attaching the CE marking in a Declaration of
Conformance (EU declaration of conformity), that the device complies with all EU
Directives. This requires that the engineers who developed the device have
awareness of the respective EU laws. Essentially, the development engineer is
responsible for the correctness of this stamp of approval and thus, for compliance
with all relevant safety regulations and guidelines. An external test is only required
for devices that have increased risk potential.
The CE marking certifies that a product may be brought into service only when it
does not pose a risk to the health and safety of users or third parties. It is important
to note that this safety requirement also applies if the device is used incorrectly in a
foreseeable manner.

3.4.2 Protection Classes

One of the key aims of equipment protection is to protect the user against electric
shock; this is achieved by the use of protection classes (also called appliance
classes) [4]. They specify measures to prevent hazardous contact voltages on
unenergized parts of an electronic device. All electronic systems (devices) must
comply with one of the following three protection classes:
– Protection class I is not only based on the basic insulation, but also conductive
parts are also connected with a low-resistant protective conductor, also called
protective grounding. If, in the event of a fault, a current-carrying wire makes

1
It is said that “CE” originated as an abbreviation of Conformité Européenne, meaning European
Conformity, but this claim has never been officially confirmed. Other sources refer to “CE” as
Communauté Européenne (European Union).
3.4 System Protection 41

Fig. 3.5 CE marking is the manufacturer’s declaration that the product meets the requirements of
the applicable EU directives. The mark consists of the CE logo and, if applicable, the four digit
identification number of the notified body involved in the conformity assessment procedure

Protection class I Protection class II Protection class III

Fig. 3.6 Symbols for designating protection classes as defined in the international standard
IEC 61140 [4]

contact with the protective conductor connected to the enclosure, a high current
is able to flow in the “grounded” protective conductor, which triggers the fusible
cut-out, which in turn de-energizes the device. These types of devices are fitted
with a device connector with grounding contact, where the low-impedance of
the grounding protective conductor between enclosure and protective conductor
at the terminal plug must meet certain standards and requirements. The con-
nection to the protective conductor should be the first connection that is made
when the plug is plugged in, and it should be the last to be broken when the plug
is removed.
– Protection class II not only provides basic insulation, but also reinforced pro-
tective insulation. High insulation resistances are required for predefined test
voltages. The devices should not be connected with the protective conductor of
the installation, as protection is unlikely to be provided when the fusible cut-out
is triggered due to low-fault currents caused by the high-impedance enclosure.
– Protection class III offers protection by the exclusive use of a safety extra-low
voltage (SELV), which is (in many countries) 50 V for AC (rms value), 120 V
for DC, 24 V for children’s toys, and 6 V for medical systems for application
in the body. Devices with safety extra-low voltage are operated without a
protective conductor and should not be connected to the protective grounding of
the extra-low voltage generator or to other (live) parts under voltage.
The symbols depicted in Fig. 3.6 are used to designate systems with the
respective protection class.
Appliances with protection class 0 are prohibited in much of the world for safety
reasons as they have no protective-earth connection and feature only a single level
of insulation.
42 3 System Architecture and Protection Requirements

Table 3.2 Protection details designed for IP codes comprising at least two digits x1 and x2. They
are defined in the international standard IEC 60529 [5]
Digit First digit x1 Second digit x2
Shock protection Protection against Protection against ingress of
ingress of foreign water
bodies
0 No protection No protection No protection
1 Protection against random Protection against Protection against vertically
contact with the hand; solid foreign bodies dripping water
protection against access to 50 mm and more in
dangerous parts with the back diameter
of the hand
2 Protection against contact Protection against Protection against vertically
with the fingers; protection solid foreign bodies dripping water when the
against access to dangerous 12.5 mm and more in enclosure is tilting at an angle
parts with the fingers diameter up to 15°
3 Protection against contact Protection against Protection against spraying
with tools; protection against solid foreign bodies water
access to dangerous parts with 2.5 mm and more in
a tool diameter
4 Protection against contact Protection against Protection against splashwater
with tools and wires; solid foreign bodies from any direction
protection against access to 1.0 mm and more in
dangerous parts with a wire diameter
5 Complete protection against Protection against Protection against water jets
contact; protection against dust (dust-proof)
access to dangerous parts with
a wire
6 Complete protection against Protection against Protection against
contact; protection against dust (dust-proof) high-pressure water jets
access to dangerous parts with
a wire
7 – – Protection against temporary
immersion in water
8 – – Protection against continuous
immersion in water

3.4.3 IP Codes of Enclosures

The system protection also includes the protection of the device interior by the
mechanical casings and electrical enclosures of the system. This protection is called
IP Code, International Protection Marking, sometimes interpreted as Ingress
Protection Marking. The IP Code is typically defined as IP x1 x2 and subdivided into
protection provided against intrusion (body parts such as hands and fingers), pro-
tecting against ingress of foreign bodies, and protection against ingress of liquids [5].
3.4 System Protection 43

Table 3.3 Examples of IP codes

Application Operating conditions Typical locations Protection
type
Low-level Dry building interiors with Offices, apartments, and IP 10, IP
protection no condensation business premises, showrooms 20
Average Building interiors where Kitchens, deep freeze rooms, IP 30, IP
protection condensation can occur or cellars, closed stables, 40, IP 41,
devices in farm vehicles automobiles, closed trucks IP 22
Medium Outdoor rooms, temporary All weather shelters, tents, IP 22C, IP
protection outdoor operation roofed surfaces, open-cast 34, IP 43,
mining IP 44
Strong Continuous operation Locations where the harmful IP 54, IP
protection outdoors effects of ambient weather 56, IP 65,
conditions are permanent IP 66
Total Temporary or permanent IP 67, IP
protection flooding with water 68

The protection details specified with at least two digits x1 and x2 for the IP
protection types are shown in Table 3.2. The first digit indicates on a scale of 0–6,
the level of protection that the enclosure provides against access to hazardous parts
(e.g., electrical conductors, moving parts). It comprises the protection against
intrusion of body parts such as fingers and hands (shock protection) and the ingress
of solid foreign bodies such as dust. The second digit indicates on a scale of 0–8,
the level of protection that the enclosure provides against harmful ingress of water.
Table 3.3 lists examples of these classifications.
The capital letter “X” is used instead of a digit when no particular protection is
specified (note that it should not be confused with “no protection”). IP protection
type of at least IP 3X is mandatory for a device with live parts over 50 V AC or
120 V DC in most countries.
Two further positions, in addition to the double-digit, numerical IP protection
types, are available for extra information to form a four-position IP x1x2x3x4. The
third position can contain the letters A, B, C, or D to define extra protection against
contact with dangerous parts with the back of the hand (A), the finger (B), a tool
(C) or a wire (D). An additional letter at the fourth position provides further
information for high voltage devices (H), whether the moving parts were in motion
(M) or at a standstill (S) during the water test or whether the test was carried out
under predefined weather conditions (W).

References

1. W. Krause, Gerätekonstruktion in Feinwerktechnik und Elektronik, Hanser Verlag, 2000

2. G. R. Mezger, “The Relay Rack in Amateur Construction”, pp. 27–30, QST, vol. 18 (1934),
American Radio Relay League, Hartford, CT, 1934
44 3 System Architecture and Protection Requirements

3. R. R. Tummala, Fundamentals of Microsystems Packaging, McGraw-Hill, 2001

4. IEC 61140:2016, Protection against electric shock - Common aspects for installation and
equipment, Publication date 2016-01-07
5. IEC 60529:1989+AMD1:1999+AMD2:2013 CSV, Degrees of protection provided by
enclosures (IP Code), Publication date 2013-08-29
Chapter 4
Reliability Analysis

Inexperienced engineers typically neglect reliability issues when designing.

Reliability parameters are sometimes not known, and as a result the development
engineer often maximizes them, “to be on the safe side.” However, the resulting
excessive costs often require a redesign. On the other hand, when reliability data for a
system are provided, they raise questions on the required reliability of the system’s
individual components.
This chapter explains the mathematics needed to perform reliability analysis and
introduces the primary reliability parameters, which a development engineer must
be familiar with today (Sects. 4.1 and 4.2). The so-called bathtub curve of failure
rates is applied for the reliability of electronic systems; understanding the middle of
this curve, which represents a constant failure rate, is critical in practice. The
reliability parameters for electronic systems are easily calculated by applying this
constant failure rate, which is associated with an “exponential failure distribution”
(Sect. 4.3). The failure modes of electronic components are described in Sect. 4.4.
We show how the required reliability parameters for individual components and
modules can be determined by applying the exponential failure distribution to these
failure modes (Sects. 4.5 and 4.6). In addition, we show how the system reliability
can be calculated from the reliability of individual components.
Finally, Sect. 4.7 contains recommendations for upgrading the reliability of
electronic systems.

4.1 Introduction

Function and reliability are the two most important factors impacting system
quality. An electronic system should fulfill its required functions based on given
parameters (output/response values) within defined boundaries. Reliability is a
measure of the performance of these functions over a given period. The parameter

© Springer International Publishing AG 2017 45

J. Lienig and H. Bruemmer, Fundamentals of Electronic Systems Design,
DOI 10.1007/978-3-319-55840-0_4
46 4 Reliability Analysis

boundaries are determined by the predefined operating modes and conditions of

usage, along with maintenance, storage, and transportation.
High reliability is especially important for electronic systems in industrial
equipment, where a device failure often results in production loss or rejects. The
associated costs in such cases may be higher than the initial outlay for the defective
system.
We will show later how the product price increases as the reliability increases.
The price increase associated with increased reliability is, however, offset by a
reduction in extra costs for the customer for maintenance and repair during the
product lifetime. Thus, customer costs can be optimized by examining the rela-
tionship between the overall costs and system reliability (Fig. 4.1).
If there is a loss of reliability, maintenance costs may exceed customer expectations
or the proposed manufacturer guarantee and warranty costs. In addition, the business’s
reputation may also suffer and it may lose customers if the reliability of its products is
lower than that of its competitors’ products. On the other hand, if a product’s reliability
exceeds market expectations, without offering additional technical benefits, it can
become so expensive that it is not profitable to manufacture.
Against this backdrop of cost efficiency, a product need not be overly reliable.
Rather, the development engineer should aim to minimize overall costs by seeking
reliability that fits the purpose. There are exceptions to this rule, however.
Maximum reliability is required in aerospace engineering, for example, as main-
tenance and repair are extremely difficult, if not impossible. The same applies to
healthcare systems: health and safety risks and environmental concerns prohibit
cost cutting.

Costs

Overall costs for the

customer

Purchase price

Minimum
overall costs

Purchase
price Costs during the lifetime (repair,
maintenance, breakdown costs)

System reliability

Fig. 4.1 Achieving cost efficiency by examining the relationship between the overall costs and
system reliability. The increased reliability associated with higher purchase prices is offset by a
reduction in repair and maintenance costs, resulting in an overall cost optimum at specific
(to-be-aimed-for) reliability values
4.1 Introduction 47

Reliability data are always future oriented. The proper functioning of a system
can only be predicted with a specific probability, as the reliability parameters are
stochastic (random). Nevertheless, every development engineer needs to define the
target reliability level for the system at hand.
The functionality, accuracy, processing power, etc. of electronic systems are
constantly improving. At the same time, due to these increased levels of com-
plexity, there is also an increased risk of systems becoming prone to failure. These
factors cause a conflict of interests. A culture of reliability is needed to accompany
systems throughout their entire life cycles. Reliability must be designed “into the
systems,” starting with product planning, and on through component selection and
the system design itself, to fabrication and quality control. Since reliability should
be “designed in,” it should be considered a strategic task. (In contrast, maintenance,
keeping components and systems functioning, is considered a tactical task.)
The engineer remains responsible for reliability when the product moves from
engineering into production. The developed system is also tested “in the field,” as
the product is still under warranty and the manufacturer guarantees the quality of its
product for the customer. Failures, which are not random failures, must be carefully
assessed for a period of several years. The development engineer remains
responsible for the reliability parameters and calculations even years after the
design and development is complete.

4.2 Calculation Principles

4.2.1 Probability Terminology

Probability plays a crucial role in reliability theory. We will introduce probability

here with the game of dice, using a single cubic die whose six faces represent the
numbers 1–6.
Events can be certain, impossible or random. An event E is certain if it always
occurs under given conditions. It is an impossible event if it can never arise. A
random event can occur or not occur.
Let us say the random event E “4 on top” occurs 15 times for a 100 rolls of a die.
The relative frequency H(E) of the events E in the series of rolls of the die can be
expressed as follows:
m
HðEÞ ¼ ; ð4:1Þ
n

where the parameter m is the number of occurrences of E for n tries. This yields the
fraction 15/100 = 0.15 in the above example.
A regular pattern emerges when the relative frequency of an event E is calculated
for a large number of tries. The relative frequencies for the numbers 1–6 on a die
48 4 Reliability Analysis

Fig. 4.2 Relative frequency 6 0 ro lls 1 2 0 0 r o lls

H(E) of individual numbers H (E) H (E)
1–6 for different numbers of
die rolls
0,2 0,2

0,1 0,1

1 2 3 4 5 6 x 1 2 3 4 5 6 x

approach a fixed value, namely 1/6 for an “ideal die.” Deviations from this value
decrease as the number of throws increases (Fig. 4.2).
This value is called the probability of event E, i.e., the probability of rolling a
particular die number. In general, the probability of an event is the relationship of
the given (favorable) results to the total set of possible results. Its value range lies
between 0 (event never occurs) and 1 (event always occurs), where percentage
values between 0 and 100% are often used as well.
Probability theory applies when the same object is repeatedly observed under the
same test conditions. For a sufficiently large number of tests n, where the event
E occurred m times, the relative frequency m/n can be used to estimate the prob-
ability P(E).
Not only can probabilities be determined experimentally (subsequently), they can
be theoretically predicted as well (in advance). The probability of occurrence E of an
event is a predetermined theoretical value. Actually meeting the probability of
occurrence E is a function of the number of tries; the higher the number of tries, the
more likely the observed, relative occurrence will fit the predicted one (see Fig. 4.2).
There is a difference between the probability of a single event and the total
probability, the latter of which may increase or decrease over multiple events,
depending on the nature of the event. For example, the probability of occurrence
that the number 4 turns up when the die is rolled a single time is 1/6, 0.1667 or
16.67%.
Obviously, the probability of rolling a given number increases as the number of
tests increases (such as by throwing a number of dice simultaneously, or throwing a
single die a number of times in succession). This total probability is determined
from the product of many single probabilities; for example, the product
1/6  1/6 = 1/36 represents the probability that the number 4 is thrown twice.
However, the scenarios of interest here, i.e., rolling the number 4 (at least) once
cannot be determined with this approach. The focus instead is on the comple-
mentary event (not rolling number 4) and its probability. This is 5/6 for one try, and
5/6  5/6 = 25/36 for two tries. Since this is the probability of not rolling a 4, we
must subtract this value of 25/36 from 1 to arrive at 11/36 as the probability of
throwing the number 4 (at least) once in two tries.
4.2 Calculation Principles 49

The same procedure is followed for n tries by multiplying the probabilities of the
complementary event n times and subtracting the result from 1. Later, we will see
how this technique is applied to determining the failure probability of systems,
which is based on the individual failure probabilities of their functional compo-
nents. The single probabilities of the complementary event (component does not
fail) are multiplied together here as well to calculate the probability of survival of
the system. The failure probability of the system is obtained by subtracting this
survival probability from 1 (Sect. 4.6.3).

4.2.2 Reliability Terminology

Reliability is defined as the property with which a product performs

– a required function,
– under defined functional and environmental conditions,
– during a given service period.
Reliability is therefore a probability between limit values 0 and 1, in which the
operating period plays a fundamental role. Please note that every system or device
will fail during a sufficiently long operating period, and thus the reliability
approaches 0. Reliability data are meaningless if they are not based on a given
operating period. Furthermore, the system must be operational at the beginning of
the reliability analysis.
The serviceability of components and systems depends greatly on their operating
environment; on compliance with preset maximum stress levels and loading; and on
environmental conditions, such as temperature, humidity, and vibrations. Thus,
functional and environmental conditions for the product typically need to be specified
as well as reliability data. The development engineer selects and specifies these
conditions.
A module or system is said to have failed if its intended purpose is not met, i.e.,
at least one parameter (output value) exceeds the minimum or maximum limit
value. In the case of failure, the system function must be reinstated by an unplanned
external action, such as a repair. When an external action is planned, for example,
to replace consumables, it is called maintenance. Maintenance, in contrast to repair,
is a preventative measure, typically to counteract wear and tear.

4.2.3 Reliability Parameters

The reliability of components and systems is defined as the probability of proper

operation under the required operating conditions and for a defined period of time.
It is expressed by parameters that describe their response over time with respect to
50 4 Reliability Analysis

failures, and their prevention and repair. These parameters are mean values of a
totality, probability data, or probability-related prognoses (probability of occur-
rence). Reliability is typically reduced to a quantitative reliability metric, such as
failure rate, which is introduced below.
The key parameters will be illustrated using the life expectancy graphs for
humans shown in Fig. 4.3. These graphs show various functions that approximate
the relationship between a reliability parameter and time.
The reliability function (also: probability of survival or survival function)
R(t) captures the probability that a system will survive up to a specified time. It is
generally defined as follows:

nðtÞ
RðtÞ ¼ ; ð4:2Þ
n0

where n(t) represents the failure-free units to time t, and the initial stock n0, which
represents the totality of working units at the starting time t0.
Only 50% of the initial stock of the human group shown in Fig. 4.3 are alive
after 76 years. In other words, a given human being has a 50% chance of living to
be 76 years old. Only the probability of survival, which drops over time, can be
determined. We cannot predict when a given person will die.
The arithmetic mean value of the reliability function R(t) is calculated from the
areas above and below the curve R(t) (Fig. 4.3, top). This mean value m for
repairable units is called the mean time between failures (MTBF), and the mean time
to failure (MTTF) for non-repairable units is:

Z1
m¼ RðtÞ  dt: ð4:3Þ
0

The MTBF (MTTF) value can be used as a system reliability parameter or to

compare different systems or designs. This value, as we will show later, should only
be understood conditionally as the “mean lifetime” (an average value), and not as a
quantitative identity between working and failed units. The mean time to failure is
m = 73 years for the given human group shown in Fig. 4.3, with approximately
55% of the initial stock still alive.
The failure distribution function (also: failure probability or unreliability func-
tion) F(t) is the probability that an element will fail before time t. It is thus the
complementary quantity of the reliability function R(t) and is expressed as follows:

FðtÞ ¼ 1  RðtÞ: ð4:4Þ

Due to this relationship, it is sufficient to know one of the two functions as a

function of time. For example, one can observe the fraction of a population of
components that fail at time t in order to estimate the value of the failure distribution
function at this time.
4.2 Calculation Principles 51

R(t)
1,0

Reliability function
(probability of survival)
0,5
( )
=
o

0
0 20 40 60 76 80 100 Years
f (t) “Mean time to failure”
m = 73 years
Failure density function
(probability density function)
d
=−
d

0 20 40 60 80 100 Years
λ (t)

Failure rate
( ) 1 d
= =− .
( ) ( ) d

0 20 40 60 80 100 Years

Fig. 4.3 Reliability-related functions for a human group to illustrate the terms reliability function,
failure density function, and failure rate

The failure density function (also: probability density function, PDF) f(t) is the
mathematical derivative of the failure probability and thus defines how the failure
distribution function F(t) changes with time:

dFðtÞ dRðtÞ
f ðtÞ ¼ ¼ : ð4:5Þ
dt dt

The failure rate kðtÞ is the probability that a module that has not failed up to
time t will fail up to time t + dt (i.e., in the small period dt):
52 4 Reliability Analysis

Fig. 4.4 Typical plot of the λ Early f ailures Random failures W earout f ailures
failure rate kðtÞ over
time t (bathtub curve) with
decreasing, constant, and
increasing failure rate sections

f ðtÞ 1 dRðtÞ
kðtÞ ¼ ¼  : ð4:6Þ
RðtÞ RðtÞ dt

The failure rate thus defines how many units will fail on average in a time unit.
This critical reliability parameter is defined in failures per time unit, that is, the
reciprocal of time, e.g., h−1 (failures/hour). The failure rate cannot be measured for
an individual unit, and it is estimated from observations of the failure mode of a
larger number of similar units:

Dna
kðtÞ  ; ð4:7Þ
nðtÞ  Dt

where Dna is the number of failures in the given interval Dt, n(t) the number of all
units functioning at the beginning of the analysis, i.e., at time t, and Dt is the
observed time interval.1
We will illustrate this estimate with two examples. If an average of five com-
ponents from a set of 100 working components fails in 1000 h, the failure rate for a
component is 5  10−5 failures/hour. Should a stamping device temporarily fail 100
times in 1000 h uptime, the failure rate is 0.1 failures/hour (0.1 h−1).
A plot of the failure rate over time is given in Fig. 4.4. This curve is known as
the bathtub curve. This typical characteristic curve can be broken down into three
sections early failures, random failures, and late or wearout failures.
Early failures, also known as infant mortality fails or early life failure rates
(ELFR), occur during the early life of a product due to manufacturing defects that
escape detection. They are caused by inadequate quality management during fab-
rication and inadequate product testing. Typically, the failure rate drops during this
period. The remaining products, presumably without manufacturing defects, should
remain functional for their design lifetime.
Random failures occur during this expected product lifetime. They are unpre-
dictable and unforeseeable and are due to the statistical superimposition of a

1
Calculating the failure rate for ever smaller intervals of time, i.e., the instantaneous failure rate as
Dt tends to zero, results in the hazard function (also called hazard rate), h(t). As it is a function that
describes the conditional probability of failure, it is always a value between 0 and 1. (Failure rate,
as the count of failures per unit time, can be a value greater than one.)
4.2 Calculation Principles 53

number of independent factors. The failure rate is constant during this period of
intrinsic fails, also known as the intrinsic failure period or the stable failure period.
Wearout failures, also known as late failures, occur at the end of the service life
through wear and tear, fatigue, aging, etc. This period is characterized by an
increase in the failure rate.

4.3 Exponential Distribution

4.3.1 Reliability Distributions

Reliability distributions of components and systems need to be modeled with

suitable mathematical functions for them to be mathematically treated in practice.
Standard statistical distributions are matched with empirically determined distri-
butions of reliability parameters. The exponential distribution, the Gaussian normal
distribution, or the Weibull distribution are such functions (Fig. 4.5).

Reliability function Failure density Failure rate

function
R (t) f (t) λ (t)
1
Exponential
distribution

0
t t t
R (t) f (t) λ (t)
1
Gaussian
normal
distribution
0
t t t

R (t) f (t) λ (t)

β>1
β<1
β=1 β>1
β=1 Weibull
β>1 β<1 distribution
β<1 β=1

t t t

Fig. 4.5 Different distributions of reliability parameters over time. The decline in numbers due to
random failures (i.e., constant failure rate) can be expressed using the exponential distribution. The
Gaussian normal distribution is suitable to describe wearout failures (with electric motors, relays
etc., and often with mechanical elements). Early and wearout failures can be modeled by the
Weibull distribution with the shape parameter b
54 4 Reliability Analysis

Complex reliability distributions can be approximately described as the sum-

mation of Weibull distributions that can be suitably adapted with their shape
parameters to predefined characteristic curves (also: shape factor, Weibull slope).
The Weibull distribution can be used to describe decreasing, constant, and
increasing failure rates in technical systems. The exponential distribution with its
constant failure rate described below is a special case. The “bathtub curve” (see
Fig. 4.4) can be approximated by a summation of three Weibull functions. Due to
its versatility, the Weibull distribution is one of the most widely used lifetime
distributions in reliability engineering.
The exponential distribution is frequently used to model electronic components
that usually do not wear out until long after the expected life of the system in which
they are installed. It describes the decline in numbers caused exclusively by random
failures occurring during the useful life of tested, nonaging electronic components.
It covers the middle of the bathtub curve (Fig. 4.6). So-called memorylessness
plays a key role here. The probability that a component that has been used for a
number of days will last another x days is the same as that of a new component
lasting x days. The exponential distribution is therefore not applicable to humans,
and other living things, as the probability that a newly born child will live for
50 years is not the same as the probability that a 50-year old will live to be a
hundred.
Of all reliability distributions, the exponential distribution is the most commonly
used in electronic systems design, since such systems typically do not experience
wearout type failures. It is also sufficiently accurate for reliability calculations of
electronic components and systems. It is thus used exclusively throughout this
book.

λ
Early Wearout R(t)
failures Random failures failures 1 R(t ) = e − λt
(constant failure rate)
t

Fig. 4.6 Exponential distribution with its constant, low failure rate is restricted to the middle of
bathtub curve; hence, it does not include early and wearout failures. The probability of survival R(t) is
indicated in this period by an exponential function, the exponential reduction in the number of
operational units over time
4.3 Exponential Distribution 55

4.3.2 Reliability Parameters and the Exponential

Distribution

As noted earlier, the decline in population size can be described with an exponential
function using a constant failure rate k, i.e., purely by random failures. The relia-
bility function R(t) can be expressed as follows:

nðtÞ
RðtÞ ¼ ¼ ekt ð4:8Þ
n0

for the special case k(t) = constant based on Eq. (4.6).

As introduced in Eq. (4.2), the number of failure-free units at time t is n(t) and n0
is the initial stock units. The failure distribution function F(t) can thus be expressed
as follows:

FðtÞ ¼ 1  ekt : ð4:9Þ

The functions R(t) and F(t) are plotted in Fig. 4.7. The exponential function as
per Eq. (4.8) can be described with the help of the parameter m. This value, as with
the time constant of RC circuits, can be determined graphically via the initial
tangent of the e function.
The other parameters are expressed as follows:

failure (probability) density function f ðtÞ ¼ k  ekt ; ð4:10Þ

+ =1
1
R(t)
F(t) Failure distribution function (failure probability)

=1 =1 e =1 e
0,63

0,37 Reliability function (survival probability)

=e =e

0
Service period t
1
= =

Fig. 4.7 Failure and reliability functions with the exponential distribution, i.e., during a period of
constant failure rate. Also shown is the proportion of failed and operating units after a service
period corresponding to the MTBF or MTTF
56 4 Reliability Analysis

f ðtÞ
failure rate kðtÞ ¼ ¼ k ¼ constant; ð4:11Þ
RðtÞ

Z1
1
mean time between failures ðMTBF or MTTFÞ m¼ ekt  dt ¼ : ð4:12Þ
k
0

The mean time between failures (MTBF) and the mean time to failure (MTTF)
are the mean value of the exponential failure distribution and, hence, are the
reciprocal of the failure rate k, according to Eq. (4.12). The reciprocal is defined
mathematically as the area under the reliability function R(t) curve. The units used
are typically hours or life cycles. This critical relationship between time between
failures (MTBF, MTTF) and failure rate allows a simple conversion when one of the
two quantities is known and an exponential distribution (constant failure rate) can
be assumed.
According to Eq. (4.8), only e−1  0.37, i.e., approximately 37% of the test
units available at the beginning of the test (initial stock) are properly functioning
after t = MTBF = 1/k hours have elapsed. In other words, the probability of an
individual unit in a group surviving, during a given service period of MTBF hours,
is only 37%. The probability of its failure up to this time is 63%. It is important to
remember these relationships when using MTBF or MTTF for reliability
predictions.2

4.4 Failure of Electronic Components

We have covered the typical relationship of the failure rate with time in Sect. 4.2.3
(“bathtub curve” in Fig. 4.4). Failure rates for electronic components drop to a few
percent of their original values after a “burn-in period” of 300–500 h (2–3 weeks
continuous operation) according to different sources. The end of the early failures
should coincide with the product leaving the manufacturer’s test area.
The exponential distribution with its simple mathematical formulas, introduced
above, applies only to random failures, that is, to the linear part of the “bathtub
curve.” The phrase “random failures” is not very accurate, as every failure is caused
by something. The notion of randomness should be viewed statistically and is based
on the assumption that the time of failure for a given component cannot be
predicted.

2
Since MTTF can be expressed as “average life (expectancy)”, many engineers assume that 50% of
items will have failed by time t = MTTF. This inaccuracy can lead to bad design decisions.
Furthermore, the above statements imply the total absence of systematic failures (i.e., a constant
failure rate with only intrinsic, random failures), which is not easy to verify.
4.4 Failure of Electronic Components 57

The failure rate for every component, and thus every system, becomes
time-dependent sooner or later. The reliability then depends on the accumulated
service period and cannot be described with the exponential function. Internal inter-
connects in electronic components often suffer fatigue due to reverse thermal stress
and become increasingly prone to failure. In addition, the surrounding atmosphere or
impurities may enter through defects in enclosures to alter the state of a component.

4.4.1 Drift

The definition of reliability includes requirements on the behavior of properties

during a given period. When is a component said to have failed, for instance? While
the requirements for digital components are fairly straightforward, analog compo-
nents have drift issues. Drift can be defined as the gradual change in attributes over
time that cause failure for a given loading. Drift is caused by chemical and physical
processes inside a material or on its surface. The totality of these processes and their
impact is called aging (Sect. 4.6.5; Fig. 4.12).
Drift failures can be differentiated between monotonic and non-monotonic drift.
Monotonic drift is characterized by a parameter (output value) continuously varying
in the same direction, crossing a predefined minimum or maximum value at some
point. Non-monotonic drift is characterized by both positive and negative variance
of a parameter.
Drift does not necessarily result in the failure of a functional unit, such as an
interruption or short circuit. In the case of non-monotonic drift, it may be that the
parameter quickly drifts back into its “acceptable region.” Hence, the consequence
of drift should instead be defined in terms of the resulting accumulated degradation.
Such information, unfortunately, is often not sufficiently detailed in component data
sheets. Many engineers do not appreciate the significance of these issues.

4.4.2 Reference and Operating Conditions

Functional and environmental conditions can also significantly impact component

failure. Therefore, failure rates without reference to functional and environmental
conditions have little or no value. Operating conditions arise from functional loads,
such as current, voltage, and power dissipation; and environmental conditions
include all component stresses originating in the environment. These include
ambient temperature, pressure, humidity, radiation, and mechanical stresses, such as
vibration and shock.
Failure rates quoted by component manufacturers are based on reference con-
ditions, if not otherwise specified, using the concept of base failure rates. Examples
of climatic and mechanical reference stresses relevant for these base failure rates are
listed in Table 4.1.
58 4 Reliability Analysis

Table 4.1 Climatic and Type of stress Reference stress

mechanical reference
conditions for electronic Ambient temperature 40 °C (104 °F)
components [1] Relative humidity 30%
Air pressure for electronic 1.013  105 Pa
components negligible in the range
(0.860–1.060)  105 Pa
Mechanical stress Vibration stress Frequency: (10–55) Hz
Acceleration: 20 m/s2
Shock stress Acceleration: 150 m/s2
Duration: 11 ms
Other stresses: wind, rain, snow, ice, None
dripping, spraying, splashing water
or water jets, dust, the effects of
pests, corrosive gases, radioactive
radiation, temperature change, etc.

Influence factors (also: reduction, loading, or stress factors) are used to deter-
mine the failure rate under given functional and environmental conditions. They are
based upon the intended operating environment of the component or system. These
factors are defined as follows:

kB ¼ kref  pV  pI  pT  pE ð4:13Þ

kB failure rate under operating conditions (operating failure rate)

kref failure rate under reference conditions (base failure rate)
pV voltage factor for voltage influence
pI current factor for current influence
pT temperature factor for temperature dependence
pE environmental factor for environmental influences (factors other than
temperature, such as humidity and vibration.).
There are other factors as well that are used as multipliers for the base failure rate.
Some of these factors will result in a linear degradation of the base failure rate, while
others, especially temperature-related factors, result in an exponential degradation.

4.4.3 Failure Rates of Electronic Components

The failure rate k of electronic components can be approximated, using a method

similar to that used in Eq. (4.7), as follows:

number of failures
k : ð4:14Þ
number of test units  period
4.4 Failure of Electronic Components 59

Influence factors pn for determining the failure rate under operating conditions
ðkB Þ should be used when the failure rate k was calculated under reference con-
ditions ðkref Þ (Sect. 4.4.2).
The failure rate of electronic components is often defined by Failure in time
(FIT). The FIT metric is the number of failures that occur in 109 h, which is
approximately 114,000 years. The need for the unit “10−9 h−1” illustrates the high
reliability of today’s electronic components, especially in microelectronics.
Table 4.2 shows reference values of failure rates for electronic components
under reference conditions (base failure rates). These values are examples only, and
should not be used in reliability calculations.

Table 4.2 Failure rates for electronic components under reference conditions [2]
Element kmin in FIT = 10−9 h−1 kmax in FIT = 10−9 h−1
Transistors
Thyristor, Triac 2.2
Transistor, bipolar 0.74
Transistor, FET 4.5 12
Diodes
Signal 1 3.8
Z 2
Power 5
IC
Digital, bipolar 2.5 80
Digital, MOS 10 290
Digital, CMOS 160 240
Resistors
Carbon film 0.07 4.8
Wire 3.3 33
Thermistor 21 105
Potentiometer 8.9 650
Capacitors
Electrolyte 9.5 2000
Film 0.53 490
Ceramic 0.67 23
Tantalum 2.1 240
Piezoelectric resonators 11 38
Interconnects
Vias 0.041 0.26
Solder joint, automatic 0.069
Solder joint, manual 0.14 2.6
Plug connection 0.12
Crimped connectors 0.26
60 4 Reliability Analysis

Derating curves3 are available for a variety of components, which depict the
relationship between the base failure rate and the stress. Figure 4.8 shows typical
curves for carbon composition resistors and dry tantalum capacitors. The rise in the
failure rate as a function of temperature and electrical stress (power, voltage) is
universally applicable to all electronic components. Influence factors (p) can be
derived from these relationships.
The MIL-HDBK 217 [2] handbook is widely used to determine failure rates in
the defense industry, aeronautics, and shipbuilding. The latest technological
advances are not covered in the handbook as it has not been revised and updated
since last issued in 1991 (revision F).
The Siemens standard SN 29500 [5] is a very popular resource for failure rates
and is regularly revised and updated. The standard allows FIT values to be cal-
culated based on known stress data for the most commonly used electronic and
electromechanical components. This industrial standard is widely used for making
reliability prognoses although it is not officially recognized globally. The failure
rates acquired with the standard are conservative, and the resulting reliability errs on
the safe side.
Exemplary failure rates are also cited in the application standard ISO 13849-1 [6].

4.4.4 Derating

According to the curves in Fig. 4.8, if the loading or the temperature is reduced by
50%, the failure rate is reduced by one order of magnitude. This technique of
operating an electronic device at less than its rated maximum capability is called
derating. It is one of the key techniques for increasing reliability. The price of
components rises, however, due to this type of overengineering.
As mentioned earlier, the exponential degradation caused by temperature has a
significant impact on failure rates. If, for example, the operating temperature of
integrated circuits is increased by 10 K, the average time to failure is approximately
halved. Thus, the reliability of electronic systems is closely tied to their thermal
management, especially cooling (Chap. 5).

4.4.5 Accuracy of Failure Rates

Failure rates for components are specified by manufacturers, users, and authorities.
On the face of it, these specifications appear very convincing and are typically
published with very accurate supporting data. However, in most cases, there is no

3
Derating is the operation of an electronic device at less than its rated maximum capability in order
to prolong its life.
4.4 Failure of Electronic Components 61

Load ratio
Base failure rate

Base failure rate

Ambient temperature Ambient temperature

Fig. 4.8 Failure rate characteristics for carbon composition resistors (left [3]) and dry tantalum
capacitors (on the right [4])

mention of functional and environmental stresses that components are subjected to

during the observation period. For example, the simple statement “The failure rate
of a film resistor is 33  10−9 failures/hour” is unsatisfactory. The following data at
a minimum should be provided as well:
– operational and test conditions: these include functional stresses, such as electrical
and magnetic stress; and environmental stresses, such as ambient temperature,
humidity, mechanical loading (such as vibrations), and the effects of radiation,
– limit values for failure criteria, including drift failure criteria,
– observation period and stress cycles, if necessary,
– confidence range for failure rate (i.e., the range that contains the true value with
a given probability), calculated from the number of failures.
As these test conditions and requirements are typically not published, the lit-
erature often contains failure rates that differ by many orders of magnitude.
However, comparative reliability and weak-point assessments can still be carried
out with specifications from a single source. The same applies to concept tests.
Durability data for switches and relays cannot be specified directly, as they
depend on the type of contact loading as well as environmental conditions (tem-
perature, humidity, air impurities, shock, and vibration loading).
The typical service life spans of switches and relays in Table 4.3 are essentially
“approved mechanical cycles.” If, for example, the typical time to failure for a relay

Table 4.3 Typical life spans Component Number of cycles  106

of switches and relays
Min. Typical Max.
Pushbutton switch 0.01 0.1 10
Relay, heavy-duty 1 2 10
Relay, light-duty 1 10 100
Reed relay, DIL enclosure 5 10 1000
Reed contact, dry 0.5 50 5000
62 4 Reliability Analysis

is 10  106 cycles, the equivalent failure rate is k ¼ 0:1  106 failures/cycle. This
value should be multiplied with the cycles/time unit, e.g., 1000 cycles/h. The
failure rate for the selected numbers k ¼ 103 cycles/h  0.1  106 failures/
cycle = 10−4 failures/h.
The failure rates of electronic components are essentially based on compre-
hensive statistical data, and nothing more. It is by no means a recommendation to
engineers and other electronic designers to use this failure rate data without due
consideration and care. More importantly, the set of curves for the component at
hand, along with the parameters for temperature and loading and the relevant
influence factors (p), will need to be carefully examined.

4.5 Failure of Electronic Systems

4.5.1 Calculation Principles

Before investigating the reliability of electronic systems, we first illustrate in this

section the relationship between the reliability data for the components forming the
system and the system itself. To do this, we generalize the analysis of the system
and view its components and modules as system elements. The relationships
introduced below will then be applied to actual systems in Sect. 4.6.
Information on the failure modes for system elements is required to predict
system failure modes. The failure mode for system elements is typically calculated
from the failure modes quoted in data sheets under reference conditions and con-
sidering the actual stress and environmental conditions (Sect. 4.4.2). The following
condition must be met to establish the system failure mode from the element failure
modes: The functioning or failure of an element is independent of other elements,
i.e., there is no mutual interaction of the reliability values.
This criterion is met in many electronic systems. Hence, reliability calculations
for electronic systems are much more useful than for mechanical systems, where
failure rates for individual mechanical components cannot be accurately provided
due to mutual, failure-related interactions between components.
Assuming the above condition holds, system reliability (e.g., of a printed circuit
board) can be calculated from the failure modes of system elements (e.g., electronic
components). The converse is also true, where failure modes for elements forming
the system can be inferred from the system reliability. Both these approaches are
based on the serial or parallel structure of the reliability network for the system
introduced below in Sect. 4.5.2. It is very important that the relationship between
the system and its reliability network model be understood before introducing the
analytical techniques that are used to calculate the reliability of these systems in
Sects. 4.6.3 and 4.6.4.
4.5 Failure of Electronic Systems 63

4.5.2 Network Modeling—Serial and Parallel Systems

A structure is said to be serial in the context of reliability if the entire system fails
as a consequence of a failure of at least one of its constituent elements. For
example, the electronic circuit on a printed circuit board typically fails when a
component fails. The system failure rate is always greater than an individual ele-
ment failure rate, and the probability of system survival is always less than that of
an individual element. This illustrates the disadvantages of serial systems, in which
high individual element reliabilities are required to achieve high system reliability.
A parallel structure, on the other hand, comprises a basic element and at least
one standby element. Only one of the components in a parallel system needs to be
working for the system to be operational. All components, that is, the basic element
and all standby elements, must fail for the system to fail. Multi-engine aircraft, for
example, can land safely with only one engine running. Redundancy4 is defined as
the availability of more technical functional elements than are required for the
intended function. Standby elements constitute structural redundancy. The redun-
dancy level for r elements is r′ = r − 1. Therefore, a double-engine aircraft has a
redundancy level of 1.
When all elements of a parallel configuration are active (switched on) and
always connected to a working system this is called hot-spare or hot-standby
redundancy. In the case of cold redundancy, the secondary or back-up element is
activated (switched on) only when the primary element fails.
Redundancy greatly increases system reliability, as the probability of system
survival in parallel configurations is higher than the survival rate of its individual
components. However, this applies only up to the mean time to failure (MTTF) of
individual redundant elements; the entire system can only be configured as reliable
by means of redundancy up to the MTTF of its constituent elements (Sect. 4.6.4;
Fig. 4.11).
Please note that the reliability network as a serial or parallel structure should not
be mistaken for the real circuit layout. If, for instance, one of two “series” con-
nected blocking capacitors fails due to a short circuit, the system can still work
properly. This is technically a serial system but acts reliability wise as a redundant
parallel system.
Generally speaking, the reliability network model depends not only on the
functional configuration, but also on the type of failure. If the capacitor in the
example above did not fail by short circuit, but by an open-circuit, such as a broken
wire, the system would fail since the other blocking capacitor would become dis-
connected; this would then be a serial system in terms of reliability.

4
The word redundancy comes from the Latin word redundare, which means available in
abundance.
64 4 Reliability Analysis

4.6 Reliability Analysis of Electronic Systems

4.6.1 Preliminaries

The systems treated below are assumed to be free of design, assembly, and man-
ufacturing failures and do not show any effects of wear and tear. This applies to
both hardware and software. Failures occurring after the system has been put in
operation are exclusively random, and, hence, the probability theories based on the
exponential distribution covered in Sect. 4.3.2 can be applied.
We should point out, however, that the reliability of a system should not be used
for warranty purposes. This is due to inaccurate failure rates rather than reliability
theory. Depending on the source of the failure rates, “favorable” or “unfavorable”
numerical values can be chosen, resulting in widely differing reliability parameters.
It is not uncommon to see failure rates that differ by orders of magnitude between
various sources.
Reliability analyses are still useful, as they provide the development engineer
with useful information for selecting and designing components, and for identifying
weak points. Different system designs can be compared with respect to reliability.
When doing so, the failure rates need to be taken from the same source and
uniformly applied. Failure rates from different sources, or failure rates that are
applied without specifying the functional and environmental stresses they were
subjected to when determined, are useless.
Sales people should refer to these issues when, for example, a customer points to
a better MTBF value from a rival bidder. Due to the widespread misunderstanding
of MTBF as “average” or “useful life,” engineers and sales should not use those
values when talking to customers, nor should they promise failure-free life based on
those values. A customer should stipulate the failure rates to be used when com-
paring different quotes.
The types of reliabilities found in industrial practice are nominal, test, design,
and operational reliabilities. As reliability should be ideally “designed in,” the
following discussion is based on design for reliability. This term is typically (and
here as well) defined as “a reliability value that is calculated mathematically and is
based on the design and the parts used, excluding manufacturing failures.”
Design reliability should be calculated early in the design process, as it can
provide valuable indicators of weak points and thus impact design decisions, such
as the choice of components. These reliability calculations should be done con-
currently with the development work, so that the development engineer has
up-to-date information on the expected reliability of the system.
There is no real “lifetime” metric for electronic systems as every failure can
technically be cleared. A system can be in service indefinitely depending on the
strategy adopted by the organization. In practice, the end of the useful life of a
system is reached when troubleshooting or operating the system becomes too
expensive.
4.6 Reliability Analysis of Electronic Systems 65

The term minimum lifetime should not be used for electronic systems.
A minimum lifetime (sometimes referred to as minimum service life or incubation
period) is the period in which a product never fails. This postulates that the
probability of a failure is exactly (and not only approximately) zero. Such a period
exists for certain items, like solder joints. Here, a series of time-consuming pro-
cesses must take place before solder joints fail. However, it is impossible in practice
to quote a minimum lifetime for an entire system as all individual components
including their interactions would be required to possess this property.
The term ROCOF (rate of occurrence of failures) is often used for repairable
systems. Adding the term availability to the parameters yields a useful practical
reliability metric, as we show next.

4.6.2 Availability of Repairable Systems

We have already mentioned that the lifetime of systems can be extended infinitely
by repair. The relationship between service period and out-of-service period
(downtime) is of interest here. If the system is not working, it may have failed or be
shutdown. Typically, the out-of-service period is set to the mean time between
failure and repair, whereby the mean value for many repairs should be used. The
probability of survival (reliability function) considers no repairs. It is worth
examining how available systems really are, especially systems that are in the
continuous operation.
The availability A is a performance criterion for repairable systems that accounts
for both the reliability and maintainability properties. It describes the probability
that a component or system will operate satisfactorily at a given point in time when
used under stated conditions. The exact definition of availability is based on the
types of downtimes one chooses to consider in the analysis. Inherent availability
considers only repair downtime, expressed as mean time to repair (MTTR); it can be
calculated with:

MTBF 1
A¼ ¼ MTTR : ð4:15Þ
MTBF þ MTTR 1 þ MTBF

If preventive maintenance downtimes are also included (in addition to corrective

repair downtimes), the term achieved availability is used. Finally, the operational
availability is a measure of the average availability that includes all experienced
sources of downtime, i.e., administrative or waiting downtime, and logistic
downtime, in addition to both preventive maintenance and corrective repair
downtimes.
If we run the numbers with an example, we can get better insight into these
metrics. A system has a mean time between failures MTBF = 1000 h and a mean
time to repair MTTR = 10 h. The probability of survival R(t) for the period of
1000 h is as follows:
66 4 Reliability Analysis

Rð1000 hÞ ¼ ekt ¼ et=MTBF ¼ e1000 h=1000 h  0:37  37%:

If the component is repaired, the inherent availability A is as follows:

1
A¼ ¼ 0:99 ¼ 99%:
1þ 10 h
1000 h

Equation (4.15) shows that the same inherent availability is obtained for dif-
ferent mean failure intervals, when MTTR/MTBF is constant. Even unreliable
systems can have a high permanent availability, if the out-of-service period or
repair duration for failed components or modules is minimized. This illustrates the
importance of a carefully considered and planned modular system configuration,
good test facilities, and an efficient and capable repair service.

4.6.3 Electronic Systems Without Redundancy—Serial

Systems

System reliability, as explained in Sect. 4.5, depends on the reliability of individual

components and their interactions. Electronic systems without redundancy are
systems in which all components must work to ensure system success, i.e., serial
systems from a reliability point of view. In other words, if a single component fails,
then the entire system will fail. We assume constant failure rates, i.e., no functional
degradation, to simplify the analysis. We also assume that the reliabilities of
individual components are known under their actual operating conditions, i.e., their
failure rates kB were calculated under their actual operating conditions based on
their FIT values (kref) under reference conditions and adjusted using influence
factors (p) (Sect. 4.4.2).
If the survival probabilities (reliability parameters) of single elements 1 to n in a
system are R1(t) to Rn(t), the system reliability RS(t) of the whole unit can be
expressed as follows:

RS ðtÞ ¼ R1 ðtÞ  R2 ðtÞ  R3 ðtÞ  . . .  Rn ðtÞ: ð4:16aÞ

We can see from this product rule of reliability that the probability of survival of
a serial system is always less than the smallest individual probability of survival.
The more individual elements in an electronic system, the more likely it is to fail. If,
for example, the probability of survival of an individual component is 0.99 (99%)
and if the system comprises 10 such components, the system has a probability of
survival of 0.9910 = 0.904, which is still >90%. If, however, the number of such
components is 1000, the probability goes down to 0.991000 = 0.00004, i.e., 0.004%.
So the fact that modern microprocessors with 5 million times more components,
4.6 Reliability Analysis of Electronic Systems 67

that is, 5 billion transistors, work at all is a testament to the high reliability of
today’s microelectronic components.
The product rule of reliability can be used not only to determine the system
reliability, but also to determine the minimum required reliability of each compo-
nent in order to satisfy an expected system reliability. For example, if the system
reliability must not be less than 0.99, what is the minimum reliability of its 100
identical components? Using Eq. (4.16a), we get 0.99 = Rn(t)100, i.e.,
Rn(t) = 0.991/100 = 0.9999.
Substituting the reliability function for the exponential distribution as per
Eq. (4.8) in the product rule in Eq. (4.16a) yields:

RS ðtÞ ¼ ek1 t  ek2 t  ek3 t  . . .  ekn t ; ð4:16bÞ

RS ðtÞ ¼ eðk1 þ k2 þ k3 þ  þ kn Þt : ð4:16cÞ

The total failure rate of the serial system kS is thus the summation of the failure
rates of all components:

kS ¼ k1 þ k2 þ k3 þ    þ kn : ð4:17Þ

Assuming an exponential distribution, the mean time between failures (MTBF)

or the mean time to failure (MTTF) may be calculated from the reciprocal of the
failure rate (Eq. (4.12)). The MTBF for a serial system can then be expressed as
follows:

1
MTBF S ¼ mS ¼ : ð4:18Þ
kS

If the system is subjected to environmental and operational stress during rest

periods, then the failure rate is also applicable here and, hence, these periods should
be included in the calculations. This scenario can occur in systems that are also
partially operational during rest periods. Modules that have been switched off may
be thermally impacted by heat, for example. The following formula can be used in
such cases:

RðtÞ ¼ eðkon ton þ koff toff Þ ; ð4:19Þ

where kon is the failure rate for the “on” state, koff is the failure rate for the “off”
state, ton the service time or “on” period, and toff is the idle time or “off” period.
The procedure described above delivers only a useful approximate value when
the system being monitored continuously executes all states, i.e., all failure options
are effective and all components are active. The result of such a calculation can be
too pessimistic with standard modules for logic circuits, where often only a subset
of the available functions are used and failures in inactive elements have no effect.
68 4 Reliability Analysis

Redundancies should be included in the calculations (see Sect. 4.6.4) if the

system can only be partially viewed as a serial system in terms of its reliability; this
can improve upon the “worst-case” approach taken here, whose results are therefore
too pessimistic.

4.6.4 Electronic Systems With Redundancy—Parallel

Systems

Redundancy techniques must be used if the desired design reliability cannot be

achieved despite careful circuit design and the use of particularly reliable compo-
nents. Redundancy, as explained in Sect. 4.5.2, is the deployment of additional
components or modules that are not required for the main function (Fig. 4.9). The
purpose of these redundant components is to increase the reliability, as they can
perform the function of a failed element. Redundant components employed for the
purpose of reliability are characteristic of parallel systems that comprise a basic unit
and at least one standby unit.

Signal source Component Modul System

System without
redundancy

Component
redundancy

Module
redundancy

System
redundancy

Fig. 4.9 Communication networks with surplus, and thus redundant, components. Redundancy
can be built in at different levels, i.e., at the component, module, or system level
4.6 Reliability Analysis of Electronic Systems 69

A number of parallel paths should be made available to the signal, so that it can
follow an “alternative” route if an element fails. If, for example, there is a switch in a
transmission line that does not reliably close, the signal can be shunted through other
switches to mitigate the unreliability effects. The same applies to switches that do not
reliably open; other switches can be arranged in series in this case. Unreliable opening
and closing can be mitigated with a combination of four switches in a serial–parallel
cluster. This “quad redundancy” principle is shown in Fig. 4.10 with four diodes.
Redundancy can be built in at the lowest level, that is, in the components (with a
suitable parallel component in the simplest case, for example); at a higher level in
the modules; or at the system level (see Fig. 4.9). Increasing the redundancy level at
the component level for all components in a system leads to a greater increase in
reliability than a comparable increase in redundancy at the system level. To put it
more simply, duplicating all components in a system effects higher reliability for
the user than duplicating the system.
Redundancy elements are called “active” or “hot” if they are always operational
during the service period, as described in Sect. 4.5.2. The concepts of hot-spare or hot
redundancy are relevant in this context. Redundancy elements are “passive” or “cold”
if they come into operation only when they are actually needed. A system that detects a
faulty component and actuates a control element is required for this type of cold
standby or cold redundancy. The reliability of this failure monitor and the changeover
switch must be considered as well and integrated in the required level of reliability for
the parallel circuit. These complex cold standby redundancy issues are beyond the
scope of this book; please refer to [7] for a detailed treatment of this topic.
The probability of survival (reliability function) of a redundant system with
hot-spare redundancy is calculated from the failure probabilities of the same or
similar redundant elements, as the system fails exactly when all elements fail in the
given period. If F1(t) to Fr(t) are the failure distribution functions of redundant
elements 1 to r in a system with redundancy level r − 1, the system failure function
FS(t) can be expressed as follows:

FS ðtÞ ¼ F1 ðtÞ  F2 ðtÞ  F3 ðtÞ  . . .  Fr ðtÞ: ð4:20Þ

Fig. 4.10 Diode circuit with quad redundancy, in which the outputs of one stage are
interconnected to the inputs of the succeeding stage by a connection pattern so that failures in
the first stage are overridden in the second stage
70 4 Reliability Analysis

This product rule of unreliabilities shows that the failure probability of a parallel
system is always smaller than the smallest individual failure probability (failure
distribution function) of its elements. Should the theoretical assumption hold that a
single element i cannot fail (Fi(t) = 0), then the parallel system will not fail either
(FS(t) = 0 or RS(t) = 1).
Obviously, the unreliability of the system decreases as the number of parallel
components is increased; hence, the reliability increases with the number of
redundant components. Figure 4.11 illustrates the possibilities and limitations of
this increase in reliability with a parallel configuration of redundant elements. On
the one hand, the respective increase in the probability of survival drops with
increasing redundancy level: This means that single-digit redundancy levels should
be used. On the other hand, a significant increase in reliability by means of
redundancy is observed only in the period of MTBF (or MTTF) of its elements. The
probability of survival for this period can be increased from 37% (no redundancy)
to almost 100% with a redundant system, but then the probability of survival will
inevitably drop. This is due to the fact that a system with redundancies cannot
remain reliable for a longer period than its constituent elements.
Finally, it is important to be aware that simplifications during the investigation of
the reliability of redundant systems can lead to false conclusions. Critical analysis is
recommended, especially in connection with possible failure modes, as they can
impact the changeover to the standby unit and call into question the correct
assumption of a parallel structure in the context of reliability.

1,0
= 0,001 h

0,8 = 1/ = 1000 h
RS
( )=1 =1 (1 )
0,6

r=1 2 3 5 10
0,4
0,37

0,2

MTBF

0 1000 2000 3000 t in h

Fig. 4.11 Increase in the probability of survival of a system with hot-spare redundancy for
redundancy levels r − 1 = 0, 1, 2, 4, 9. The graph shows the decreasing benefit of ever increasing
redundancy levels as well as the reliability gain limited to the period of the mean time between
failures (MTBF) of its elements
4.6 Reliability Analysis of Electronic Systems 71

4.6.5 Service and Maintenance of Electronic Systems

A system is serviced to keep it in operation. Servicing can be divided into the three
areas: inspection, maintenance, and repair. Maintenance, in contrast to repair, is a
preventative measure to counteract wear and tear.
The random failures typically encountered in electronic systems cannot be
prevented by maintenance. A sudden short circuit or an interruption at normal load
is not due to wearout and are thus not predictable. Drift fails, i.e., a slow change in
attributes, are easier to deal with. Drift, which typically cannot be detected in digital
operating systems, causes output voltage shifts, such as change in gain amplifica-
tion, in analog components. A total failure can be prevented here with regular
inspections and maintenance, especially by monitoring, tuning, and replacing
components when necessary. Drift-related operation and failure modes for
non-redundant systems with and without maintenance are shown in Fig. 4.12.
The standby system takes over operation in the event of a failure for redundant
systems. If the failure is found during equipment condition assessment or mainte-
nance, a failure of the standby system has no impact.
Components should be replaced during planned maintenance if they exceed their
expected (intrinsic-fails-only) lifetime and, hence, are in danger of becoming
subjected to wearout failures. This applies especially to electromechanical com-
ponents with high cyclical or continuous loading, for example, fans for reducing the

Operability

Non-maintained system
Ocr with no failure
Failure range
up t

Non-maintained system with

failures and repairs
Ocr

up up up t
down down

Maintained system
Ocr with no failure

up up up up t
mt mt mt

Maintained system with up: uptime (operating time)

Ocr failure down: downtime (repair)
mt: maintenance time
up up up up up t Ocr: critical value of operability
mt mt down mt

Fig. 4.12 Drift characteristics of non-redundant maintained and non-maintained systems

72 4 Reliability Analysis

internal system temperatures. The wearout-failure distributions should be consid-

ered when designing systems with such components to enable preventive mainte-
nance schedules that are time-coordinated for all components. Determining the
times at which expendable modules are to be replaced should be a crucial part of
early design decisions.

4.7 Recommendations for Improving Reliability

of Electronic Systems

All employees involved in the design, development, and manufacture of reliable

systems should be proactively engaged with reliability issues. A range of measures
are required to assure the high reliability standards of components and systems are
met. The key considerations are outlined below. All of these measures have
associated material or personnel costs. A cost-benefit analysis is required to
determine an appropriate balance:
– The lowest number of components possible should be used in a given solution.
Please note that the failure rates for different components can vary greatly. The
total failure rate, for example, of 100 carbon-film resistors is lower than that of
one-film potentiometer. A potentiometer, therefore, should be replaced by a
voltage divider made of two resistors.
– Proven, tried, standard components should be used. Caution is advised with new
and unknown components. A balance needs to be struck between the benefits of
improved functionality (e.g., using the latest VLSI circuits) and the risk of
unknown reliability.
– Use reliable component types: failure rates can be greatly reduced by using
ceramic capacitors instead of electrolytic capacitors, for example.
– Operate components below their nominal ratings (power, voltage, current, etc.).
Operating components only at 50% power rating reduces the failure rate of
many components to a fifth, and sometimes up to a tenth, of its original value.
The cost of such overdesigned components increases in many cases approxi-
mately proportional to the rated load.
– The various components and modules of a system should be designed with the
same reliability. Designing different elements in a chain to different reliability
standards is, generally speaking, a waste of time and money.
– Components and modules should be operated at ambient temperatures that are
as low as possible.
– Components and modules should be prematurely aged so that early failures can
be eliminated before the components and modules leave the test field.
– Components and modules should be protected against climatic, mechanical, and
electrical stresses during storage, transportation, and operation.
– Preventive maintenance should be carried out if components reach the end of
their expected (intrinsic-fails-only) lifetimes. Wearout-failure distributions
4.7 Recommendations for Improving Reliability of Electronic Systems 73

should be considered in the design process to enable time-coordinated mainte-

nance schedules of expendable components and modules.
– Elements that are prone to failure or are subject to wear should be easy to service
and repair, and, hence, easy to access. These requirements should have a higher
priority than the typical desire for high packaging densities.
– Redundancy techniques should be applied where there is insufficient reliability.
Higher system reliability can be achieved by structural redundancy at the
component level than with similar levels of redundancy in higher levels of the
system. However, an increase in system reliability by means of redundancy is
only achievable during the MTBF (or MTTF) period of its redundant elements;
reliability inevitably drops after this period has elapsed. Hot-spare redundancy
avoids failure monitoring that is prone to error, and no changeover mechanism is
required.

References

1. IEC 61709:2011 Electric components - Reliability - Reference conditions for failure rates and
stress models for conversion, publication date 2011-06-24
2. Military Handbook Reliability Prediction of Electronic Equipment, MIL-HDBK-217F, 2
December 1991
3. MIL-R-11/RC 07/12: Electronic Components - Resistors Military Ordering Code
4. MIL-C-26655: Electronic Components - Capacitors Military Ordering Code
5. SN 29500: Failure Rates for Electronics and Electromechanical Components. Siemens AG
Munich, Corporate Technology, Dept. CT TIM IR SI
6. ISO 13849-1:2015, Safety of machinery – Safety-related parts of control systems – Part 1:
General principles for design, December 2015
7. A. Birolini, Reliability Engineering. Theory and Practice, 7th edition, Springer, 2014