Open BMW E-Sys for the first time and you will meet a small army of abbreviations: FA, VO, FDL, CAFD, TAL and SVT.

They may look like random file names, but each one has a specific role. Some describe how the car was built, others hold ECU settings, and a few are used when calculating or performing a software flash.

Here is the short version:

• FA/VO describes the vehicle and its installed equipment.
• FDL refers to individual coding parameters.
• CAFD contains the coding structure for an ECU.
• SVT lists the vehicle’s control units and software.
• TAL is the action plan used during programming or flashing.

These items work together, but they are not interchangeable. Understanding the difference is essential before coding a feature, adding a retrofit or updating a BMW control unit.

Quick BMW Coding File Comparison

TermBasic MeaningMain PurposeFAFahrzeugauftragStores the vehicle’s build and option informationVOVehicle OrderEnglish name commonly used for the FAFDLFunction Data LineRepresents individual ECU coding parametersCAFDCoding Application FileDefines the coding data available for an ECUSVTECU/software inventoryShows installed modules and their software componentsTALTechnical Action ListTells the software which programming actions to perform

The exact labels and available functions can vary by E-Sys and PSdZData version, vehicle platform and software integration level.

What Is a BMW FA File?

FA stands for Fahrzeugauftrag, a German term generally translated as Vehicle Order.

The FA is the car’s electronic build specification. It describes what type of BMW the vehicle is, when it was built and which factory options or equipment codes belong to it.

BMW introduced the Vehicle Order structure as a replacement for the older Central Coding Key, known as ZCS. BMW training material describes the VO/FA as a list of vehicle-specific data and option codes used to configure replacement or additional modules correctly. (BMWGROUP)

A BMW FA can include information such as:

• Vehicle series
• Model designation
• Production date
• Type code
• Market or country version
• Paint and upholstery information
• Factory option codes
• Retrofit option entries
• Vehicle-related coding data

In simple terms, the FA tells the coding software:

“This is the vehicle, and this is the equipment it is supposed to have.”

What Are SALAPA Codes?

Inside the FA, you will often see SALAPA elements. These are BMW option codes used to identify installed equipment.

Examples may represent items such as:

• Navigation systems
• Lighting packages
• Parking sensors
• Heated seats
• Bluetooth equipment
• Driver-assistance features
• Audio systems
• Market-specific equipment

During a retrofit, a technician may add or remove an appropriate option code from the FA and then VO-code the affected control modules.

Editing the FA alone does not complete a retrofit. The required hardware, wiring, compatible ECUs and correct software must also be present.

Are FA and VO the Same Thing?

In most BMW coding conversations, FA and VO refer to the same vehicle-order data.

FA is the German abbreviation used in BMW software, while VO is the English term. This is why one guide may say “read the FA” while another says “save the VO.”

You may also hear expressions such as:

• FA coding
• VO coding
• FA/VO coding
• Vehicle Order coding

These usually describe the same general method: configuring a control module according to the vehicle’s official build specification.

What Is BMW VO Coding?

VO coding writes factory-style configuration settings to an ECU based on the active FA.

Rather than changing individual parameters one at a time, E-Sys reads the vehicle order and applies the appropriate configuration to the selected module.

VO coding is commonly used when:

• Installing a compatible replacement ECU
• Completing a retrofit
• Restoring factory coding
• Removing unwanted custom coding
• Configuring modules after programming
• Updating the vehicle’s equipment specification

For example, imagine that compatible factory hardware has been installed for a retrofit. The correct option code may be added to the FA before the related modules are VO-coded. Those modules then receive configuration values that match the revised vehicle order.

Does VO Coding Update ECU Firmware?

No. VO coding normally changes the ECU’s configuration, not its operating software.

That distinction matters:

• VO coding: applies settings based on the FA.
• FDL coding: changes selected parameters.
• Flashing: installs firmware or other software components.

VO coding can reset previous FDL changes in the selected module because it reapplies configuration derived from the vehicle order.

What Is BMW FDL Coding?

FDL coding changes individual parameters inside a control unit’s coding data.

FDL is commonly expanded as Function Data Line. It is the detailed, parameter-level side of BMW coding.

Instead of telling an ECU to configure itself from the complete vehicle order, FDL coding allows a supported value to be changed directly.

Depending on the vehicle and module, FDL coding may adjust settings related to:

• Lighting behavior
• Mirror operation
• Locking confirmation
• Welcome lights
• Instrument-cluster displays
• Auto start-stop behavior
• Comfort opening and closing
• iDrive options
• Warning messages
• Audio settings

VO Coding vs. FDL Coding

Here is the practical difference:

VO coding says:

“Configure this module for the equipment listed in the FA.”

FDL coding says:

“Change this particular setting inside the module.”

VO coding is useful for factory-style configuration and retrofits. FDL coding is generally used for precise personalization.

Can FDL Coding Add Missing Hardware?

No. FDL coding can only change functions supported by the vehicle’s hardware, ECU software and network configuration.

Changing a parameter cannot install a missing camera, amplifier, antenna, radar sensor or electric mirror motor. Coding is clever, but it has yet to master online shopping and a socket set.

What Is a BMW CAFD File?

CAFD is the coding application data associated with a BMW control unit.

It defines the coding structure used to configure that ECU. When coding data is read through E-Sys, the CAFD entry provides the framework containing the ECU’s available parameters and values.

A simplified way to understand it is:

• The ECU is the physical control module.
• The CAFD defines how that module can be configured.
• The FDL data contains the individual coding values within that structure.

Why Does a CAFD Appear Under an ECU?

In the E-Sys ECU tree, a control unit may show one or more software-related entries beneath it. The CAFD entry identifies its coding application data.

Reading the coding data allows the relevant CAFD structure to be viewed and, where supported, edited at the FDL level.

What Does “Missing CAFD” Mean?

A missing CAFD usually means the ECU does not currently show valid coding application data in the expected place.

Possible reasons include:

• The module was replaced
• Programming was interrupted
• Coding data is damaged
• The ECU has not been correctly initialized
• The installed software and PSdZData do not match
• The wrong target vehicle or connection was selected
• The module requires further diagnosis or programming

E-Sys may provide a function often described as Detect CAF for SWE, which attempts to identify compatible coding application data for the ECU’s installed software.

That is not a button to select at random. Assigning an unsuitable CAFD or coding the wrong ECU can leave a module incorrectly configured or unable to communicate properly.

What Is a BMW SVT File?

SVT represents the vehicle’s ECU and software inventory.

It shows which control units E-Sys sees and which software components are associated with them.

An SVT can contain entries representing items such as:

• ECU identifiers
• Bootloader software
• Application software
• Coding application data
• Calibration data
• Software versions
• Hardware-related information

Think of the SVT as a detailed map of the BMW’s electronic control-unit network.

SVT Actual vs. SVT Target

Two SVT terms are particularly important during BMW programming.

SVT Actual

The SVT Actual, often shown as SVT Ist, represents the current state of the vehicle.

It answers questions such as:

• Which ECUs are installed?
• Which software components are present?
• What versions are currently detected?
• Which CAFD entries belong to each control unit?

SVT Target

The SVT Target, also called SVT Soll, describes the intended state after a calculated programming operation.

It may show:

• Software components that should be updated
• New target versions
• Components that should be added or replaced
• Changes needed to reach the selected integration level

The actual and target SVTs are compared when preparing a programming plan.

Why Save the SVT?

Saving the original SVT creates a useful record of the vehicle’s ECU and software state before work begins.

It can help with:

• Checking the original software inventory
• Investigating a failed programming session
• Confirming module changes
• Comparing software versions
• Planning recovery work

An SVT backup is valuable, but it is not a complete rescue solution by itself. A failed flash may still require proper BMW programming equipment, compatible software and specialist recovery knowledge.

What Is a BMW TAL File?

TAL stands for Technical Action List.

A TAL is the calculated plan that tells E-Sys which programming actions are required to move the vehicle from its current software state to the target state.

If the SVT shows what is installed and what should be installed, the TAL explains what must happen between those two points.

Depending on the job, a TAL may include actions involving:

• Bootloader deployment
• Application-software deployment
• Coding-data deployment
• Software activation
• ECU programming
• Module updates
• Component changes

Does a TAL Contain the ECU Software?

Not in the simple sense of being the firmware package itself.

The TAL is better understood as an instruction list. It identifies the technical actions and software components involved in the programming plan. E-Sys then uses the required data from the appropriate programming-data package.

Why Is TAL Processing Risky?

TAL processing may write software directly to one or more control units. If communication or power is interrupted, an ECU may stop responding.

Before a programming session, technicians normally check:

• Vehicle battery condition
• Regulated power-supply capacity
• Network stability
• Laptop power
• E-Sys and PSdZData compatibility
• Correct target chassis
• Current and target integration levels
• Saved FA and SVT data
• The calculated TAL
• The possibility of ECU recovery

BMW’s current technical requirements specify a stable wired network for vehicle programming and note that the IP address must remain unchanged during the session. (BMWGROUP)

How FA, CAFD, FDL, SVT and TAL Work Together

The easiest way to understand these terms is to follow a typical workflow.

For Basic FDL Coding

1. Connect E-Sys to the vehicle.
2. Read and activate the FA.
3. Read the ECU or SVT information.
4. Select the required ECU.
5. Read its coding data.
6. Open the associated CAFD.
7. Change the required FDL parameter.
8. Write the edited coding data back to the ECU.

In this example:

• FA identifies the vehicle.
• SVT shows the installed ECU.
• CAFD provides the coding structure.
• FDL is the parameter being changed.
• TAL is normally unnecessary for a basic coding change.

For VO Coding

1. Read and save the original FA.
2. Edit the FA when a valid retrofit requires it.
3. Calculate the FA and check it for errors.
4. Activate the revised FA.
5. Read the vehicle’s ECU information.
6. VO-code the affected modules.

Here, the active FA provides the factory-style configuration used for the selected ECUs.

For ECU Programming or Flashing

1. Read and save the FA.
2. Read and save the SVT Actual.
3. Select the correct target integration level.
4. Calculate the SVT Target.
5. Compare the actual and target software states.
6. Calculate the TAL.
7. Review every planned action.
8. Connect regulated programming power.
9. Execute TAL processing.
10. Code, initialize and test affected modules as required.

Programming is far more invasive than changing a single FDL value. BMW’s technical portal provides official diagnostic and programming resources, while access requirements and supported software can vary by vehicle generation and region. (BMWGROUP)

Which Files Should You Back Up?

Before making BMW coding or programming changes, save at least:

• The original FA
• The original SVT
• Original ECU coding data where available
• Relevant CAFD or FDL exports
• Current integration-level information
• Screenshots or notes showing every manual change
• The TAL and target SVT for a planned flash

Use clear file names containing the vehicle, date and whether the file is original or modified.

Avoid posting unedited FA or diagnostic files publicly. They may contain a full VIN or other vehicle-specific information.

Common BMW File Mistakes

Editing the FA Without Saving the Original

Always preserve an untouched copy. Without it, returning the car to its previous vehicle order becomes more difficult.

Coding the Wrong ECU

Several module names can look similar. Confirm the ECU address and function before writing data.

Using Incompatible PSdZData

Outdated or mismatched data can prevent CAFD detection, TAL calculation or successful programming.

Treating VO and FDL Coding as the Same Thing

FDL coding changes selected parameters. VO coding may rewrite the full module configuration and remove previous custom changes.

Running TAL Processing Without Power Support

A healthy battery alone is not always enough for a long programming session. Use a regulated supply designed for vehicle programming.

Flashing to Fix an Undiagnosed Fault

Programming is not a universal repair. Wiring faults, water damage, weak batteries and failed hardware should be diagnosed before software is changed.

Final Explanation

BMW’s coding terminology becomes easier once every item has a clear job:

• FA and VO describe the vehicle and its equipment.
• FDL refers to individual coding parameters.
• CAFD provides the coding structure for an ECU.
• SVT records the installed control units and software components.
• TAL lists the technical actions required for programming.

For a simple preference change, you may only work with the FA, SVT, CAFD and a selected FDL parameter. For a factory-style retrofit, the FA and VO-coding process become more important. During programming or flashing, the SVT and TAL take center stage.

The safest rule is simple: read first, save the originals, verify every selection and never start programming without stable power.

Frequently Asked Questions

Is an FA file the same as a VO file?

Yes, in most BMW coding discussions. FA is the German abbreviation for Fahrzeugauftrag, while VO means Vehicle Order.

Does FDL coding change the FA?

No. FDL coding changes selected parameters inside an ECU’s coding data. It does not normally rewrite the vehicle order.

Will VO coding remove FDL changes?

It can. VO coding reapplies settings calculated from the active FA, so custom FDL values in the selected ECU may return to factory-style defaults.

Can I copy a CAFD file from another BMW?

That is not a safe general solution. CAFD compatibility depends on the ECU, software version, vehicle integration level and programming data. Use data correctly matched to the vehicle and module.

Is a TAL needed for normal BMW coding?

Usually not. A TAL is primarily associated with programming and flashing operations. Basic VO or FDL coding generally follows a different workflow.

What is SVT Ist?

SVT Ist is the actual software and ECU inventory currently detected in the vehicle. “Ist” is German for the existing or actual state.

What is SVT Soll?

SVT Soll is the calculated target state. It represents the control-unit software configuration expected after the proposed programming work.

Can incorrect TAL processing damage an ECU?

Yes. An incorrect plan, incompatible software, unstable power or interrupted communication can leave one or more modules unresponsive. TAL processing should only be carried out after the full plan has been reviewed carefully.