Back to Sensors & Actuators Series

Part 12: Professional & Industry-Level Skills

July 14, 2025 Wasil Zafar 45 min read

Functional safety standards (ISO 26262, IEC 61508), embedded Linux with Yocto/Buildroot, DSP signal processing, FPGA fundamentals, and the complete product lifecycle from concept to end-of-life.

Table of Contents

  1. Functional Safety
  2. Embedded Linux
  3. DSP Fundamentals
  4. FPGA Introduction
  5. Product Lifecycle
  6. Conclusion & Next Steps

Functional Safety Standards

Functional safety ensures that safety-related systems respond correctly to inputs, including detecting and handling faults. When embedded systems control vehicles, industrial machines, or medical devices, compliance with international safety standards is mandatory.

ISO 26262 — Automotive

ASIL Classification (Automotive Safety Integrity Levels)

ASILSeverityExample SystemsRequirements
QMNon-safetyInfotainment, seat heaterStandard quality management
ASIL ALowRear lights, hornBasic safety analysis
ASIL BMediumHeadlights, wipersSystematic testing + analysis
ASIL CHighABS, ESC, power steeringFormal methods recommended
ASIL DHighestAirbags, autonomous drivingStrictest process + verification

IEC 61508 — Industrial

SIL Levels (Safety Integrity Levels):
  • SIL 1: Probability of dangerous failure < 10-5 per hour. Basic process control
  • SIL 2: PFD < 10-6 per hour. Emergency shutdown systems
  • SIL 3: PFD < 10-7 per hour. Nuclear reactor safety, railway signaling
  • SIL 4: PFD < 10-8 per hour. Aircraft flight control (extremely rare in industrial)

IEC 62304 — Medical Device Software

Medical Software Safety Classes:
  • Class A: No injury or damage to health possible. Documentation-light process
  • Class B: Non-serious injury possible. Requires architecture documentation, integration testing
  • Class C: Death or serious injury possible. Full lifecycle traceability, formal verification, detailed unit testing

Embedded Linux

Linux on MCU vs MPU

When to Use Linux vs RTOS

FactorRTOS (FreeRTOS, Zephyr)Embedded Linux
ProcessorCortex-M (MCU)Cortex-A (MPU) — needs MMU
RAM16 KB–1 MB32 MB minimum, typically 256 MB+
Boot timeMillisecondsSeconds (optimizable to <2s)
LatencyDeterministic (µs)Non-deterministic (use PREEMPT_RT for near-real-time)
NetworkinglwIP, minimalFull TCP/IP, WiFi, BLE, cellular
Best forHard real-time, low powerUI, networking, file systems, ML

Yocto & Buildroot

# Buildroot: Build a minimal Linux image for Raspberry Pi 4
git clone https://github.com/buildroot/buildroot.git
cd buildroot

# Select target board
make raspberrypi4_64_defconfig

# Customize (add packages, kernel config)
make menuconfig

# Build complete image (kernel + rootfs + toolchain)
make -j$(nproc)

# Output: output/images/sdcard.img
# Flash to SD card:
sudo dd if=output/images/sdcard.img of=/dev/sdX bs=4M status=progress

DSP Fundamentals

FIR & IIR Filters

// FIR low-pass filter implementation (fixed-point for MCU)
#include <stdint.h>

#define FIR_ORDER 16

// Coefficients generated with scipy.signal (Q15 fixed-point)
static const int16_t fir_coeffs[FIR_ORDER] = {
    328, 765, 1534, 2687, 4109, 5627, 7032, 8097,
    8097, 7032, 5627, 4109, 2687, 1534,  765,  328
};

static int16_t fir_buffer[FIR_ORDER] = {0};
static uint8_t fir_index = 0;

int16_t fir_filter(int16_t input) {
    fir_buffer[fir_index] = input;

    int32_t acc = 0;
    uint8_t idx = fir_index;
    for (int i = 0; i < FIR_ORDER; i++) {
        acc += (int32_t)fir_coeffs[i] * fir_buffer[idx];
        idx = (idx == 0) ? FIR_ORDER - 1 : idx - 1;
    }
    fir_index = (fir_index + 1) % FIR_ORDER;

    return (int16_t)(acc >> 15);  // Q15 normalization
}

FFT Analysis

# Vibration analysis using FFT on accelerometer data
import numpy as np
import matplotlib.pyplot as plt

# Simulate accelerometer data: 50 Hz vibration + 200 Hz bearing fault
fs = 1000  # Sampling rate (Hz)
t = np.arange(0, 1.0, 1/fs)
signal = (0.5 * np.sin(2 * np.pi * 50 * t) +   # Normal vibration
          0.1 * np.sin(2 * np.pi * 200 * t) +   # Bearing defect
          0.05 * np.random.randn(len(t)))         # Noise

# Compute FFT
N = len(signal)
fft_vals = np.fft.rfft(signal)
fft_freqs = np.fft.rfftfreq(N, 1/fs)
fft_magnitude = 2.0 / N * np.abs(fft_vals)

# Plot frequency spectrum
plt.figure(figsize=(10, 4))
plt.plot(fft_freqs, fft_magnitude)
plt.xlabel('Frequency (Hz)')
plt.ylabel('Amplitude')
plt.title('Vibration Frequency Spectrum')
plt.axvline(x=50, color='g', linestyle='--', label='50 Hz (normal)')
plt.axvline(x=200, color='r', linestyle='--', label='200 Hz (fault)')
plt.legend()
plt.grid(True)
plt.tight_layout()
plt.show()

FPGA Introduction

FPGA vs MCU

When to Choose FPGA over MCU

CriteriaMCUFPGA
ProcessingSequentialMassively parallel
LatencyMicrosecondsNanoseconds (clock cycle)
I/O countDozens of pinsHundreds of configurable pins
Best forControl logic, protocols, UIHigh-speed ADC, motor control, video processing
DevelopmentC/C++, fast iterationVerilog/VHDL, longer design cycle
Cost$0.50–$20$5–$500+

HDL Basics — Verilog

// PWM generator in Verilog (runs on FPGA fabric)
module pwm_generator #(
    parameter COUNTER_WIDTH = 16
)(
    input  wire clk,
    input  wire rst_n,
    input  wire [COUNTER_WIDTH-1:0] duty_cycle,  // 0 to 65535
    input  wire [COUNTER_WIDTH-1:0] period,       // PWM period
    output reg  pwm_out
);

    reg [COUNTER_WIDTH-1:0] counter;

    always @(posedge clk or negedge rst_n) begin
        if (!rst_n) begin
            counter <= 0;
            pwm_out <= 0;
        end else begin
            if (counter >= period)
                counter <= 0;
            else
                counter <= counter + 1;

            pwm_out <= (counter < duty_cycle) ? 1'b1 : 1'b0;
        end
    end

endmodule

Product Lifecycle

Embedded Product Development Phases (V-Model):
  1. Requirements: System requirements specification (SRS), safety goals, use cases
  2. Architecture: Hardware/software partitioning, block diagrams, interface definitions
  3. Detailed Design: Schematics, firmware modules, algorithms, state machines
  4. Implementation: PCB layout, firmware coding, unit tests
  5. Integration Testing: Hardware + software integration, peripheral bring-up
  6. System Testing: Full system validation against requirements
  7. Acceptance Testing: Customer validation, regulatory compliance (CE, FCC, UL)
  8. Production & Maintenance: DFM review, production testing, OTA updates, EOL planning

Conclusion & Next Steps

Industry-level embedded systems demand knowledge beyond coding. Functional safety ensures your sensor systems won't cause harm, embedded Linux opens up advanced processing capabilities, DSP enables real-time signal analysis, FPGAs provide hardware-level parallelism, and understanding the product lifecycle guides development from concept through production and maintenance.

Key Takeaways:
  • ASIL D (automotive) and SIL 3 (industrial) require the most rigorous safety processes
  • Embedded Linux needs an MPU with MMU — use RTOS for MCU-class devices
  • FIR filters are stable and linear-phase; IIR filters are more efficient but can be unstable
  • FPGAs excel at parallel, low-latency I/O processing that MCUs cannot handle
  • The V-model ensures traceability from requirements through testing

In Part 13, we build Real-World Projects — 8 hands-on projects from beginner weather stations to advanced drone flight controllers.