One of the most common product-development mistakes is beginning detailed circuit design too early.
An MCU is selected.
Then memory is added.
Then wireless is added.
Then a battery is selected.
Then engineers discover the processor needs more power.
The larger power system produces more heat.
The enclosure becomes too small.
The antenna location becomes poor.
EMC becomes difficult.
Firmware requires more memory.
The PCB grows.
The product misses its cost target.
Each individual engineering decision may have been reasonable.
But the system architecture was never optimized as a whole.
365PCB approaches complex ODM development from the opposite direction:
Design the System Before Designing the Board.
System Context Architecture
Before defining the internal architecture, engineers must understand the system boundary.
What interacts with the product?
That may include:
Users
Sensors
Actuators
Machines
Other Electronic Devices
Cloud Platforms
Mobile Applications
Industrial Networks
External Power
Battery Systems
Mechanical Systems
Environmental Conditions
Manufacturing Equipment
Service Tools
Regulatory Environments
A system-context model helps define:
This prevents an important architectural mistake:
Designing the Product in Isolation From the System It Must Operate Within.
Functional Architecture
What Must the System Actually Do?
Before assigning functions to processors, ICs, PCBs, or software modules, we define the functional architecture.
A product may perform functions such as:
The purpose of functional architecture is to separate:
from:
How the system will eventually accomplish it.
For example, the requirement:
Detect abnormal motor vibration and report an equipment-health condition.
may require:
That is a system function chain.
The processor selection comes later.
Functions Should Drive Architecture — Components Should Not Drive Functions.
Logical Architecture
Once functions are understood, they can be grouped into logical subsystems.
Depending on the product, these may include:
Compute Subsystem
MCU · MPU · SoC · FPGA · DSP · NPU
Sensing Subsystem
Sensors · Analog Front End · ADC · Signal Conditioning
Connectivity Subsystem
Ethernet · Wi-Fi · BLE · Thread · Cellular · CAN · RS485
Power Subsystem
Input Protection · Conversion · PMIC · Battery · Charging · Distribution
Control Subsystem
Real-Time Control · Motor Control · Actuation · Safety Logic
Storage Subsystem
Flash · EEPROM · eMMC · UFS · SSD · Removable Storage
User Interface Subsystem
Display · Touch · Buttons · LEDs · Audio
Security Subsystem
Secure Boot · Authentication · Encryption · Secure Storage
Mechanical / Thermal Subsystem
Enclosure · Cooling · Structural Interfaces · Thermal Paths
This allows product complexity to be decomposed into manageable engineering domains without losing the relationships between them.
Physical Architecture
The physical architecture maps logical functions onto actual product elements.
The product may ultimately use:
or:
Main Control Board
Power Board
RF Board
Sensor Board
Display Board
Interface Board
The architecture decision may depend on:
PCB size
Layer count
RF isolation
Power density
Serviceability
Thermal behavior
Connector complexity
Product variants
manufacturing cost
assembly strategy
testability
The question is not automatically:
Can everything fit on one board?
The better question is:
What Physical Architecture Produces the Best Overall Product?
Compute Architecture
MCU, MPU, SoC, FPGA, DSP or NPU?
One of the most important architecture decisions is determining how the product will compute.
Different platforms solve different problems.
Suitable for deterministic embedded control, sensor acquisition, low-power systems, real-time applications, and cost-sensitive embedded products.
Appropriate when products require richer operating systems, graphics, networking, large memory, complex applications, or Linux-class environments.
Can integrate CPU, GPU, connectivity, multimedia, security, AI, and specialized accelerators.
Useful where hardware-level parallelism, deterministic high-speed processing, custom interfaces, extremely precise timing, or reconfigurable logic is required.
Designed for computationally intensive signal-processing workloads such as filtering, communications, control, audio, and certain measurement systems.
Increasingly important for:
Computer vision
Local inference
Classification
Object detection
Sensor fusion
Edge AI
Advanced systems may combine several of these.
For example:
MCU + FPGA
MPU + MCU
SoC + NPU
CPU + FPGA
MCU + Wireless SoC
Architecture engineering evaluates the correct division of responsibility between them.
Use the Right Compute Architecture — Not Simply the Fastest Processor.
Hardware / Software Partitioning
One of the most important architecture decisions is deciding:
What Should Be Hardware?
and
What Should Be Software?
A function implemented in firmware may offer:
But hardware acceleration may provide:
For example:
An algorithm might run on:
or
or
or
The correct choice depends on:
This partitioning is particularly important in:
Robotics
Machine vision
AI edge products
Industrial control
motor control
communications
high-speed instrumentation
Architecture Determines Where Intelligence Lives.
Real-Time Architecture
Many embedded products must respond within deterministic timing limits.
Examples include:
industrial automation
protection systems
high-speed acquisition
precision control
communications
synchronized sensor systems
Architecture analysis may define:
Missing a deadline is unacceptable.
Timing is important but some variation can be tolerated.
Engineering considerations may include:
task scheduling
priority
hardware timers
synchronization
real-time communication
memory contention
operating-system behavior
worst-case execution timing
Depending on the product, architecture may use:
Average Performance Is Not Enough When the Product Depends on Worst-Case Timing.
Memory Architecture
Memory is often treated as an afterthought.
In advanced products, it can determine system performance.
Architecture may evaluate:
Volatile Memory
SRAM · SDRAM · DDR · LPDDR
Non-Volatile Memory
NOR Flash · NAND Flash · EEPROM · eMMC · UFS
High-Capacity Storage
SSD · NVMe · removable storage
Engineering considerations may include:
bandwidth
latency
bus width
error correction
endurance
retention
boot architecture
security
power
signal integrity
thermal behavior
High-performance architectures must also evaluate memory bandwidth relative to compute demand.
A processor capable of enormous computation can still be limited by memory throughput.
Compute Performance Is Often Memory-System Performance.
Edge AI Architecture
Modern electronic products increasingly perform intelligence locally rather than sending every task to the cloud.
An Edge AI architecture may include:
Architecture decisions can involve:
inference latency
memory bandwidth
camera interfaces
preprocessing
quantization
thermal limits
power budget
cloud dependency
privacy
offline operation
For battery or thermal-constrained products, the correct metric is not only computational performance.
It may be:
Useful AI Performance per Watt.
Sensor & Data Acquisition Architecture
For sensing and measurement products, architecture starts with the physical quantity being measured.
The complete signal chain may be:
Architecture engineering considers:
sensor technology
accuracy
signal level
bandwidth
sampling rate
reference architecture
noise
synchronization
calibration
temperature drift
isolation
For multi-sensor systems, architecture may also include:
combining inputs such as:
vision
radar
encoders
current
temperature
environmental sensors
to produce a more reliable estimate than any individual sensor can provide.
RF & Wireless System Architecture
It interacts with the complete product.
Architecture decisions can include:
Wi-Fi
Bluetooth / BLE
Thread
Zigbee
LoRa / Sub-GHz
GNSS
LTE / Cellular IoT
and other application-specific wireless technologies.
Engineers evaluate:
frequency
range
throughput
latency
topology
antenna architecture
enclosure influence
coexistence
power
security
certification
regional requirements
A sophisticated connected product may contain several radios simultaneously.
For example:
This creates new architecture problems involving:
antenna placement
coexistence
spurious emissions
power peaks
thermal behavior
Wireless Architecture Is a System Problem, Not Just an RF Circuit.
Power Architecture
Every Function Eventually Becomes a Power Requirement.
A modern electronics platform may contain:
12 V input
5 V
3.3 V
1.8 V
1.2 V
0.8 V Core
plus separate supplies for:
sensors
analog
memory
motors
displays
high-current loads
Architecture decisions include:
isolated vs non-isolated
buck / boost / buck-boost
distributed vs centralized power
sequencing
current capacity
transient response
efficiency
ripple
thermal dissipation
At the highest level, power architecture should be co-designed with:
PI + Thermal + PCB + Mechanical + Firmware.
Battery & Energy Architecture
For battery-powered products, architecture goes beyond simply choosing a battery capacity.
It can involve:
The engineering team may model:
peak current
average current
usage profile
sleep states
battery runtime
charging time
cell balancing
low-temperature behavior
aging
safety constraints
Battery Life Is an Architectural Outcome.
Communication & Interface Architecture
A complex product can include dozens of interfaces.
Examples:
Low-Speed Board-Level Interfaces
SPII²CUART
Industrial Interfaces
CAN / CAN FDRS485ModbusIndustrial Ethernet
Consumer / Computing Interfaces
USBEthernetPCIe
High-Speed Internal Interfaces
MIPILVDSSerDesDDR
Architecture engineering defines not simply the protocol but the complete interface contract:
Function
Bandwidth
Latency
Electrical Layer
Connector
Cable
Isolation
Termination
EMC
Error Handling
Software Protocol
Interfaces Are Where Subsystems Meet — and Where Integration Problems Often Begin.
High-Speed Interconnect Architecture
As products move into higher bandwidth, architecture must increasingly consider PCB electrical performance before detailed layout begins.
This may involve:
high-speed Ethernet
high-speed SerDes
Early architecture decisions can determine:
stack-up
layer count
material family
connector choice
trace length
via strategy
reference planes
routing topology
loss budget
At sufficiently high speed:
PCB Architecture Becomes Part of System Architecture.
This is one area where 365PCB's connection between product development and real PCB manufacturing can be particularly valuable.
Clock, Timing & Synchronization Architecture
Timing can become a system-level requirement in:
communications
data acquisition
machine vision
instrumentation
networking
robotics
distributed sensors
Architecture may include:
oscillators
clock generators
clock distribution
synchronization
hardware timestamps
trigger synchronization
Engineering must consider:
Timing should be budgeted like power and thermal performance.
Time Is a System Resource.
Data Architecture
Modern connected products generate increasing amounts of data.
System architecture should define:
Where Data Is Created
Sensors · Cameras · Interfaces
Where Data Is Processed
MCU · MPU · FPGA · DSP · NPU
Where Data Is Stored
RAM · Flash · eMMC · SSD · Cloud
Where Data Is Sent
HMI · Network · Gateway · Cloud
How Long Data Must Be Retained
Architecture decisions may therefore include:
throughput
storage size
compression
buffering
logging
database format
synchronization
integrity
privacy
encryption
High-data-rate products increasingly need:
Data-Flow Architecture Before Hardware Architecture Is Frozen.
Cybersecurity Architecture
Connected product security cannot be added after hardware development.
Architecture may need to establish a hardware root of trust.
Potential elements include:
Secure Boot
Trusted Execution
Secure Element / TPM
Hardware Crypto
Secure Key Storage
Device Identity
Firmware Signing
Encrypted Communication
Debug-Port Security
OTA Authentication
Rollback Protection
This creates a security chain:
Security requirements may influence processor selection, memory architecture, manufacturing provisioning, firmware architecture, and cloud infrastructure.
Security Is an Architecture — Not a Feature.
Reliability & Fault Architecture
Complex systems should consider not only normal operation but also:
What Happens When Something Fails?
Potential architecture techniques may include:
watchdogs
brownout protection
redundant sensing
fault detection
diagnostic channels
safe state
power-domain isolation
thermal protection
communication timeout
memory integrity
error correction
logging
graceful degradation
Depending on the product, engineers may perform:
FMEA
Fault Analysis
Risk Analysis
Derating Analysis
Reliability Allocation
The architecture should define which failures:
Must Be Prevented
Must Be Detected
Must Be Tolerated
or
Reliability Is Easier to Architect Than to Repair Later.
EMC Architecture
EMC problems frequently originate at the architectural level.
Examples include:
long noisy cable interfaces
poor grounding topology
switching power placement
inadequate isolation
high-current motor drivers near sensitive analog circuitry
enclosure and shield decisions
Therefore architecture planning may define:
Power Zones
Analog Zones
Digital Zones
RF Zones
Isolation Boundaries
Ground Relationships
Cable Interfaces
Shield Connections
before PCB layout begins.
Good EMC Begins Before the PCB Is Routed.
Mechanical Architecture
Electronic system architecture must fit the physical product.
Important interactions include:
PCB Shape
Board Location
Connectors
Antenna Position
Battery Position
Display
User Interface
Cooling
Mounting
Cable Routing
Service Access
For rugged or industrial electronics, architecture may additionally consider:
vibration
mechanical support
environmental sealing
connector retention
shock
structural loads
conformal coating
thermal expansion
Electrical and mechanical architecture should therefore evolve together.
Thermal Architecture
As compute density and power density increase, thermal architecture becomes a first-class engineering discipline.
The thermal path may be:
Architecture decisions may include:
passive cooling
forced airflow
heat sink
vapor chamber
enclosure conduction
thermal interface materials
thermal throttling
The right time to solve thermal architecture is:
Before Mechanical Design Is Frozen.
PCB Architecture
Before schematic and layout, the system architect may already need to make decisions affecting PCB construction.
These can include:
single-board vs multi-board
approximate board size
layer count
stack-up concept
rigid-flex requirement
high-speed material
controlled impedance
power-plane strategy
isolation distances
connector strategy
For complex products, architecture should therefore connect directly to PCB manufacturing engineering.
The PCB Is Not Merely a Carrier for the Architecture.
It Is Part of the Architecture.
Design for Manufacturing Architecture
A product architecture can either make manufacturing easy or make it permanently difficult.
Architecture-level DFM considerations can include:
component package selection
board count
connector count
assembly sequence
calibration requirements
accessible test points
programming interfaces
modular construction
cable complexity
enclosure assembly
service access
The goal is not only:
Does the product work?
but also:
Can thousands of products be built consistently?
Production Problems Often Begin as Architecture Decisions.
Design for Test Architecture
Testing should also begin at architecture stage.
Questions include:
What must be measured in production?
Which functions can be self-tested?
What test access is required?
How will firmware be programmed?
How will serial numbers be generated?
What data should be recorded?
What constitutes PASS / FAIL?
This may influence:
Test Points
Connectors
Debug Interfaces
Built-In Self-Test
Firmware Test Modes
Fixtures
Traceability
A design that cannot be efficiently tested can become expensive to manufacture even if the electronics are excellent.
Product Platform & Modular Architecture
World-class ODM development should not always optimize for one isolated SKU.
If the customer expects a product family, we can evaluate a platform architecture.
For example:
Shared processor, memory, power, firmware foundation.
Different:
wireless radios
sensor boards
displays
power options
This can support:
Basic
Professional
Industrial
Regional
product variants.
Potential advantages include:
higher reuse
faster future development
common firmware
common manufacturing process
reduced certification duplication
simpler supply chain
Architect the Platform — Not Just the First Product.
Architecture Trade Studies
The first workable architecture is rarely automatically the best architecture.
365PCB engineering can compare alternatives against a structured set of criteria.
For example:
Architecture
Performance
Power
Cost
Risk
Thermal
Development
MCU
Medium
Excellent
Excellent
Low
Excellent
Low
MPU
High
Medium
Medium
Medium
Medium
Medium
FPGA
Very High / Specialized
Medium
Higher
Higher
Medium
Higher
SoC + NPU
AI-Optimized
Medium
Medium/High
Medium
Challenging
Medium
The actual matrix changes by project.
Criteria can include:
performance
power
size
weight
cost
thermal
technical risk
supply-chain risk
certification
schedule
software complexity
manufacturing complexity
future scalability
Architecture Is the Discipline of Managing Trade-Offs.
Engineering Budgets
World-class architecture often turns vague targets into allocated engineering budgets.
Examples:
20 W total system limit.
Allocate allowable power across:
Compute + RF + sensors + display + peripherals.
Allocate heat generation and thermal resistance.
Allocate allowable latency through the processing chain.
Allocate loss and margin between package, PCB, vias, connector, and receiver.
Allocate measurement uncertainty across the complete signal chain.
Allocate target product cost across major subsystems.
This creates measurable architecture discipline.
If Margin Is Not Allocated, It Will Usually Be Consumed.
Model-Based System Architecture
For highly complex systems, architecture can move beyond disconnected diagrams and spreadsheets.
Modern MBSE can connect:
SysML 2.0 was formally adopted by OMG in 2025, with improvements in modeling precision, consistency, interoperability, APIs and machine-readable system descriptions.
ISO/IEC/IEEE 42010:2022 likewise provides the international framework for expressing architecture descriptions through architectural concepts, viewpoints, model kinds and their relationships.
For sufficiently complex ODM programs, this enables an engineering digital thread rather than isolated documents.
Requirements and Architecture Should Remain Connected.
Architecture Views for Different Engineering Teams
A single block diagram rarely explains a complex product adequately.
Different stakeholders need different views.
An architecture package may therefore contain:
What does the product do?
How are functions grouped?
What hardware implements them?
How are boards, processors and components organized?
How are software layers and services organized?
How do system elements communicate?
How is energy distributed?
How does information move?
Where are trust boundaries?
How does heat move?
How will the system be built and tested?
This multi-view approach is consistent with modern systems architecture practice, where architecture must serve multiple engineering concerns rather than only one diagram.
Architecture Verification
Before committing to detailed development, critical architecture assumptions should be challenged.
Depending on the project, this may involve:
calculation
simulation
breadboard experiments
proof-of-concept modules
processor benchmarks
power measurements
thermal simulation
RF link analysis
SI analysis
interface testing
prototype algorithms
The purpose is to answer:
Which Architectural Assumptions Are Most Dangerous If They Are Wrong?
Those assumptions should be tested first.
Architecture Reviews
For sophisticated projects, architecture maturity can be reviewed before design freeze.
A review may examine:
Have all important requirements been addressed?
Are subsystem boundaries defined?
Do compute, power, thermal and communication budgets close?
Are high-risk assumptions identified?
Can the proposed product be built and tested?
Are key technology choices sustainable?
Can the architecture support future product growth?
This helps prevent expensive redesign after schematic, PCB, enclosure and firmware development have already progressed.
Architecture to Detailed Engineering
Once architecture is sufficiently mature, it becomes the technical foundation for subsequent 365PCB ODM disciplines:
The architecture is therefore not another document sitting beside the design.
It Is the Engineering Map That Controls the Design.
Architecture Designed for Production
A pure product-design consultancy may architect a product and then hand the files to a manufacturer.
365PCB's ODM model can connect architecture directly with manufacturing realities involving:
component availability
package assembly risk
high-value components
programming
test fixtures
cable assemblies
enclosure manufacture
system assembly
reliability
repeat production
That means manufacturing questions can influence architecture before design freeze, not after.
Architecture Should Understand the Factory.
What Does World-Class System Architecture Look Like?
At its highest level, electronic product architecture connects:
And every major decision should have:
A reason.
A trade-off.
A risk.
A verification method.
That is the level of architecture discipline we want to apply to complex ODM development.
Depending on project scope, deliverables may include:
System Context Diagram
System Architecture Specification
Functional Architecture
Logical Architecture
Physical Architecture
Product Block Diagram
Subsystem Definition
Hardware Architecture
Software / Firmware Architecture
Hardware–Software Partitioning
Processing Platform Evaluation
Memory Architecture
Power Architecture
Power Budget
RF & Connectivity Architecture
Antenna Architecture Inputs
Sensor Architecture
Interface Architecture
Interface Control Document
Data-Flow Architecture
Timing Architecture
Security Architecture
Thermal Architecture
Reliability Architecture
Preliminary PCB Architecture
Product Variant / Platform Architecture
Engineering Budgets
Architecture Trade Studies
Risk Register
DFX Architecture Assessment
Verification Strategy
Prototype Strategy
Architecture Review Report
The exact deliverables should match the complexity and commercial requirements of the project rather than creating documentation for documentation's sake.
You do not need to arrive with a completed schematic.
You can bring:
or simply:
The Performance and Functions You Need the Product to Deliver.
365PCB can help define how the electronics should be structured before detailed development begins.
Architect the Product Before You Commit the Design.
Engineer the Interfaces Before Integration.
Engineer the Margin Before Testing.
Engineer Manufacturing Before Production.
365PCB System Architecture Design connects:
Requirements + Electronics + Firmware + RF + Power + Mechanical + Thermal + Reliability + Manufacturing
into one coordinated product architecture.
From Product Requirements to Production-Ready Architecture.
[Discuss Your Product Architecture]
[Start an ODM Development Project]
[Submit Your Product Requirements]
English
