E-Sys Manual PDF

Fahrzeugprogrammierung
Manual
Manual
Programming ECUs with E-Sys
Project: Fahrzeugprogrammierung
Authors: Wolfgang Schühle, ESG
Tobias Thiemann, ESG
Version: 10.0
Valid as of: E-Sys 3.32.0
Date: 19.02.2018
Manual: Programming ECUs with E-Sys 19.02.2018
Contents
1) Introduction 4
1.1 Change documentation 4
1.2 Confidentiality 5
1.3 Purpose 5
1.4 References 6
1.5 Abbreviations 6
1.6 Table of figures 8
2) Basics 10
2.1 Programming flow 10
2.2 Settings 10
2.2.1 Program 11
2.2.2 System data / fingerprint 12
2.2.3 FSC/CERT 13
2.2.4 Options 14
2.2.5 Connections 16
2.2.6 External Applications 18
2.2.7 Authentication 19
2.2.8 ODX 20
3) Creating a PDX component container 21

3.1 Loading the PDX template 21
3.2 Assignment of main series 21
3.3 Adding ECU software 22
3.4 Adding BLUP/FLUP files and BLUMap 23
3.5 Adding user documentation 26
3.6 Setting the programming order 27
3.7 Saving the container 29
3.8 ODX-Checker 30
3.9 Importing the component container into PSdZ 31
3.10 Updating containers 32
4) Creating a TAL 33
4.1 Manual creation in the TAL-Editor 33
4.2 Automatic TAL calculation 36
4.3 Definition of a TAL-Filter 37
4.4 Creating a TAL in the PDX-Charger 39
4.5 Creating a TAL with BLUP/FLUP 40
Page 2 of 65
4.5.1 Automatic calculation in the comfort mode 40

4.5.2 Automatic calculation in the PDX-Charger 40
4.5.3 Manual creation of a TAL with BLUP/FLUP 40
5) Connecting 45
5.1 Choosing a TargetSelector 46
5.1.1 Connecting via gateway 46
5.1.2 Direct connection 46
5.2 Choosing the physical interface 47
5.2.1 Connecting via Ethernet 47
Connecting via gateway URL 47
Connecting via vehicle identification number (VIN) 48
5.2.2 Connecting via ICOM 48
Connecting via ICOM/D-CAN 48
Connecting via ICOM/Ethernet 48
5.2.3 Connecting via CANCard and CANCase 49
5.2.4 Connecting via OMITEC 50
5.2.5 Connecting via radio interface 51
5.3 Choosing vehicle-specific parameters 51
5.4 Connection test 52
6) Executing a TAL 53
6.1 Selecting ECUs and transaction classes 54
6.2 Parameters for TAL the execution 55
6.3 Logging during the TAL-Execution 57
7) Special features for L4-ECUs 58

7.1 Mapping 58
7.2 AIFContents 59
8) Recovering individual data 60

8.1 IDBackup 60
Automatic TAL calculation 60
Manual creation 60
Reading and saving individual data 62
8.2 IDRestore 63
Automatic TAL calculation 63
Manual creation 63
Restore individual data 65
Page 3 of 65
1) Introduction
1.1 Change documentation

Version Date Description Author
0.1 07.12.06 Creation of document Wolfgang Schühle, ESG
1.0 11.01.07 Document completely reworked Tobias Thiemann, ESG, ES-71
1.1 02.02.07 Description of component name in section 3.4 added Tobias Thiemann, ESG, ES-71
1.2 04.05.07 Chapter 7 “Special features for L4-ECUs” added Tobias Thiemann, ESG, ES-71
Adaptation to E-Sys 3.0

2.0 22.05.07 Tobias Thiemann, ESG, ES-71
Chapters 2, 5 and 6 reworked
Chapter 4 restructured
Sections 4.2 and 4.3 added

3.0 11.09.07 Section 3.4 added Tobias Thiemann, ESG, ES-71
Sections 4.3 and 5.2.1 reworked
3.1 13.12.07 Minor adaptations to E-Sys 3.3.1 Tobias Thiemann, ESG, ES-71

Section 3.4 completely reworked

5.0 25.03.08 Tobias Thiemann, ESG, FZ-620
Section 2.2 added

5.1 23.04.08 Section 3.6 added Tobias Thiemann, ESG, FZ-620
Section 4.3 reworked
5.2 12.06.08 Adaptation to E-Sys 3.6 Tobias Thiemann, ESG, FZ-620

Section 4.4 added
License note added in section 3.8

5.5 04.11.08 Tobias Thiemann, ESG, FZ-620
Layout of info boxes altered
5.6 10.12.08 Chapter 8 added Tobias Thiemann, ESG, FZ-242

6.0 05.06.09 Section 2.2 updated Tobias Thiemann, ESG, FZ-242
Chapter 5 reworked due to omission of B2V

6.1 18.11.09 Screenshots updated Tobias Thiemann, ESG
Section 5.2.2 updated
Section 2.2.5 updated

6.2 22.04.10 Tobias Thiemann, ESG
Chapter 5 updated, section 5.2.2 “Connecting via ICOM” added
6.3 30.04.10 Warning in section 3.5 added Tobias Thiemann, ESG
6.4 01.06.10 Warning in section 4.3 added Tobias Thiemann, ESG
Page 4 of 65
Adaption to E-Sys 3.15

Section 2.2.6 updated due to omission of SWE-Generator
7.0 07.10.10 Section 3.11 added Tobias Thiemann, ESG
Chapter 4 reworked
Chapter 6 reworked, sections 6.1 and 6.2 added

8.0 12.04.12 Section 5.3 reworked Tobias Thiemann, ESG
General rework and adaption to E-Sys 3.30.1

9.0 Constantin Lehnhoff, ESG
Replacement of old screenshots (all sections)

Replacement of old screenshots (all sections)
Changed some text sections
Section 2.2.x reworked
Philipp Horn, ESG
10.0 21.11.17 Section 4.2 reworked
Andreas Poppek, ESG
Section 5.1.2 reworked
Section 6 reworked
1.2 Confidentiality
The present manual is only for the insight of persons participating directly to the project. Any forwarding of
this documentation, in particular to contract partners outside of the BMW Group, must be agreed with the
appropriate responsible project leader and must comply with the regulations and specifications of the
confidentiality agreement of the development contract.
1.3 Purpose
This document describes the process of programming ECUs with E-Sys. It is assumed, that valid software
units (SWEn) have already been created with the SWE-Generator. The handling of the SWE-Generator is
described in [SWEGEN].
Page 5 of 65
1.4 References
Reference Version Date Description Author
[SWEGEN] 1.0 28.11.2006 Handlungsanweisung SWE-Generator Patrick Wagner, ESG

Available on GIS in the folder “BMW Standard Tools
Entwicklung/ Standard Tools/ Datei-Generatoren und
Vorlagen/ SWE-Generator (L6)/ Applikation”
[LH_FP_SWL] 9 18.04.2008 LH „FP Teil 2 Softwarelogistik“, 10000967 - 000 – 09 Dr. Olaf Kluge, BMW
Available in the SAP system
[FA_GEN] 4 02.07.2009 FA-Generator Markus Wolf, BMW

Available on GIS in the folder “BMW Standard Tools
Entwicklung/ Standard Tools/ Datei-Generatoren und
Vorlagen/ FA-Generator (L6)/ Applikation”
1.5 Abbreviations
Abbreviation Description
CAF Coding Application File
CBB Certificate and Binding Box
CSR Certificate Signing Request
E-Sys New programming system for BMW ECU development
FA Fahrzeug-Auftrag (Vehicle order)
FP Fahrzeugprofil (Vehicle profile)
FSC Freischaltcode (Activation code)
GIS Global Information Server
GUI Graphical User Interface
IDR Individual Data Recovery
KIFA Development Resorts: Body and Interior Trim (Karosserie), Electrics/Electronics and
Driver Environment (Interieur), Driving Dynamics (Fahrwerk), Powertrain
(Antriebsstrang)
KIS Kompatibilitäts- und Informations-System (compatibility and information system)
LAN Local Area Network
ODX Open Diagnostic Data Exchange
PDX Packed ODX
Page 6 of 65
Abbreviation Description
PSdZ Programmiersystem der Zukunft (BMW programming core)
SC Standard Core
SG Steuergerät (ECU)
SG-ID Steuergeräte-Identifier (ECU identifier)
SGBM Steuergerätebeschreibungsmodell (ECU description model)
SGBM-ID Steuergerätebeschreibungsmodell-Identifier (ECU description model identifier)
SWLdZ Software-Logistik der Zukunft (BMW software logistics)
SREC Motorola SREC format
SVK Steuergeräte-Verbau-Kennung (software variant identification)
SVT (Ist) System variant table (actual)
SVT (Soll) System variant table (target)
SWE Softwareeinheit (software unit)
TAL Transaktionsliste (transaction list)
VCM Vehicle Configuration Management
VIN Vehicle Identification Number
Page 7 of 65
1.6 Table of figures

Figure 1: Program settings ...............................................................................................................................11
Figure 2: Settings for coding and fingerprint ....................................................................................................12
Figure 3: Settings for FSC and certificate management ..................................................................................13
Figure 4: Further options ..................................................................................................................................15
Figure 5: Connection settings ...........................................................................................................................17
Figure 6: Settings for external applications ......................................................................................................18
Figure 7: Settings for the developer soft token (EST) ......................................................................................19
Figure 8: Settings for ODX-Checker rules ........................................................................................................20
Figure 9: Main series for a PDX container .......................................................................................................21
Figure 10: PDX-Charger with loaded PDX template ........................................................................................22
Figure 11: Adding a BLUP to a component container ......................................................................................23
Figure 12: Adding a BLUMap to the container .................................................................................................24
Figure 13: BLUMap displayed in the PDX-Charger .........................................................................................25
Figure 14: Adding user documentation to the container ..................................................................................26
Figure 15: User documentation displayed in the container ..............................................................................27
Figure 16: Loaded SWESEQ file in the SWESEQ-Editor ................................................................................28
Figure 17: Report after ODX check ..................................................................................................................30
Figure 18: File-Explorer view after ODX data import .......................................................................................31
Figure 19: Updating the PDX container ............................................................................................................32
Figure 20: Adding a new transaction ................................................................................................................34
Figure 21: TAL-Editor view with loaded TAL ....................................................................................................35
Figure 22: Calculating a TAL from SVTactual and SVTtarget ..........................................................................37
Figure 23: Loaded TAL filter in the TALFILTER-Editor ....................................................................................38
Figure 24: Creating a TAL/SVT from an ECU variant ......................................................................................39
Figure 25: Adding a BlFlash transaction to the TAL .........................................................................................41
Figure 26: Deleting the default BLFlashTA entry .............................................................................................42
Figure 27: Adding a BLFlashTA based on a file ...............................................................................................43
Figure 28: TAL-Line with BLUP transaction .....................................................................................................44
Figure 29: Connection button ...........................................................................................................................45
Figure 30: Connection dialogue .......................................................................................................................45
Figure 31: Valid TargetSelectors for a gateway connection .............................................................................46
Figure 32: Valid TargetSelectors for a direct ECU connection .........................................................................47
Figure 33: Connecting via gateway URL ..........................................................................................................47
Figure 34: Connecting via VIN .........................................................................................................................48
Figure 35: Connecting via ICOM/D-CAN ..........................................................................................................48
Figure 36: Connecting via ICOM/Ethernet .......................................................................................................49
Figure 37: Example assignment of „ProDiaS-CAN-Driver CAN 1“ to channel 1 of CANcaseXL .....................49
Figure 38: Connecting directly via FA-CAN......................................................................................................50
Page 8 of 65
Figure 39: Connecting via OMITEC interface...................................................................................................51

Figure 40: Connecting via radio interface .........................................................................................................51
Figure 41: Vehicle-specific parameters ............................................................................................................51
Figure 42: Read SVT_actual from ECUs .........................................................................................................52
Figure 43: General controls in the TAL execution module ...............................................................................53
Figure 44: Checkbox matrix for choosing transactions ....................................................................................54
Figure 45: Parameters for the TAL execution ..................................................................................................56
Figure 46:Log windows during the TAL execution ...........................................................................................57
Figure 47: Container with mapping files for AMP_TOP and MULF_Basis .......................................................58
Figure 48: TAL with AIContents for MULF_Basis ............................................................................................59
Figure 49: SVTactual and SVTtarget with different HWEL ..............................................................................60
Figure 50: TAL with IDR transactions in the TAL-Editor ..................................................................................61
Figure 51: Backup files after IDR classic (left), IDR light (middle) and IDR with PIA Client (right) ..................62
Figure 52: TAL calculation settings for IDRestore ............................................................................................63
Figure 53: TAL for IDRestore (IDR light) ..........................................................................................................64
Figure 54: TAL for IDRestore (IDR classic & PIA client) ..................................................................................65
Page 9 of 65
2) Basics
2.1 Programming flow

The following steps are necessary to program an ECU with E-Sys:
1) Creating a PDX component container
a) Loading a PDX template
b) Creating ECU variants and adding ECU software (bootloader, application, coding data) in the shape
of software units (SWEn)
c) Adding configuration files (mapping, sequence, …)
d) Saving the component container
2) Importing the component container into PSdZ.
3) Creating a transaction list (TAL) that defines the actions to be performed by the programming system
4) Connecting to the ECU
5) Executing the TAL (programming the software image to the ECU)
Accomplishing these steps is the subject of this document.
2.2 Settings
All program and user settings can be modified in the menu „Options  Settings“. System specific information
will be saved in the file
▪ <E-Sys_installation>\config\Esys.properties.
User specific settings will be saved in
▪ C:\Documents and Settings\<login>\Esys\EsysUser.properties.
The settings will be described in the following sections.
Page 10 of 65
2.2.1 Program
Global settings are specified in the tab „Program“ (cf.Figure 1), the following settings can be made:
▪ „Directories“: Defines the path for the data folder in which E-Sys data will be stored. This folder will
be referred to as <E-Sys_data> in the following sections of this document. The folder <E-
Sys_data>/psdzdata is the location where ODX data is stored.
▪ „Language“: Switches the E-Sys GUI from German to English and vice versa.
▪ „Logging“: Sets the log level for E-Sys. Log files are automatically created in the folder <E-
Sys_data>/Logs at system start with the name pattern
E-Sys_yyyymmdd_hhmmss.log (e.g. E-Sys_20090112_143821.log). Old log files can be deleted at
system start by activating the provided checkbox.
Figure 1: Program settings
Page 11 of 65
2.2.2 System data / fingerprint
Settings for programming / coding and fingerprint can be specified on the tab „System data“ (cf. Figure 2).
The fingerprint contains information about the programming system, which are written to the ECU in the
programming process. The fingerprint is composed as follows:
▪ TesterApplyIdentifier: as defined in system data settings. Selection via direct entry or via drop-
down menu possible.
▪ ProgrammingDeviceType: fixed value (0x01), not changeable.
▪ ProgrammingDeviceSerialNo: as defined in system data settings.
▪ BusPriority:
▪ Settings FingerprintID: depending on the used TesterApplyIdentifier
- PlantID:
- SystemSupplierID:
- SystemSupplier List:
- DealerID:
- FingerprintID:
A tooltip with the permitted values for each field appears when moving the cursor over the field. The “Default”
button can be used to reset all values.
Figure 2: Settings for coding and fingerprint
Page 12 of 65
2.2.3 FSC/CERT
On tab „FSC/CERT“ (cf. Figure 3) the settings for FSC (activation of additional ECU functions with a
cryptographic code) can be taken:
▪ Verify: Defines, whether an FSC is verified automatically on “Open” and “Safe” in FSC Editor.
▪ Certificate: Defines the path of the FSC certificate. If an FSC certificate is specified, it will be written
to the ECU in addition to the FSC in the functions “Write FSC” and “Upgrade FSC” in the module
“FSC” as well as in batch mode.
▪ Periodical Check: Defines, whether an additional periodical check is triggered when reading the
SWT status in the modules “FSC”, “FSC Extended” and in batch mode.
▪ Certificate management Server-URL: Here it is possible to add, delete or edit the server URLs of
CBBs for certificate management.
Figure 3: Settings for FSC and certificate management
Page 13 of 65
2.2.4 Options
The following settings can be found on the „Options“ tab (cf. Figure 4):
▪ „Show message after cancel…“: Defines whether a message dialogue is shown when cancelling
an action.
▪ „Ask for saving changes…“: Defines whether the user is prompted to save unsaved data when
leaving a module.
▪ „Update VCM after TAL execution“: Defines whether the VCM (Vehicle Configuration Module) will
be updated automatically after TAL execution. By doing this FA, FP, I-Step and SVT will be written to
the VCM module (currently in the ZGW) and FA and I-Step will be written to VCM backup module
(currently in the CAS) after TAL execution. With no CAS available VCM update will cause timeout
errors!
▪ „Show warning before TAL generation…“: Defines whether a dialogue with function constraints
will be shown when generating a TAL in the PDX-Charger.
▪ „Check software availability…“: Defines whether a check for availability of required software units
is performed before TAL execution. TAL execution will be aborted if a required software unit is not
available when this option is active..
▪ „Update MSM after TAL execution“: Defines whether the MSM (Master Security Module) will be
updated automatically after TAL execution. MSM update transfers transport keys for all CSM-ECUs
(Client Security Modules) to the MSM (currently in the ZGW) and triggers distribution to the CSMs.
All affected ECUs are determined by reading data from the VCM in advance.
▪ “Show message after connection is established”: Defines whether an info dialogue is shown
after successfully establishing a connection or not.
▪ “Show warning to close other applications at startup”: Defines whether a message to close
other applications is shown after programme start or not.
▪ “Show collapsed SVT”: Defines whether the tree structure of a SVT in the module “TAL-
Calculating” will be shown in a collapsed way or not.
▪ “Show message after finish of TAL…”: Defines whether a separate message with the status of
the TAL-Processing will be displayed after the TAL-Processing or not.
▪ “Delete list of recently…”: Defines whether the list of recently opened files will be deleted upon
each restart of the application. The list itself can be found under “File” -> ”Recent Files” in modules
like the FA-Editor or the TAL-Editor.
▪ “Read vehicle configuration (SVT) before and...”: Defines whether the SVT will be read
automatically from the vehicle before and after the TAL-Processing. Advantage of the automatic
reading is, that the respective vehicle configurations are guaranteed to be logged to the log file.
The radio buttons in the box "E-Sys mode" are to switch between the car and the motorcycle mode. The
scope of functions is adjusted specifically to the selected mode.
Page 14 of 65
Figure 4: Further options
Page 15 of 65
2.2.5 Connections
On the „Connections“ tab (cf. Figure 5) an additional timeout for all diagnostic services can be specified. This
additional timeout respects the latency caused by bus transmission. The maximum value for the „Additional
Transmission Timeout“ is 1000ms.
In addition to that special settings needed for connecting via radio and ICOM interface can be made on this
tab:
• All/global connections:
- Additional Transmission Timeout [ms]: Additional transmission time for all connections added
to the normal timeout
• Wireless connection:
- Additional Transmission Timeout [ms]: Additional transmission time for the radio connection
added to the normal timeout
- Short-VIN: The 7-digit vehicle identification number of the vehicle to be connected
- MDA Number: The MDA number of the radio interface connected to the vehicle
• ICOM connection:
- Base Port: The base port used for calculation of port-mapping URLs needed for ICOM
connections
• Http Update:
- Checkbox: Defines whether a PSdZ internal Http-Server is used for flashing via Ethernet
connections or not.
- Server Port: Defines the port for the internal PSdZ http server. If no port number is specified,
port 8888 will be used by default.
The default settings can be restored via the "Default" button.
Page 16 of 65
Figure 5: Connection settings
Page 17 of 65
2.2.6 External Applications
On the „External applications“ tab (cf. Figure 6) an external editor and a browser can be defined to open
appropriate file formats directly in those tools from E-Sys.
Figure 6: Settings for external applications
Page 18 of 65
2.2.7 Authentication
On the „Authentication“ tab (cf. Figure 7) one can define settings that allow the executability of secured
processes.
Developer-Soft-Token:
In this area of the tab it is possible to define the path for the developer soft token (EST) which is needed for
coding function data lists (FDLs).
Client Certificate for CBB:
In this area, a client certificate needed to establish a connection to the Certificate and Binding Box (CBB) can
be imported into the application. To do so the path to a valid certificate file in the CERT[PEM].txt format must
be specified and the “Import” button must be pressed afterwards.
To retrieve a valid client certificate one has to generate a Certificate Signing Request (CSR) for the
respective machine. After the successful generation of the CSR file a message will popup, indicating under
which path the CSR file can be found. Now the CSR file has to be manually forwarded to the respective
department.
Attention: It is only possible to import a client certificate which was issued based on the most
recently generated CSR.
Figure 7: Settings for the developer soft token (EST)
Page 19 of 65
2.2.8 ODX
On the „ODX“ tab (cf. Figure 8) the path of the ODX check rules can be specified. These rules are used by
the ODX-Checker in the PDX-Charger module to check for the correctness of ODX containers. As of E-Sys
3.4.0 C:\Data\Rules is the default directory to which the rules are copied during the installation process.
The maximum size of the user documentation that can be added to the PDX container can be specified in
the box „Component Documentation Files“ (cf. chapter 3.5).
Figure 8: Settings for ODX-Checker rules
Page 20 of 65
3) Creating a PDX component container

This chapter describes how to create a PDX component container based on a PDX template and how to
import the container to the programming system PSdZ.
3.1 Loading the PDX template

To create a component container an up-to-date PDX template has to be loaded in the module “Data
Handling → PDX-Charger”. The current PDX template can be obtained via SWL Cockpit.
3.2 Assignment of main series

As of E-Sys 3.15 it is possible to select for which main series (BRVs) a PDX container should be valid. The
list of possible main series is defined by the underlying PDX-Template. The single main series can be
selected in a dedicated dialogue after clicking on the “Edit” button (cf. Figure 9, red box).
Figure 9: Main series for a PDX container
Page 21 of 65
3.3 Adding ECU software

In the PDX template tree you can then create new ECU variants by right-clicking on the root element PDX-
Container and choosing “Add new ECU variant” from the menu. Each new ECU variant must first be
assigned to a base variant. This is done by choosing the appropriate base variant from the corresponding
drop-down menu. The ECU variant can then be renamed. A valid name must end with the suffix “_EV”.
Figure 10: PDX-Charger with loaded PDX template
Finally, the software units (SWEn) for the ECU variant can be added by choosing “Add” in the SWE context
menu. The appropriate SWE files in the BSW format (binary software) can then be chosen from a file
dialogue. The software units are automatically extracted and processed during container import.
The coding application files (CAFs) needed for ECU coding cannot be added beneath the ECU variant. They
are added to the CAF element at top level instead. Thus, they are not related to any ECU variant. The same
applies to SVT files which can be added to the SVT element. All other configuration files (e.g. mapping files,
sweseq files (cf. 3.6), …) have to be appended beneath the Config element.
Page 22 of 65
3.4 Adding BLUP/FLUP files and BLUMap

Bootloader updaters with process classes BLUP/FLUP are added to ECU variants beneath the SWE
element just like conventional bootloaders with process class BTLD (cf. Figure 11). The files are chosen from
a file dialogue as usual.
Figure 11: Adding a BLUP to a component container
Page 23 of 65
If an ECU variant (HSR_EV in our example) contains at least one BLUP or FLUP the appropriate BLUMap
can be added by using the basevariants context menu (cf. Figure 12) and choosing the appropriate file from
the file dialogue. After picking the file its name can be altered. The convention for BLUMap files is
blumap_<base_variant_name>_<component_name>.xml.
The added BLUMap then appears beneath Config/blumaps and is not assigned to a certain ECU variant (cf.
Figure 13, red marking). To see if a BLUMap has been added for an ECU variant, check for the element
“Bootloader map present: yes” beneath the variant.
Figure 12: Adding a BLUMap to the container

When importing a PDX container the BLUP/FLUP software units are copied to the directory
psdzdata\swe\blup respectively psdzdata\swe\flup. The BLUMap is copied to folder
psdzdata\mainseries\<BRV>\<project>\mapping\blumaps.
Page 24 of 65
Figure 13: BLUMap displayed in the PDX-Charger
Page 25 of 65
3.5 Adding user documentation

By adding user documentation to the container software developers can even distribute non-ODX-contents
in the PDX container (TALs, manuals, etc.). These documents can be added by using the context menu of
the DOC element (cf. Figure 14). The component container must be saved before inserting the documents.
Figure 14: Adding user documentation to the container
Appended documents are saved in the ZIP archive <component_name>_Doku.zip within the container and
are listed beneath the DOC element in the PDX charger (cf. Figure 15).
Page 26 of 65
Figure 15: User documentation displayed in the container
The maximum size of this archive defaults to 1MB. It can be altered in the menu Options → Settings → ODX
(cf. section 2.2.8).
3.6 Setting the programming order

By adding a sweseq file to the container one can specify a programming sequence for the software units of
an ECU. This file has to respect the naming convention sweseq_<bootloader_ID>.xml.xxx_yyy_zzz where
<bootloader_ID> is the 8-digit SGBM-ID of the ECU (e.g. sweseq_01020304.xml.001_002_003 to specify a
programming sequence for the standard core template). The sweseq file is added to the container node
Config.
Figure 16 displays the SWESEQ-Editor used to create sweseq files in E-Sys. In the sweseq file, only
dependencies for the programming order can be specified („SWE A has to be programmed before SWE B
und SWE C“), not a definite sequence. The programming system will determine a feasible sequence
respecting the restrictions made in the sweseq file at runtime.
Attention: If the sweseq file contains cyclic dependencies („A before B“ as well as „B before A“)
programming will be aborted.
For each dependency, an ECUDependencies element has to be created in the sweseq file. Within this
section the following elements have to be filled:
▪ BootloaderId: The bootloader ID of the designated ECU
▪ BaseVariant: The ECUs base variant (as listed in the PDX container)
▪ PhysicalOffset: The ECUs diagnostic address (hex)
▪ PreConditions: A list of SGBM-IDs of software units to be programmed before those listed in
Dependors.
Page 27 of 65
▪ Dependors: A list of SGBM-IDs of software units to be programmed after those listed in

PreConditions.
In the example in Figure 16 thus software unit 11121314 has to be programmed before software units
21222324, 31323334 and 41424344 on an ECU with standard core template (bootloader ID 01020304,
diagnostic address 0x7E, base variant EVALBOARD). The software units 21222324, 31323334 and
41424344 can be programmed in any sequence preferred by the programming system.
Figure 16: Loaded SWESEQ file in the SWESEQ-Editor
Attention: Sweseq files can also be used to specify an order among master (BTLD) and slave
bootloader (FLSL). If no dependency is specified between those the slave bootloader (FLSL) will be
programmed first. Structural dependencies (e.g. BTLD before SWFL, SWFL before CAF) don’t need to
be defined here. If the dependencies specified by the user are in conflict with those elementary rules
programming will be aborted!
Page 28 of 65
3.7 Saving the container

When the container covers all desired ECU variants and configuration files it obviously has to be saved for
further use. Use the “Save as” function for this purpose not to overwrite the underlying template. When
saving the container the naming convention (cf. Table 1) has to be respected to submit the container to
software logistics.
<E/E_component>__<free_text>.<version>.pdx
For the E/E component, the hyphen "-" should be replaced by a double underscore "__"
According to these rules ZBE__04__F001.003_004_000.pdx for instance would be a valid component
container name.
E/E component [A-Z0-9_]{1,8}__[A-Z0-9_]{1,8} E.g. ZBE__04
Free text [A-Z0-9_]{1,20} E.g. F001
Version \d{3}_\d{3}_\d{3} E.g. 003_004_000
Table 1: Legend for naming the component container
Page 29 of 65
3.8 ODX-Checker
After saving the container it can be checked for formal correctness by using the ODX-Checker (cf. Figure
17). The rules needed by the ODX-Checker are copied to the folder C:\Data\Rules during the E-Sys
installation process (cf. section 2.2.8). If new checker rules are provided via GIS the old rule files in this
folder have to be replaced by the user.
The ODX-Checker detects errors and irregularities in the and reports those in the lower section of the PDX-
Charger (cf. Figure 17).
Attention: E-Sys contains ODX-Rules which have been developed exclusively for BMW as well as
ODX-Rules which have been purchased by BMW within the scope of the package ASAM. If a user
installs E-Sys on a hardware which is not owned by BMW AG or any other affiliated company within
in the BMW Group, the user shall:
1. Purchase a Licence for the ASAM-Rules (detailed information can be obtained at
http://www.asam.net) or
2. Delete the ASAM-Rules which can be found in the data directory (default:
C.\Data\Rules\asamrules.jar).
Otherwise the user commits a violation of third parties intellectual property (right to licence).
Figure 17: Report after ODX check
Page 30 of 65
3.9 Importing the component container into PSdZ

Before the contents of a PDX container can be used in E-Sys the container has to be imported into the
programming system by means of the button “Import into PSdZ”. When importing the container a name
differing from the container name can be specified as the project name under which the container data is
stored and displayed when connecting to a vehicle or ECU.
Attention: If a container is valid for more than one main series (cf. chapter 3.2) the PSdZ import
creates a project for each valid main series. If the first four characters of the project name do not
match the name of the main series, the name of the main series will be put in front of the project
name followed by an underscore.
Example: If a container valid for F001 and F010 is imported with the project name “my_project”, the
projects “F001_my_project” and “F010_my_project” will be created.
In the course of the import, data from the container is extracted and copied to the folder <E-
Sys_data>/psdzdata for local use by E-Sys. The contents of <E-Sys_data>/psdzdata can be displayed and
edited in the File-Explorer module (cf. Figure 18).
Attention: As the files in the directory psdzdata/extLibs are used by the Java Virtual Machine (JVM)
this folder cannot be deleted while E-Sys is running.
Figure 18: File-Explorer view after ODX data import
Page 31 of 65
3.10 Updating containers

It is also possible to update a component container to the level of a newer PDX template. To process the
update, the component container has to be loaded in the PDX-Charger first. The update is then triggered by
the “Update” button (cf. Figure 19). The user has to choose a template from a file dialogue. The template-
specific content of the component container is subsequently replaced by the selected template, the ECU-
specific content remains unaltered. The updated container can then be saved with a new name by means of
“Save as” (cf. section 3.7).
Figure 19: Updating the PDX container
Page 32 of 65
4) Creating a TAL
In order to program an ECU, E-Sys needs a transaction list (TAL). A TAL can either be created manually in
the TAL-Editor, it can be calculated automatically in the module “TAL-Calculating” or it can be derived from
an ECU variant in the PDX-Charger.
Attention: It is strongly recommended to calculate the TAL either from SVTactual and SVTtarget or
from an ECU variant in the PDX-Charger (with SVT readout). This ensures completeness and
correctness of the TAL.
4.1 Manual creation in the TAL-Editor

In the TAL-Editor (section Editors & Viewers) an empty TAL can be created by the menu item File → New or
the corresponding item in the toolbar. An existing TAL can be edited by selecting File → Open.
When creating a new TAL one has to use different TAL-Lines with unique IDs for each ECU and
transaction class. Furthermore each TAL-Line has to be filled with the base variant name (not the
component name) and the diagnostic address (hex) of the designated ECU (cf. Table 2: Base elements of a
TAL-Line
). The remaining attributes (ExecutionStatus, FlashPreReqs, CodingPreReqs, …) do not have to be altered.
TalLine Unique ID for each TAL-Line
BaseVariant Base variant of the ECU to be programmed as listed in the container
DiagAddress Diagnostic address of the ECU to be programmed (hex)
Table 2: Base elements of a TAL-Line

Elementary parts of each TAL-Line are the software units to be programmed. Those can be added by
appending a new transaction to a TAL-Line (by right-clicking the TAL-Line root element and choosing New
(cf. Figure 20)). It is important to pick the correct transaction category from the list e.g. SwDeploy for
programming application and data (process class SWFL). Table 3 displays the most important transaction
categories.
Page 33 of 65
Figure 20: Adding a new transaction
Figure 21 for instance shows a TAL for programming the bootloader and the software units of a HU_CIC.
Therefore one TAL-Line for the bootloader (TalLine_ID=tl_3) and one TAL-Line for application and data
software units (TalLineID=tl_4) have been created. Eight transactions of the same type (SwDeployTA) have
been appended to TAL-Line 4. The attributes beneath the SgbmIdentifier element (ProcessClass, ID,
MainVersion, …) have been filled according to the file names of the software units.
Attention: If the SWE versions specified in the TAL do not match the versions of the SWE files
programming will be aborted!
In addition, the InstalledEcuList_Ist/_Soll has to be filled with the ECUs (base variant and diagnostic
address) installed before/after TAL execution.
Page 34 of 65
Figure 21: TAL-Editor view with loaded TAL

The TAL-Line for the bootloader has been filled with a BLFlash transaction analogously.
SWDeploy Programming application software and data (SWFL)
CDDeploy Programming coding data (CAFD)
BLFlash Programming a master or slave bootloader (BTLD/FLSL)
Table 3: Important transaction categories in the TAL
Page 35 of 65
4.2 Automatic TAL calculation

In the module “TAL-Calculating” a TAL can be derived by specifying SVTactual and SVTtarget (cf. Figure
22). The SVTactual reflects the current state of the vehicle connected to the programming station and can be
read either from the vehicle configuration management (VCM) or directly from the vehicle’s ECUs or can be
loaded from a file. The desired vehicle state reflected by SVTtarget can be diverted from the KIS database (if
existent) or can also be loaded from a file. If it is derived from the KIS a vehicle order (FA) and an I-Step
have to be specified additionally.
Attention: Calculating a target SVT from the KIS database is only possible after an I-step container
has been imported. The available I-steps depend on the container, the activated FA and the
calculation strategy.
When SVTactual and SVTtarget have been loaded, the difference is displayed in the lower left part of the
module pane (red = acutual state, blue = target state). In the “TAL-Filter” area one can now load an
additional filter which will impact the TAL calculation process with respect to treated transaction categories
and/or ECUs (cf. chapter 4.3). By clicking the Calculation button a TAL containing all transactions needed to
transfer the vehicle (respectively the ECU composite) from the actual state to the target state is then
calculated. The calculated TAL can afterwards be saved, edited or directly executed. If the checkbox “ECUs
from SVTsoll” is activated, only ECUs contained in SVTtarget will be considered for TAL calculation. ECUs
only appearing in SVTactual will be discarded in this mode.
Attention: A connection is mandatory to calculate a TAL!
Page 36 of 65
Figure 22: Calculating a TAL from SVTactual and SVTtarget
4.3 Definition of a TAL-Filter

A TAL-Filter is used during the automatic TAL calculation and can further define in what matter specific
transaction categories and/or ECUs should be treated or not. The “TALFILTER-Editor” in the module “Editors
and Viewers” can be used to either load and modify an existing TAL filter or to generate a new TAL filter
based on a SVT. The following filter options can be applied to each transaction category of each ECU:
Empty Execution of the transaction depends on differences between SVTactual and SVTtarget
(filter option will not be added to the TAL-Filter)
Allow Execution of the transaction depends on differences between SVTactual and SVTtarget
(filter option will be added to the TAL-Filter)
Prohibit The transaction will not be executed (differences between SVTactual and SVTtarget are not
taken into account)
Force The transaction will be executed (differences between SVTactual and SVTtarget are not taken
into account)
Table 4: Possible filter options for transactions
Page 37 of 65
A generated or loaded TAL filter is displayed as a table (cf. Figure 23). Each row represents an ECU that can
potentially be treated during the TAL execution. Within the first column of the table one can set a global filter
option for each transaction category. During the TAL calculation process this global filter option will only be
considered for those transactions that were not explicitly defined on an ECU level (filter option = “empty”).
The columns of the table are used for the following purposes:
ID-Basis (column 1) Identification of the ECU based on its diagnostic adress in the
hexadecimal format (decimal in brackets).
Set All to… (column 2-5) Assigns the value of all TA categories of the respective ECU to the
value of the respective column.
Specifiy… (column 6) Opens a dialogue which allows to specify filter options for the sub
transactions of the swDeploy transaction (swDeployTa, swDeleteTA
for swfl and swfk). The specified options will be used if the filter
option for the swDeploy transaction is set to “User defined”.
TA-Categories (column 7-18) Allows the specific editing of a filter option with respect the
transaction category.
Table 5: Structure of the TAL filter wihtin the TALFILTER-Editor
Figure 23: Loaded TAL filter in the TALFILTER-Editor
Page 38 of 65
4.4 Creating a TAL in the PDX-Charger

If there is no KIS available, it can be useful to derive the TAL directly from the PDX container. Deriving a TAL
from the container is possible for the whole container as well as for single ECU variants. The function is
triggered by the menu item “Generate TAL” in the context menu of the ECU variant (cf. Figure 24)
respectively the context menu of the container root element. Transactions for all software units assigned to
this variant will then be created in the TAL. Depending on the container it can be necessary to assign version
information, diagnostic addresses or coding files in a wizard afterwards if the information cannot be uniquely
derived from the container.
A SVTtarget can be created in a similar fashion (see above). With a SVTtarget a TAL can be calculated in
the module TAL-Calculating based on an up-to-date SVTactual (cf. section 4.2). Advantage: Only the
necessary transactions are created in the TAL and less additional information has to be delivered by the
user.
A connection (cf. chapter 5) is needed to create a TAL/SVT in the PDX-Charger.
Attention: When creating a TAL in the PDX-Charger the InstalledECUList_Ist/Soll can only be filled
automatically if a valid SVTactual can be read at that time.
Otherwise the InstalledECUList_Ist/Soll remains empty. In this case the installed ECUs have to be
inserted in the InstalledECUList manually or automatically at TAL execution time (cf. chapter 6.2).
Figure 24: Creating a TAL/SVT from an ECU variant
Page 39 of 65
4.5 Creating a TAL with BLUP/FLUP
4.5.1 Automatic calculation in the comfort mode
Automatic TAL calculation as described in section 4.2 also works with process classes BLUP and FLUP. The
SVTactual/SVTtarget contains the actual or target bootloader with process class BTLD/FLSL in this case. By
using the BLUMap from the container the necessary BLUP/FLUP transactions for the TAL are calculated.
Attention: For this function, it is necessary to establish a connection with a project containing valid
BLUMaps for the desired ECU.
4.5.2 Automatic calculation in the PDX-Charger
Attention: It is not possible to derive a TAL with BLUP/FLUP transactions in the PDX-Charger. The
actual ECU state needed for this calculation is not available in the PDX-Charger.
4.5.3 Manual creation of a TAL with BLUP/FLUP
To add BLUP/FLUP transactions to the TAL manually please follow these instructions:
Page 40 of 65
1. Create a TAL-Line for the BLUP/FLUP transaction and add a BlFlash section to this TAL-Line (cf.
Figure 25).
Figure 25: Adding a BlFlash transaction to the TAL
Page 41 of 65
2. Delete the BLFlashTA element BLFlash_BTLD_00000000_001_000_000 created by default

(cf. Figure 26).
Figure 26: Deleting the default BLFlashTA entry
Page 42 of 65
3. Create a new BLFlashTA from a file (cf. Figure 27).
Figure 27: Adding a BLFlashTA based on a file
Page 43 of 65
4. Pick the desired BLUP file from the file dialogue. Subsequently a BLFlash transaction is created
which contains the SGBM-ID of the BLUP as well as the SGBM-ID of the encapsulated BTLD
(contained bootloader) (cf. Figure 28).
Figure 28: TAL-Line with BLUP transaction
Page 44 of 65
5) Connecting
Before programming or coding an ECU a vehicle connection has to be established. This is only possible with
a PDX container successfully imported into PSdZ (cf. section 3.9). The connection dialogue can be opened
by clicking the connection button in the toolbar (cf. Figure 29).
Figure 29: Connection button

The E-Sys connection dialogue (cf. Figure 30) is divided in three parts, i.e. “Target”, “Interface” and “Vehicle-
specific parameter”. In the “Target” section in the upper part the “TargetSelector” for the connection can be
chosen. The “TargetSelector” determines the ODX project (i.e. the data from an imported container) you
want to work with. In the “Interface” section the physical interface for the connection can be defined. In the
“Vehicle-specific parameter” section additional information about the connected vehicle can be specified.
The following sections explain the use of these settings regarding the various connection types.
Figure 30: Connection dialogue
Page 45 of 65
5.1 Choosing a TargetSelector

Each “TargetSelector” is composed of two parts, the “Project” and the “VehicleInfo”. By choosing a “Project”
you determine which imported ODX container data you want to use for the connection. The “VehicleInfo”
defines whether a direct ECU connection or a connection via gateway (e.g. ZGW) is set up. Thus two
TargetSelectors are offered for each imported container, one for direct ECU connection and one for gateway
connection. The dropdown menus “Main series” and “Connection type” can be used to further filter the list of
displayed target selectors.
5.1.1 Connecting via gateway
Gateway connection has to be chosen whenever a gateway is installed between the programmer and the
ECU(s) to be programmed. The gateway will route all diagnostic services to the ECU bus system and back
to the tester based on its routing table.
Attention: When setting up a gateway connection, a “VehicleInfo” WITHOUT the suffix “_DIRECT”
has to be selected in the connection dialogue (cf. Figure 31).
Figure 31: Valid TargetSelectors for a gateway connection
5.1.2 Direct connection
In the case of a direct connection, the host computer is connected for example via a CANCard or CANCase
or something comparable. That means a direct connection is established to the ECU to be programmed; no
gateway-ECU is used.
Attention: When setting up a direct ECU connection a “VehicleInfo” WITH suffix “_DIRECT” has to be
selected (cf. Figure 32).
Page 46 of 65
Figure 32: Valid TargetSelectors for a direct ECU connection
5.2 Choosing the physical interface

By selecting the radio buttons in the lower part of the dialogue the user can decide which hardware interface
is used to set up the connection.
5.2.1 Connecting via Ethernet
An Ethernet connection can be set up by either specifying the gateway URL or by selecting a vehicle by its
vehicle identification number (VIN). To set up a vehicle connection the tester and the vehicles’ gateway have
to be in the same IP subnet. If there is no DHCP server available in this subnet the gateway will fall back to a
169.254.x.y local IP address (Windows APIPA addressing). This means an address in the same subnet (i.e.
169.254.u.v) has to be assigned to the testers’ network interface to set up the connection, the subnet mask
is 255.255.0.0 in this case.
Connecting via gateway URL
If one knows the gateways’ IP address a connection can be set up by simply entering the URL (cf. Figure
33). Specifying the protocol (tcp://) and the port (:6801) is mandatory! Thus tcp://169.254.47.11:6801 would
be a valid gateway URL.
Instead of the IP address the gateways’ DNS name can also be used in the gateway URL. For a vehicle with
the VIN “00000000000000000” the gateway URL would in this case be
tcp://diagadr10bmwvin00000000000000000.muc:6801.
Figure 33: Connecting via gateway URL
Page 47 of 65
Connecting via vehicle identification number (VIN)
When opening the connection dialogue and after clicking the “Refresh” button all available vehicles are
detected by a network broadcast and their vehicle identification numbers (VINs) are listed under “Connection
via VIN” in the connection dialogue (cf. Figure 34). A connection to the desired vehicle can be established by
picking it from the drop down list. If there is no vehicle available “Connection via B2V” is disabled.
Figure 34: Connecting via VIN
5.2.2 Connecting via ICOM
Basically there are two ways to set up a connection via ICOM depending on whether the ICOM forwards
messages to the vehicle via D-CAN or via Ethernet. Irrespective of that the connection to the ICOM is always
set up via TCP/IP.
Connecting via ICOM/D-CAN
If the ICOM forwards messages to the vehicle via D-CAN (special ICOM firmware required) “Connection via
ICOM/D-CAN” has to be chosen (cf. Figure 35). The ICOM URL has to be entered in the text field, the port in
this case is 52410 (50000 + 10*0xF1).
Figure 35: Connecting via ICOM/D-CAN
Connecting via ICOM/Ethernet
If the ICOM forwards messages to the vehicle via Ethernet “Connection via ICOM/Ethernet” has to be
chosen (cf. Figure 36). The ICOM URL has to be entered in the text field, the port in this case is 50000 +
10*<gateway diagnostic address>. To forward messages to the ZGW, for example, enter port 50000 +
10*0x10 = 50000 + 10*16 = 50160.
Page 48 of 65
Figure 36: Connecting via ICOM/Ethernet
5.2.3 Connecting via CANCard and CANCase
The supported CAN hardware and driver versions are listed in the release notes, at “C:\EC-Apps\ESG\E-
Sys……\lib\environment”, of the current E-Sys version. Up-to-date drivers for the CAN interfaces can
generally be downloaded from the manufacturers’ homepage.
Attention: Before programming via CANCard or CANCase the E-Sys vector driver „ProDiaS-CAN-
Driver CAN 1“ has to be assigned to the CAN device/channel connected to the ECU. The assignment
can be made in the „Vector Hardware“ panel located in the Windows system settings menu
(cf. Figure 37).
Figure 37: Example assignment of „ProDiaS-CAN-Driver CAN 1“ to channel 1 of CANcaseXL
Page 49 of 65
To connect to an ECU via CAN device, select „Connection via bus“ in the connection dialogue. The drop-
down menu on the left specifies the bus name (e.g. FA_CAN), the drop down box on the right specifies the
interface which is VECTOR_DIRECT in this case (cf. Figure 38).
Figure 38: Connecting directly via FA-CAN
Attention: When connecting to the D_CAN you must not select a “VehicleInfo” with the suffix
“_DIRECT” since you will communicate with the ECUs via the gateway.
5.2.4 Connecting via OMITEC
Prior to using the OMITEC interface the EDIABAS OMITEC drivers have to be installed. The installation
package is available from GIS in the folder
BMW Standard Tools Entwicklung

Standard Tools/ Fahrzeug-Kommunikation/ EDIABAS/ HW-Interface/
EDIABAS Interface OMITEC
The settings in the connection dialogue are “Connection through Bus” with bus name “D_CAN” and interface
“STD_OMITEC” (cf. Figure 39). When choosing a target selector one has to select a project without the
suffix “_DIRECT”.
Page 50 of 65
Figure 39: Connecting via OMITEC interface
5.2.5 Connecting via radio interface
Similar to the OMITEC interface, EDIABAS is also needed to use the radio interface with E-Sys. You can
install EDIABAS as part of the “Standard Tools Setup” available from GIS in the folder
BMW Standard Tools Entwicklung

Standard Tools/ Programmierung/ Tool Installation Entwicklung/ Für Windows XP/
Tool-Setup 2.12.0 - EDIABAS, INPA, NFS, WinKfP, NCSexpert - Win7 32Bit + XP
To connect via radio interface pick „Connection through Bus“ with bus name “D_CAN” and interface
„STD_FUNK“ (cf. Figure 40).
Note: To use the radio interface additional settings are necessary (cf. section 2.2.5).
Figure 40: Connecting via radio interface
5.3 Choosing vehicle-specific parameters

As of version 3.22 series and I-step (shipment) of the connected vehicle can be specified in the connection
dialogue or read from VCM (cf. Figure 41).
Figure 41: Vehicle-specific parameters
Page 51 of 65
Setting those parameters causes E-Sys to use special data from the PDX template for a certain series/I-step
if applicable. Such special data is necessary if certain ECU attributes (e.g. bus connection) have to be
differentiated within one main series. It is thus recommended to specify or read those parameters from VCM
whenever possible. If the parameters are not set (empty fields), E-Sys uses default data for the particular
main series.
5.4 Connection test

To check the connection it is recommended to read the SVT from the vehicle/ECUs after setting up the
connection. The function “Read (ECU)” is for instance located in module „Comfort Mode → TAL-Calculating“
(cf. red marking Figure 42). If the connection has been set up successfully, the configuration of all connected
ECUs will be displayed in the left module pane. If an error occurs or the pane remains empty please check
for the connection settings again!
Figure 42: Read SVT_actual from ECUs
Page 52 of 65
6) Executing a TAL
The actual programming process is triggered in the module “TAL-Processing” where the transactions
contained in the TAL (cf. chapter 4) are finally executed. Before the execution one at least must perform the
following preparations within the top area of the module (cf. Figure 43):
1. Loading of a valid TAL
2. Providing of a valid vehicle identification number (VIN)
As an alternative to the process of manually typing the VIN into a text field, the VIN can also be read from a
vehicle order (FA) or directly from the VCM (button “Read VIN (VCM)”). If stored in the VMC, the FA itself
can also be read from the vehicle (button “Read (VCM)”). TAL and FA can be opened for editing in the
designated editor by clicking the “Edit” button. Optionally a SVT can be specified which will be written as
SVTtarget to VCM before TAL execution if VCM supports SVT version 6 or higher.
Attention: If the TAL contains coding transactions an entire FA is needed for TAL execution instead
of just a VIN. FAs can be created comfortably with the tool [FA_GEN].
Figure 43: General controls in the TAL execution module
The controls at the bottom of Figure 43 have the following functions:

▪ Start: Button to start the TAL execution and automatically redirects you to the “Log” tab (cf. chapter
6.3). During TAL execution the button label changes to „Pause“ and the TAL execution can be
interrupted.
▪ Stop: Button to cancel the TAL execution. Activated only when TAL execution is in progress.
▪ Check software availability: With this button a manual check for the availability of the required
software units can be triggered before the start of the TAL execution. (can be useful if the automatic
check for software availability is disabled (cf. chapter 2.2.4))
▪ Details: This button can be used to switch to the TALSTATUS-Viewer module after the execution of
the TAL. The TALSTATUS-Viewer module can be used to e.g. further analyse the status of the
executed TAL or the executed flash sequence.
Page 53 of 65
6.1 Selecting ECUs and transaction classes

In the tab “ECU” (cf. Figure 44) one can specify if certain transaction categories or ECUs should not be
treated during the TAL execution. By means of a checkbox matrix users can precisely specify which
transaction categories in a TAL are executed for a defined ECU. Transaction categories (columns) are only
displayed if there is at least one ECU that can be treated with the respective transaction type. Transactions
that are not part of the TAL but are displayed in the matrix are disabled and highlighted with a dark grey
background colour. For transaction with a status different from “executable” the respective status is
displayed instead of the checkbox.
Figure 44: Checkbox matrix for choosing transactions
Attention: Transactions with a status different from “executable” are always executed. Therefore
failure free execution of the TAL is not possible.
Page 54 of 65
6.2 Parameters for TAL the execution

In the “Parameters” tab (cf. Figure 45) the parameters for TAL execution can be set:
▪ Parallel Programming: Defines whether the transactions in the given TAL are executed
sequentially or in parallel (default: active).
▪ Repeat in case of error: Defines how often single transactions within the TAL are repeated in case
of failure (default: 1).
▪ Check Programming Counter: Defines whether the ECUs’ programming counters are taken into
consideration or not (default: active).
Important note: The programming counter can only be ignored if TesterApplyIdentifier “F”
(development) is set (cf. section 2.2.2).
▪ Deactivate HTTP-Transmission: Defines whether the PSdZ internal HTTP-Server for flashing via
Ethernet will be deactivated (default: inactive)
▪ Auto-fill InstalledEcuList in TAL before execution: Defines whether the InstalledEcuList of the
selected TAL is to be adjusted to the read-out SVT before TAL execution or not. In this case the
existing list can be either merged or overwritten (default: active + merge).
▪ Kilometers for fingerprint: Allows the user to define a specific mileage (km) for the fingerprint of
the flash process (cf. chapter 2.2.2). (Default: 0)
▪ Deactivate Response on Event (RoE) during TAL execution: Defines whether a diagnostic
command for the deactivation of RoEs will be send to all ECUs at the beginning of the TAL
execution.
Attention: In order to ensure a flawless flash sequence by a direct flash connection, this function
must be deactivated (= ckeckbox not set!).
When flashing over a gateway, this feature can be selected. (Recommendation: = not checked)
▪ Activate programming mode for switchable ECUs: Defines whether ECUs marked as switchable
in the ODX data are switched to programming mode during TAL execution or not. Not switching
ECUs to programming mode can result in reduced parallelism and block sizes and therefore in a
longer programming time.
In addition to that the table underneath the checkbox can be used to define in detail which ECUs
should be switched to programming mode. Since it is not known by the system rather an ECU is
switchable or not, all the ECUs present in the TAL are listed in the table. Therefore the user must
know rather an ECU is actually switchable. The columns of the table have the following functions:
1. ID-Basis: Identification of the ECU based on the respective Basevariant name with
appended diagnostic address (hexadecimal)
2. Default: ECU is not listed in the Blacklist nor in the Whitelist. PSdZ do his own calculation
strategies (usually switchable ECUs are always switched)
3. Blacklist: ECU must not be switched to programming mode
4. Whitelist: ECU must be switched to programming mode if programming mode is supported
Page 55 of 65
Attention: In case an ECU is added to the Blacklist it is recommended to add all other ECUs to the
Whitelist. It should also be noted that ECUs can only be switched if central gateways are not
included in the blacklist.
Figure 45: Parameters for the TAL execution
Page 56 of 65
6.3 Logging during the TAL-Execution

The “Log” tab is used to present information about the progress of the TAL execution to the user (cf. Figure
46). The controls above the logging area suit the following purpose:
▪ Clear: Button to delete the contents in the logging area
▪ Events: Checkbox to specify whether events are displayed in the logging area during TAL execution
or not (default: active)
▪ Event Type: Opens a dialogue in which one can specify the types of events that are displayed
during the TAL execution (default: all events)
Figure 46:Log windows during the TAL execution
Page 57 of 65
7) Special features for L4-ECUs
7.1 Mapping
To be able to treat KWP2000-ECUs adopted from a prior series, logistic information from those ECUs
(assembly number, hardware number, hardware reference …) has to be mapped to SGBM identifiers. This is
achieved by means of XML mapping files which are generated in the “Eintrittskarteneditor (EKE)” and added
to the PDX container beneath the “Config” element (cf. Figure 47).
Figure 47: Container with mapping files for AMP_TOP and MULF_Basis
The following list briefly describes the existing mapping files and the mapping flow:
▪ _BTLD: Maps the ECU hardware reference to the SGBM-ID and the version of the bootloader
(BTLD).
▪ _CAFD: Maps the assembly number to the SGBM-ID of the CAF file (CAFD). The CAF main version
is derived from the parameter BMW_vehicleManufacturerCodingIndex which is part of the ECU
response to the diagnostic service „Ident_Lesen“. Subversion and patch version are derived from the
diagnostic service „Aenderungsindex der Codierdaten lesen“.
▪ _HWEL: Maps physical ECU hardware number (PECUHN) and hardware reference (ZZZPPP) to the
SGBM-ID and the version of the hardware module (HWEL). If the hardware number cannot be read
HWEL-mapping is based on the hardware reference only.
▪ _TYPNR: Maps the assembly number to the type approval number (“Typprüfnummer”).
▪ _ZB: Maps the assembly number and the program reference (respectively the data reference) to the
application (and data) software units (SGBM-IDs and versions). If ECU information and mapping files
differ in the program version only the SGBM-IDs are mapped and versions are set to 000_000_000.
Page 58 of 65
7.2 AIFContents
When programming a KWP2000-ECU in E-Sys the content of the user info field (AIFcontents) has to be filled
in the TAL (cf. Figure 48).
Figure 48: TAL with AIContents for MULF_Basis
The following elements have to be filled (if they have not been generated automatically):
▪ BmwAssemblyNumber: Assembly number written to AIF/UIF after programming
▪ BmwCalibrationDataSetNumber: SW number from the _TYPNR mapping file for ECUs with large
AIF (51 or 64 byte), "0000000" otherwise
▪ BmwExhaustRegulationOrTypeApprovalNumber: Type approval number (“Typprüfnummer”)
from _TYPNR mapping file for exhaust relevant parts, "0000000" otherwise
▪ PrgRef: Program reference of the software to be programmed
Attention: The AifContents entered in the TAL are written to the ECU after a successful programming
process. Therefore mapping might not be possible afterwards if this information is not correct. In
this case the ECU would no longer be programmable with E-Sys.
Page 59 of 65
8) Recovering individual data

The purpose of recovering individual data (IDR) is to read user specific data from an ECU before certain
ECU actions (exchange, programming ...) are performed and to write the data back after those actions.
IDRlight is a simple variant of IDR used by certain ECUs.
8.1 IDBackup
IDBackup denotes the process of reading and saving individual data. To perform an IDBackup first of all an
adequate TAL is required. This TAL can be either calculated automatically from an appropriate
SVTactual/SVTtarget or can be created manually in the TAL-Editor.
Automatic TAL calculation
To be able to calculate a TAL for IDBackup automatically with E-Sys, a SVTactual and a SVTtarget fulfilling
the following qualifications are needed:
▪ For the IDR-ECU at least, one hardware element (HWEL) had to be different between SVTactual
and SVTtarget in either the SGBM-ID or the version. Now it is possible to read out the individual data
memory objects from the ECU (cf. Figure 49)
▪
Figure 49: SVTactual and SVTtarget with different HWEL

If there is no KIS database available to derive an appropriate SVTtarget, it is recommended to adapt the
SVTactual in the SVT-Editor (change HWEL) and save it as a SVTtarget. With those two files available a
TAL for IDBackup can be calculated in the module „Comfort Mode → TAL-Calculating“ (cf. section 4.2).
Attention: Warnings might occur during TAL calculation e.g. if KIS is not available. Those warnings
normally do not affect IDBackup and can thus be ignored in this context.
The calculated TAL can afterwards be saved and edited in the module „Editors & Viewers → TAL-Editor“ or
in any other XML editor.
Manual creation
The TAL for IDBackup can also be manually created in the TAL-Editor (cf. Figure 50). At least the following
elements have to be added to the TAL:
Page 60 of 65
▪ A HWInstall transaction for the affected ECU (any content)

▪ A HWDeinstall transaction for the affected ECU (any content)
▪ An IDBackup transaction for the affected ECU
For each of these transactions a single TAL-Line has to be created (cf. section 4.1). Within the IDBackup
transaction an IDBackupTA or an IDBackupLight element has to be created. The default value is
IDBackupTA
Attention: Within an IDBackup transaction either an IDBackupTA or an IDBackupLight element can
be added. Thus the automatically created IDBackupTA element has to be deleted before an
IDBackupLight element can be created.
Figure 50: TAL with IDR transactions in the TAL-Editor
Page 61 of 65
Reading and saving individual data
In order to read the individual data, the TAL created in the former steps has to be loaded and executed in the
module „Expert Mode → TAL-Execution“ (cf. chapter 6). If IDR is successful the TAL executes with status
„FinishedForHWTransactions” and a dialog is automatically opened, asking the user where to save the
individual data. The data is then saved to the XML file IDBackup.bak (possibly additional files are genereated
aswell) in the specified directory (cf. Figure 51).
Figure 51: Backup files after IDR classic (left), IDR light (middle) and IDR with PIA Client (right)
Page 62 of 65
8.2 IDRestore
IDRestore denotes the process of writing individual data back to the ECU. Just like IDBackup the IDRestore
process is triggered by executing a TAL, either calculated automatically or created manually. Automatic
creation only works when the individual data is stored in an IDBackup.bak file created in the IDBackup
process described in section 8.1.
Automatic TAL calculation
For calculation of the IDRestore transaction in the module “Comfort Mode → TAL-Calculating” SVTactual
and SVTtarget do not necessarily have to be different. Thus both can be filled with the SVTactual read from
the vehicle so a correct InstalledECUList will be created even with no KIS available. Additionally the
checkbox “Use data backup” has to be checked and the directory containing the file IDBackup.bak has to be
specified in the file dialogue next to the checkbox (cf. Figure 52). Having done that the TAL calculation can
be triggered by the “Calculation” button and a TAL containing all the information from the backup file will be
created.
Attention: Warnings might occur during TAL calculation e.g. if KIS is not available. Those warnings
normally do not affect IDBackup and can thus be neglected in this context.
Figure 52: TAL calculation settings for IDRestore
Manual creation
Similar to IDBackup the IDRestore TAL can also be created manually. For this purpose a TAL with a single
TAL-Line containing an IDRestore transaction has to be created in the TAL-Editor (don’t forget to fill base
variant and diagnostic address). Different settings have to be performed depending on the IDR mode
Page 63 of 65
1. IDR light:
In order to accomplish an ID restore light, one has to add an IDRestoreLight element to the
IDRestore-TAL-line (this requires to first delete the automatically generated IDRestore element).
Then for each DataRecord a matching Element containing the DataIdentifier and the respective
value (cf. IDBackup.bak) has to be appended (cf. Figure 53). This is done by right-clicking on
"IDRestoreLight  new  DataRecord".
Figure 53: TAL for IDRestore (IDR light)
Page 64 of 65
2. IDR classic and IDR with PIA client

In order to accomplish an IDRestore for IDR classic or IDR with a PIA client, one has to add an
IDRestore Element to the IDRestore TAL line for each additional file that contains individual data.
Within the IDRestore elements one has to define the MemoryObjectIdentifier, the MemorySize and
the path to the individual data file (cf. Figure 54).
Figure 54: TAL for IDRestore (IDR classic & PIA client)
Restore individual data
To finally write back the data to the ECU the calculated or manually created TAL has to be executed in the
module “TAL-Execution”. If the individual data could be restored successfully the TAL execution will end with
the status “Finished”.
Page 65 of 65

E-Sys Manual PDF

Uploaded by

Copyright:

Available Formats

E-Sys Manual PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

E-Sys Manual PDF

Uploaded by

Copyright:

Available Formats

Fahrzeugprogrammierung

3) Creating a PDX component container 21

4.5.1 Automatic calculation in the comfort mode 40

7) Special features for L4-ECUs 58

8) Recovering individual data 60

1.1 Change documentation

0.1 07.12.06 Creation of document Wolfgang Schühle, ESG

1.0 11.01.07 Document completely reworked Tobias Thiemann, ESG, ES-71

Adaptation to E-Sys 3.0

Adaptation to E-Sys 3.1

Adaptation to E-Sys 3.3

Adaptation to E-Sys 3.4

Adaptation to E-Sys 3.5

5.2 12.06.08 Adaptation to E-Sys 3.6 Tobias Thiemann, ESG, FZ-620

Adaptation to E-Sys 3.7

5.4 05.09.08 Section 3.4 added Tobias Thiemann, ESG, FZ-620

License note added in section 3.8

5.6 10.12.08 Chapter 8 added Tobias Thiemann, ESG, FZ-242

Adaptation to E-Sys 3.10

Adaptation to E-Sys 3.12

Section 2.2.5 updated

6.3 30.04.10 Warning in section 3.5 added Tobias Thiemann, ESG

6.4 01.06.10 Warning in section 4.3 added Tobias Thiemann, ESG

Adaption to E-Sys 3.15

Adaption to E-Sys 3.22

General rework and adaption to E-Sys 3.30.1

Adaption to E-Sys 3.32

[SWEGEN] 1.0 28.11.2006 Handlungsanweisung SWE-Generator Patrick Wagner, ESG

[FA_GEN] 4 02.07.2009 FA-Generator Markus Wolf, BMW

CAF Coding Application File

CBB Certificate and Binding Box

CSR Certificate Signing Request

E-Sys New programming system for BMW ECU development

FA Fahrzeug-Auftrag (Vehicle order)

FP Fahrzeugprofil (Vehicle profile)

FSC Freischaltcode (Activation code)

GIS Global Information Server

GUI Graphical User Interface

IDR Individual Data Recovery

KIS Kompatibilitäts- und Informations-System (compatibility and information system)

LAN Local Area Network

ODX Open Diagnostic Data Exchange

PDX Packed ODX

PSdZ Programmiersystem der Zukunft (BMW programming core)

SG-ID Steuergeräte-Identifier (ECU identifier)

SGBM Steuergerätebeschreibungsmodell (ECU description model)

SGBM-ID Steuergerätebeschreibungsmodell-Identifier (ECU description model identifier)

SWLdZ Software-Logistik der Zukunft (BMW software logistics)

SREC Motorola SREC format

SVK Steuergeräte-Verbau-Kennung (software variant identification)

SVT (Ist) System variant table (actual)

SVT (Soll) System variant table (target)

SWE Softwareeinheit (software unit)

TAL Transaktionsliste (transaction list)

VCM Vehicle Configuration Management

VIN Vehicle Identification Number

1.6 Table of figures

Figure 39: Connecting via OMITEC interface...................................................................................................51