Hands-On: Switch & VLAN Configuration - Automotive Ethernet

Lab Setup

Component	Options
Switch	NXP SJA1110 EVB, Marvell 88Q5072 EVB, or Linux bridge with ip/brctl
ECU simulators	Linux VMs on VLANs; or real ECUs if available
Config tool	AUTOSAR EthSwt API; or direct SPI via Python (SJA1110); or Linux ip commands
Verification	Wireshark on trunk port; tcpdump on each VLAN interface; ping between ECU IPs

Exercise 1: Linux Bridge VLAN Configuration

Bashvlan_config.sh

#!/bin/bash
# Linux bridge: simulate automotive switch VLAN configuration
# Interfaces: eth1=port0(camera), eth2=port1(radar), eth3=port2(engine), eth4=trunk

ip link add name br0 type bridge vlan_filtering 1
ip link set br0 up

# Add ports to bridge
for iface in eth1 eth2 eth3 eth4; do
    ip link set $iface master br0 up
done

# Port 0 (eth1): camera → ADAS VLAN 10, access (untagged ingress/egress)
bridge vlan add dev eth1 vid 10 pvid untagged
bridge vlan del dev eth1 vid 1  # remove default VLAN 1

# Port 1 (eth2): radar → ADAS VLAN 10, access
bridge vlan add dev eth2 vid 10 pvid untagged
bridge vlan del dev eth2 vid 1

# Port 2 (eth3): engine ECU → Powertrain VLAN 20, access
bridge vlan add dev eth3 vid 20 pvid untagged
bridge vlan del dev eth3 vid 1

# Port 3 (eth4): trunk — carries VLANs 10, 20, 30 tagged
bridge vlan add dev eth4 vid 10
bridge vlan add dev eth4 vid 20
bridge vlan add dev eth4 vid 30

# Create VLAN interfaces on the bridge (for IP reachability)
ip link add link br0 name br0.10 type vlan id 10
ip link add link br0 name br0.20 type vlan id 20
ip addr add 169.254.10.1/24 dev br0.10
ip addr add 169.254.20.1/24 dev br0.20
ip link set br0.10 up; ip link set br0.20 up

# Verify
bridge vlan show
echo "VLAN config complete. Test: ping 169.254.10.100 from camera VLAN interface"

Exercise 3: Static FDB Entries for Safety Streams

Bashstatic_fdb.sh

#!/bin/bash
# Add static FDB entries: safety-critical ECUs never age out
# This ensures safety streams are never flooded during transient topology changes

# Static entry: brake controller MAC on port 0, VLAN 10
# MAC 00:1A:2B:3C:4D:01 → always forward to eth1 (port 0) — never ageable
bridge fdb add 00:1a:2b:3c:4d:01 dev eth1 master static vlan 10

# Static entry: steering ECU MAC on port 1, VLAN 10
bridge fdb add 00:1a:2b:3c:4d:02 dev eth2 master static vlan 10

# Verify static entries (they have 'static' flag, no ageing timer)
bridge fdb show | grep static

# For NXP SJA1110 hardware switch (via AUTOSAR EthSwt API):
# EthSwt_WriteFdbEntry(MAC, VLAN_ID, PORT_MASK, is_static=TRUE);

# Check that dynamic entries are limited to non-safety ECUs:
bridge fdb show | grep -v static | grep -v "ff:ff:ff:ff:ff:ff"

Summary

VLAN configuration must be validated by confirming traffic isolation: a ping from a camera ECU (VLAN 10) to an engine ECU (VLAN 20) should fail unless it is explicitly routed by the gateway. Static FDB entries for safety-critical ECU MACs are a mandatory configuration for production systems: a topology change that triggers FDB flush will temporarily flood those frames to all ports, which wastes bandwidth and potentially exposes safety-critical data to unintended receivers. Static entries with is_static=TRUE are immune to flush events.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.