Engineering workspace for
BMW software traceability.

Trace software lineage

Starting from any SGBM ID, follow the dependency chain: which SWFK this flash image belongs to, which BTLD it requires, which I-Steps carry it, and which vehicles have it as a Logistische Verwendung (part).

Validate ECU relationships

Check which ECU groups share the same SWFL or BTLD, but use different SWFKs — a common scenario when the same flash image runs on hardware variants with different encryption keys.

Inspect coding conditions

Understand the Einsatzbedingungen (activation conditions) for any component — series restrictions, SA option gates, market/region locks — and decode the raw Boolean expression that the vehicle type checker evaluates.

Compare I-Step changes

See which software versions are present in a specific I-Step level and how they changed between levels — critical for vehicle updates and compatibility analysis.

Assess mapping impact

Understand which CAFDs (coding files) reference a given SWFL, and conversely which SWFLs a CAFD depends on — before pushing a coding job to a vehicle.

Visualize as a graph

Render any SGBM and its connected components as an interactive node graph — pan, zoom, and inspect edge relationships visually across SWFL, SWFK, BTLD, HWAP and ECU nodes.

Example 1 — SWFL → SWFK for DME

A SWFL (flash image) for a DME engine control unit is paired to a specific SWFK (flash key). The key must match the ECU's hardware revision. ECU Relationship Intelligence shows which SWFK a given SWFL requires, and which other SWFLs share that same SWFK.

Example 2 — SWFL → BTLD

Before a flash image can be written, the ECU's bootloader (BTLD) must be compatible. A SWFL references the BTLD it was compiled for. Flashing with a mismatched BTLD can brick the ECU. This tool shows the BTLD relationship for any SWFL.

Example 3 — FSC → SWFL

Feature Software Codes (FSCs) — the license keys that unlock optional functions — reference the SWFLs they activate. By mapping FSC → SWFL relationships, you can identify which software packages a given feature code targets, and whether the vehicle's current SWFL version is eligible.

Example 4 — Same BTLD, different SWFK

Two HWEL variants for the same ECU may share the same BTLD (bootloader is hardware-neutral) but use different SWFKs (flash keys are revision-specific). This is visible in the Related Components section: both HWELs appear as related nodes, sharing the BTLD edge but diverging at the SWFK node.

VERSION column

The three-part software version number (major.minor.patch). For SWFL components this matches the engineering version. For CAFD files it corresponds to the coding data revision.

FILENAME

The reference filename for this version — {type}_{id}.bin.{version} for flash images, or similar patterns for other types. Used as the unique identifier when referencing a specific version.

FLASHBAR / LÖSCHBAR

Flashbar (can be programmed) and Löschbar (can be erased) flags per version. A ✓ in both is the normal state for current SWFLs. Older versions may lose the Flashbar flag when superseded.

ECU Name component

The ECU name follows BMW's internal SGBD naming convention: {SYSTEM}-{VARIANT}-{BUS_POSITION}.

In the example HU-MGU_01-HU:
• HU = Head Unit subsystem
• MGU_01 = Media Gateway Unit variant 01
• HU = Head Unit bus segment

This identifies the logical ECU within the vehicle network topology.

Bus Address (0xADDR)

The hexadecimal UDS diagnostic address used to communicate with this ECU.

0x63 = decimal 99, the addressing byte used when sending diagnostic requests to the Head Unit.

This address comes from the HWEL record for this ECU variant. Multiple HWEL records for the same logical ECU (different hardware revisions) typically share the same address.

Part ID structure

The part ID encodes the BMW logistics hierarchy:
• First segment: subsystem code (e.g. HU-MGU = Head Unit Media Gateway)
• Variant number: 01 = first variant
• Description: equipment or hardware variant name (e.g. HIGH_CHN_B317 = High-spec China build BxX7)

This tells you exactly which vehicle equipment variant receives this SGBM.

Market / Region code

The code in brackets is the market identifier:
• BVI = Baureihenvariant Inland (domestic / standard market)
• ANL = Anlauf (production start / ramp-up version)
• ZUS = Zusatzausstattung (additional equipment)

Market codes determine which logistics regions receive this part — important for understanding regional software variants.

SERIES

BMW vehicle series codes such as F91, G01, G20 or S15A for which this component is valid.

I-STUFE

Specific I-Step levels required for the component. In many cases the value is None, meaning the component is valid for all I-Steps inside the allowed series range.

MODEL / TYPE

Vehicle model and type codes. This often mirrors the SERIES field but uses the BMW type table identifier instead of the BRV or platform label.

SA OPTIONS (REQUIRED)

Equipment and feature codes that must be present in the vehicle order. These are shown as green badges such as S609, S6AC, and S6CP.

SA OPTIONS (EXCLUDED)

Equipment codes that must not be present. These appear as amber or orange badges. If the vehicle has any excluded option, the component is filtered out.

MARKET / REGION

Geographic restrictions such as ECE (European Economic Area) or US (United States market), limiting where the component may be programmed or coded.

Why CAFDs link here

A CAFD is tightly bound to the software version it was designed to configure. If the SWFL version changes, the CAFD may become incompatible. This section answers a critical workshop question: if I update this SWFL, which coding files are affected?

What to review

Use the mapped CAFD list to confirm whether coding data, vehicle options, and software revisions still align after a programming change. It is the fastest way to spot downstream coding dependencies before touching the car.

ECU

The ECU identifier itself. It is clickable and reloads the current panel, which is useful when you want to re-anchor the breadcrumb or copy the exact ECU name.

DIAG ADDRESS

0x63 — the UDS diagnostic address used to communicate with this ECU.

SERIES

S18A in this example — the platform or BRV to which this ECU instance applies.

I-STUFE RANGE

The lifecycle span in which this ECU/series combination is present, for example S18A-18-07-500 … S18A-19-03-537. This shows the release window of the ECU for that series.

COMPONENTS

The total number of SGBM components of any type associated with this ECU node — flash images, bootloaders, coding files, hardware records and more.

PSDZ Image N/N

The indicator such as PSDZ Image 2/2 tells you which image slot you are viewing. Multi-image ECUs may carry separate application partitions, modem firmware, or region-specific payloads under the same ECU.

Related BTLD / HWEL

The Related BTLD chip shows the required bootloader, for example 00003F36. Related HWEL shows the targeted hardware element. A value of None means the SWFL applies across all hardware variants of that ECU.

BRV filter

Choose a vehicle series like F020 (5 Series), G01 (X3), or G20 (3 Series). This determines which platform's release history is shown.

Search bar

Filter I-Step levels by text. For example, searching F020-26 isolates all March 2026 levels for the F020 platform.

SGBMs table

The table lists each changed component with TYPE, SGBM ID, DESCRIPTION, and VERSIONS. Clicking any row opens that SGBM in Software Lineage. Typical ATM examples include BTLD 000026A2, SWFL 000026A3 Flashloader NAD, 000026A4 APPL CAN, 000026A5 SYS MAIN, and 000026A6 APPL MAIN.

Typical multi-image ECU structure

APPL CAN, SYS MAIN, and APPL MAIN illustrate the split software architecture common in telematics ECUs like the ATM (Advanced Telematics Module), where separate application partitions and modem firmware are versioned independently.

Core fields

ECU: ATM-01-ATM
DIAG ADDRESS: 0x61
SERIES: F020
I-STUFE RANGE: F020-14-11-500 … F020-17-03-503

What ATM means

ATM stands for Advanced Telematics Module — the connected-services and SIM module. Address 0x61 is the dedicated UDS address for the telematics unit, and the I-Step range shows its full lifespan in the F020 platform.

Name

DME-841-DME-BASIS decodes as DME (Digital Motor Electronics), 841 (variant number), DME (system), and BASIS (base variant).

Teilcharakter: BVI

ECU Node

DME-841-DME (0x12) — Digitale Motor Elektronik B48 für LK. This is the engine control unit for the B48 engine in this application context, with UDS address 0x12.

I-Stufe: first appearance such as F020-15-11-501.

Group header

g_mmi, address 0x63, 14 variants, and 1834 total fault codes.

g_mmi stands for Großes Multimedia Infotainment — the SGBD family for the main infotainment and head-unit ECU at address 0x63. It spans multiple generations from early CIC and NBT hardware through today's MGU variants.

Fault Codes table

Each row shows the decimal CODE, an SAE code where available, a human-readable DESCRIPTION, and a WEIGHT. Weight indicates severity or priority in ISTA diagnostic flows — higher values are more critical.

Typical examples

156416 = CHAMP transport mode active (weight 100); 156592 and 156593 = component anti-theft protection (weight 75); 156424 to 156428 = common HU-B coding errors (weight 50).

Result example

DTC 2630A corresponds to decimal code 156426.

English: HU-B: Coding data not enabled
Deutsch: HU-B: Kodierdaten nicht freigegeben
Português: HU-B: dados de codificação não validados
Français: HU-B: données de codage non autorisées
Español: HU-B: Datos de codificación no autorizados

ECU Variants section

The ECU Variants block shows every SGBD variant where the fault code exists, including families like HU-B, HEADUNIT HIGH, HEADUNIT BASIS, and AUDIO SYSTEM. Typical variants include entrynav, nbtevo, hu_mgu, enavevo, bis01, and x_ap20. The same numeric code can carry a different description depending on the ECU variant.

What you can search for

• SGBM IDs — full or partial (e.g. 00003DD, 56EA)
• ECU names (e.g. HU-MGU, ATM-01)
• I-Step identifiers (e.g. F020-26)
• Logistic mapping names (e.g. DME-841)
• Description text (e.g. Bootloader, B58)
• Engine/ECU codes (e.g. B58TUE1, MG1)

Result types returned

• SGBM All SGBM types (SWFL, HWAP, BTLD…)
• ECU ECU node matches by name
• I-Step I-Step level identifier matches
• Mapping Logistic reference matches

Clicking any result opens the full detail panel for that item — same panel as if you had navigated to it directly from the dedicated tab.

Node colors (legend)

Node size meaning

Node size is proportional to connection count — the more components a node links to, the larger its circle. This makes shared infrastructure immediately visible:

• A large BTLD node means that bootloader is shared across many SWFLs — typical for platform-wide bootloaders
• A large SWFK node means many flash images use the same encryption key — relevant for hardware families
• A small isolated node is a component with very few connections — potentially a variant-specific or deprecated component

☑ Type

Shows the SGBM type prefix on each node — SWFL, SWFK, BTLD, HWAP, CAFD, HWEL, ECU, SWT. Useful for quickly identifying component categories without reading the ID.

☑ ID

Shows the 8-digit SGBM identifier or ECU name on each node. On by default. Disable to reduce label clutter when the graph has many nodes (30+).

☑ Description

Shows the human-readable description alongside the ID — e.g. "IDC 23 HIGH B429", "Bootloader", "FFP_LOCA_1". Most useful for identifying functional purpose at a glance. Can be toggled off for dense graphs.