1.
1 The Engineering Design Process
In electronic design, the Engineering Design Process (EDP) is a series of iterative steps used to
transform a vague idea into a functional, reliable electronic product. Unlike a standard "linear"
checklist, this cycle encourages going back to previous steps to refine the design as new
information emerges.
In simple terms, it’s how engineers think and work to turn ideas into practical, real-world
solution
TWO TYPES OF DESIGN PROCESSES
1. Prescriptive: prescriptive design processes set down an exact process, or systematic
recipe, for realizing a system. Prescriptive design processes are often algorithmic in nature
and expressed using flow charts with decision logic. An example of a prescriptive process
is shown in Figure 1.1, which describes the front end of the design process where the
problem and requirements are determined. A decision block is included where the
requirements are examined to determine if they satisfy the needs of the problem.
Figure 1.1: A prescriptive design process for problem identification and requirements selection.
2. Descriptive: This are informal frameworks that outline typical design activities without
strict sequencing, and the line between descriptive and prescriptive processes is often
blurred. A widely used descriptive design process moves from problem identification
through research, requirements, design, delivery, and maintenance. However, this linear
flow is unrealistic because design is inherently iterative. Designers frequently move back
and forth between phases, especially those that are closely related. While transitions
between distant phases are possible, they are often costly and time-consuming. Studies
have shown that the cost required to correct errors or make changes increases exponentially
as the project lifetime increases, as presented in Figure 1.3
A descriptive process that is widely applicable to design problems is shown in Figure 1.2.
Figure 1.2: A descriptive overview of the design process.
KEY DEFERENCE BETWEEN PERSPECTIVE AND DESCRIPTIVE
Prescriptive Design Descriptive Design
A "systematic recipe" or exact process for A less formal description of typical design
realizing a system. activities.
Algorithmic; follows a specific sequence of Non-linear; emphasizes that engineers jump
operations. between various phases.
Expressed using flow charts with strict Shown as a network of interconnected phases
decision logic. with links between all stages.
Rigid; you must satisfy the "decision block" Highly flexible; allows for transitions between
before moving forward. distant phases as needed.
1.11 Elements of the Design Process
Nearly all the phases of the design process in Figure 1.2 are covered below, with the exception of
the maintenance phase.
Problem identification, is to identify the problem and customer needs. This occurs in a variety of
ways, from someone conceiving a new idea to a client coming to you with a problem to solve. In
either case, it is important to determine the true needs for the product, device, or system (terms
that are used interchangeably throughout the book and often referred to as systems). Failure to
correctly identify the needs has negative ramifications for the entire process, typically resulting in
costly redesigns, or even worse, abandonment of the project.
Research phase: the design team conducts research on the basic engineering and scientific
principles, related technologies, and existing solutions. The objective is to become experts on the
problem, save time and money by not re-inventing the wheel, and be positioned to develop new
and innovative solutions.
Requirements Specification: articulates what the system must do for it to be successful and
to be accepted by the customer. It is important to focus on what the system must do, as opposed to
how the solution will be implemented. This is challenging since engineers tend to focus on
solutions and propose implementations early in the process. This is not surprising since
engineering education focuses on solving problems rather than specifying them. The requirements
are the mission statement that guides the entire project, and if properly developed, provide
flexibility for creativity and innovation in developing solutions.
Cost to
implement
changes
Project lifetime
Figure 1.3: The cost to implement design graph
Concept generation, many possible solutions to the problem are developed. The hallmark of
design is that it is open-ended, meaning that there are multiple solutions to the problem and the
objective is to develop the one that best meets the requirements and satisfies the constraints. In this
phase, wild creativity is encouraged, but it is ultimately tempered with critical evaluation of the
competing alternatives.
Prototyping and construction phase, different elements of the system are constructed and tested.
In rapid prototyping, the objective is to model some aspect of the system, demonstrating
functionality to be employed in the final realization. Many prototypes are discarded or modified
as the system evolves—the idea is to experiment, demonstrate proof of-concept principles, and
improve understanding. Prototypes may be used anywhere in the process—you may present the
client with prototypes after the concept generation phase, or they may be utilized in the design
phase to test a design idea, or as the final system is tested and developed.
During system integration, all of the subsystems are brought together to produce a complete
working system. This phase is challenging and time-consuming since many different pieces of the
design must be interfaced, and the team must work closely to make it all work. Care taken in the
design phase to clearly communicate the functionality and interfaces between subsystems aids in
system integration. System integration is closely tied to the test phase, where the overall system is
tested to demonstrate that it meets the requirements.
Delivery and acceptance: involve providing the system to the customer for testing based on
agreed criteria, after which it enters service. Development continues through maintenance,
upgrades, and correction of design issues. Understanding the design process increases the chances
of successful system development. Design is inherently flexible and iterative, requiring movement
between phases as understanding improves. While designers should aim for the best initial
solution, adaptability and willingness to revise are essential.
1.2.1 Systems Thinking
Systems thinking is a mental framework where you view an electronic device not as a pile of
components (resistors, transistors, wires), but as a collection of interacting subsystems that work
together to achieve a goal.
Core Concepts of Systems Thinking:
a. Interconnectivity (The Ripple Effect): Every component in a circuit exists in a state of
mutual dependency. In a professional environment, this is often called Cross-Talk or
Dependency Mapping. If you increase the processing speed of a CPU (to meet a
performance requirement), it draws more current. This extra current increases the heat
(thermal output), which might cause a nearby sensor to give inaccurate readings. Systems
thinking forces you to anticipate these "cascading" effects before they happen.
b. Hierarchy and Modularization: Complexity is managed by breaking the "Large" into the
"Small." This is a recursive process:
1. The Super-System: The environment (e.g., a Smart Home network).
2. The System: The device (e.g., a Smart Thermostat).
3. The Subsystem: A functional module (e.g., the Wi-Fi Connectivity Module).
4. The Circuit: The actual components (e.g., the radio chip, crystal oscillator, and antenna).
Understanding where you are in this hierarchy prevents "tunnel vision" and helps you
focus on the right level of detail at the right time.
c. The "Black Box" Approach (Functional Abstraction): Abstraction is a mental tool used
to hide unnecessary complexity. By treating a component as a Black Box, you define it
strictly by its Transfer Function: If I give this block Input A, it will produce Output B. This
allows an engineer to integrate a complex integrated circuit (like a GPS module) into a design
without needing a PhD in satellite physics. You only need to master the "Inputs"
(Power/Commands) and "Outputs" (Coordinates).
1.2.2 Block Diagram Modelling: The Structural Blueprint
A Block Diagram is a high-level flowchart of hardware. It serves as the primary communication
tool between hardware engineers, software developers, and stakeholders.
A. Importance of Block Diagrams:
a. Complexity Management (Data Compression): Humans cannot hold the logic of
10,000 components in their heads simultaneously. A block diagram "compresses" this
data. It provides a mental map that allows you to navigate the design without getting
lost in the "noise" of individual resistors.
b. Interface Definition (The "Contract"): One of the most common causes of project
failure is "mismatched interfaces." The block diagram forces you to define the
Communication Protocol (e.g., SPI, I2C, UART) and Voltage Levels (e.g., 3.3V vs 5V)
between modules early. It acts as a contract between different parts of the circuit.
c. Fault Isolation and Troubleshooting: When a prototype fails, the block diagram is
your diagnostic map. By measuring the signals between blocks (the "Interconnects"),
you can use a process of elimination to find the "Broken Block." This is much faster
than testing every single component on a board.
d. Parallel Engineering (Workflow Optimization): Large projects require teams. By
finalizing the block diagram first, the "Power Team" can work on the battery system
while the "Firmware Team" writes code for the processor, because they both know
exactly how those two blocks are supposed to connect.
B. The Anatomy and Notation:
a. Functional Blocks (Rectangles): These represent a "Stage" of processing. They should be
labeled with a Verb or a Functional Name (e.g., "Signal Conditioning," "Voltage
Regulation," "Power Amplification").
b. Signal Paths (Arrows):
i. Single-Headed: Information or energy flow is unidirectional (e.g., from a sensor
to a screen).
ii. Double-Headed: Bi-directional communication (e.g., a data bus where the CPU
both reads from and writes to memory).
c. Summing Points and Nodes (Circles): These are junctions where signals are mixed,
subtracted, or branched off. In control systems, these are used to calculate the "Error Signal.
d. System Boundary (Dashed Line): This defines the physical limits of your product. It
helps distinguish between what you are designing (Inside) and what the user provides, like
a wall outlet or a smartphone app (Outside).
1.2.3 Example: The Bluetooth Speaker Signal Chain
Let's dissect the Bluetooth Speaker to see these concepts in action:
See figure 1.3 for the block diagram.
1. Power Management Block: This is the "Heart." It takes raw voltage from a Lithium-ion
battery and uses Voltage Regulators to "clean" and "step down" the power to 3.3V for the
chips and 12V for the loud speakers.
2. Connectivity Block (Bluetooth): This is the "Ear." It contains a radio and a processor. It
"listens" for RF waves, decodes the digital packets, and extracts the raw music data.
3. Audio Processing Block (DSP/DAC): This is the "Translator." It takes the digital "1s and
0s" and mathematically processes them (adjusting bass/treble) before converting them into
a tiny, vibrating electrical signal (Analog).
4. Amplification Block: This is the "Muscle." The analog signal is too weak to move a heavy
speaker. The amplifier takes energy from the Power Block and uses it to make a high-
power copy of the audio signal.
5. Transducer Block (The Speaker): This is the "Voice." It converts electrical energy into
physical movement (vibration), which we hear as sound.
Figure 1.4 Block diagram of a Bluetooth speaker
1.3 Design requirement and constraints
In electronic design, Requirements and Constraints act as the "bounding box" of a project. They
represent the bridge between a theoretical idea and a physical, sellable product.
While a Requirement defines the functional goals (what the device must do), a Constraint defines
the boundaries and limitations (the rules the designer must follow). In professional engineering,
three constraints—Cost, Power, and Reliability—form the "Triple Constraint" that dictates
almost every design decision.
1.3.1 Design Requirements (The "What")
Requirements are the functional specifications of the device. They describe what the system must
do to satisfy the user's needs. Requirements are usually defined at the beginning of a project in a
document called a Product Requirements Document (PRD).
A. Functional Requirements
These define the specific tasks the electronics must perform.
Sensing: the device must measure ambient temperature between 10℃ and 50℃
Actuation: the system must be able to drive a 12V DC motor at 2.0A.
User Interaction: The user must be able to reset the device via a physical button.
B. Performance Requirements
These define how well the functional requirements must be performed.
Accuracy: "The temperature reading must be accurate within ±0.5℃
Speed/Latency: "The system must respond to a sensor trigger within 10 milliseconds."
Connectivity: "The wireless range must exceed 30 meters indoors."
C. Physical Requirements
These define the "body" of the device.
Size/Weight: The PCB must fit within a $50mm X 50mm enclosure.
Ergonomics: The display must be sunlight-readable at 500 units of brightness.
1.3.2 Design Constraints (The "How")
Constraints are the boundaries or restrictions placed on the designer. They do not tell you what
the device does; they tell you the limits you must stay within while building it.
A. Cost (Economic Constraints)
Cost is often the most rigid constraint in commercial electronics.
Target BOM Cost: The total cost of all components must not exceed N2k per unit.
Assembly Constraints: The design must use only 2-layer PCBs to keep fabrication costs low.
B. Power (Energy and Thermal Constraints)
Power constraints dictate the portability and "heat signature" of the device.
Source Constraints: The device must operate solely on a 3.7V Li-ion battery.
Efficiency Constraints: The battery must last for at least 72 hours of continuous use.
Thermal Constraints: The external casing temperature must not exceed 45℃ to prevent user
burns.
C. Reliability (Performance Constraints)
Reliability is the constraint on the "life" and "toughness" of the product.
Longevity (MTBF): "The device must have a Mean Time Between Failures of 10,000 hours."
Environmental Constraints: "The device must be IP67 rated (waterproof and dustproof)."
Regulatory/Legal Constraints: "The device must pass FCC/CE certification for
electromagnetic interference (EMI)."
Comparison between requirement and constraints
Design Requirements Design Constraints
"What does it do?" "What are the limits?"
Functionality and User Need Budget, Physics, and Environment
"It must play music via Bluetooth." "It must cost less than N20k to make."
Often non-negotiable (The goal). Requires Trade-offs (The compromise).
Why the Distinction Matters
In a real engineering job, a client might give you a Requirement: "I want a drone that flies for 2
hours." However, the constraints of current battery technology (Power) and the weight of the
motors (Physics) might make that requirement impossible. Engineering is the process of
negotiating between what the user requires and what the constraints of the real world allow.
1.4 Documentation standard and record keeping
In the professional world of engineering, a design is only as good as its documentation. If a project
isn't documented, it effectively doesn't exist. For students and professionals following the NBTE
(National Board for Technical Education) style, documentation is centered on the Logbook.
The logbook is a legal and technical record of the "thought process" and "physical progress" of a
project.
1.4.1 The Purpose of Record Keeping
Documentation is not just a summary of the final product; it is a chronological history.
Intellectual Property (IP): A properly dated logbook serves as proof of when an invention
was created.
Traceability: If a circuit fails, the logbook helps you trace back to which component was
changed or which calculation was used.
Continuity: It allows another engineer to pick up the project where you left off.
1.4.2 NBTE Style Logbook Requirements
The NBTE standard for technical logbooks (common in Industrial Training and Engineering
projects) emphasizes structure, frequency, and verification.
A. Daily/Weekly Entry Format
Each entry must be clear and technical. A standard entry includes:
1. Date and Time: Exactly when the work was performed.
2. Activity Description: What specific block of the system were you working on? (e.g.,
"Soldering the Power Management block").
3. Technical Observations: This is the most important part. Do not just say "It worked." Say:
"Measured 5.02V at the output of the LM7805 regulator. Heat sink reached 40°C after 10
minutes."
4. Sketches and Diagrams: Hand-drawn circuit fragments or block diagrams to visualize the
day's work.
5. Challenges/Problems Encountered: What went wrong? (e.g., "The LDR sensor is too
sensitive to ambient room light").
6. Proposed Solutions: How you plan to fix the problem in the next session.
B. The "Validation" Requirement
In the NBTE style, a logbook is an official document.
Supervisor’s Signature: Entries must be signed weekly by an industry or academic
supervisor.
No Erasures: You should never use "white-out" or erase mistakes. Instead, draw a single line
through the error and write the correction next to it. This maintains the integrity of the record.
1.4.3 Standard Documentation Types
Beyond the logbook, a complete project requires three main "Standards":
1. The Design Notebook
Where the "messy" work happens—initial brainstorms, raw calculations for Power Budgets, and
component comparisons from datasheets.
2. The Bill of Materials (BOM)
A formal table that lists:
i. Item Number
ii. Component Name/Value (e.g., Resistor 10kΩ)
iii. Quantity
iv. Package Type (e.g., SMT LM0805 or Through-hole)
v. Supplier/Part Number
3. The Technical Report
The final "formal" document that summarizes the Requirements, the Block Diagrams (1.4), and
the Final Results.
