EVC WinOLS Ecosystem Explained: DAMOS, A2L, Plugins & ECU Tools

In the world of ECU calibration, it is difficult to find software as well known as WinOLS. Developed by EVC electronic, this software has been used for many years as one of the industry standards for analyzing, editing, and developing ECU files. From tuners to companies active in motorsport, R&D centers, and even some automotive manufacturers, many professionals rely on WinOLS for complex calibration projects.

However, WinOLS is only one part of what EVC has developed over the years. Alongside this software, EVC also offers a range of engineering projects, calibration data, specialized plugins, checksum modules, ECU programming tools, and hardware equipment, each of which has a specific role in the ECU workflow. Many users have heard the names of these products, but often do not have a clear understanding of the differences between them, what they are used for, or how they are connected to WinOLS.

If your goal is to become familiar with the WinOLS environment, its internal capabilities, editing tools, map-finding methods, or analytical features, we have covered these topics in detail in a separate article. In this article, our focus is on the products and services that EVC provides alongside WinOLS. We will examine what each one is used for, when it is required, and how they work together to create a complete workflow for ECU professionals.

OLS Projects

If you are working with WinOLS for the first time, you will probably encounter files with the .OLS extension very quickly. Many users initially assume that these files are simply saved versions of a project. In practice, however, an OLS Project is one of the most important concepts in the WinOLS workflow, and its role goes far beyond that of a standard file.

Unlike a Binary file, which contains only the raw ECU data, an OLS Project manages all the information created during the analysis and calibration process. Every time you identify a map, assign a name to it, add a description to the project, or create a new version of the file, that information is stored within the same project. For this reason, an OLS Project can be considered the workspace of WinOLS, where all stages of ECU file analysis, documentation, and development are organized and recorded.

This becomes even more important in professional projects. An ECU file is usually not edited only once. Different versions may be created from the same original file for Stage 1, Stage 2, dyno testing, or even dedicated custom calibrations. If only the Binary files are saved, much of the information obtained during the analysis process can be lost. An OLS Project, however, keeps all of these versions, changes, and notes together, making it possible to review or continue the development of a project at any time.

Another advantage of this structure is the ability to develop a project progressively. Imagine that today you have identified only some of the maps in an ECU, but several months later you gain access to a DAMOS file, A2L file, or new engineering information. In this situation, there is no need to start the project from scratch. The new information can be added directly to the same OLS Project, allowing the project to become more complete over time. This is why many tuners use OLS Projects as a database for each ECU rather than simply as a place to store an edited file.

DAMOS and A2L

DAMOS and A2L files are Calibration Description Files that provide engineering information about an ECU to software such as WinOLS. These files can contain map names, table axes, measurement units, conversion factors, data types, and other information that allows the internal structure of an ECU file to be displayed in an understandable and engineering-oriented way. Using this information increases the speed of file analysis and reduces the possibility of errors when identifying maps.

Although DAMOS and A2L differ in terms of their formats and standards, their overall purpose is similar: providing engineering information for ECU analysis and calibration. Map Packs, on the other hand, are usually created by tuners and generally contain only the locations and names of certain maps. For this reason, DAMOS and A2L files typically provide more complete and detailed information than a Map Pack.

It is important, however, not to treat an OLS Project, DAMOS, A2L, and Map Pack as the same thing. Simply put, although all three types of calibration-description resources are used to make ECU map identification easier, their applications are different.

A Map Pack mainly provides WinOLS with the location of maps and basic information about them. DAMOS can provide not only map locations but also detailed engineering information such as parameter names, axes, units, conversion factors, and technical descriptions. A2L is very similar to DAMOS in terms of the type of information it contains, but it is based on the ASAM standard and is used more extensively in OEM environments, software development, and factory calibration processes.

In short, Map Packs are designed for quickly identifying maps, DAMOS files for deeper engineering analysis of ECUs, and A2L files for standardized calibration-data exchange in professional environments.

WinOLS Scripts and Lua Plugin

Not every project is exactly the same as the previous one. A tuner may work with the same type of ECU every day, while another engineer may constantly switch between different brands and controller families. For this reason, performing certain tasks manually is not always the best solution, especially when the same process has to be repeated over and over using the same logic.

In the simplest definition, a Script is a set of instructions written to perform a specific task. Instead of requiring the user to manually repeat a series of steps every time, the script executes the same process automatically. The result is a reduction in the time required and a lower possibility of errors during repetitive tasks.

However, there is an important point to understand. Script execution is not available as a standard feature in WinOLS by default. It is made available through the Lua Plugin provided by EVC. In other words, the Script is not an independent product; rather, it is a capability added to WinOLS by installing the plugin.

EVC uses the Lua programming language for the WinOLS scripting system. Lua is a lightweight, fast, and relatively simple language that has been used for many years to develop customized functionality in engineering and industrial software.

Using Lua, users can create scripts that automate parts of repetitive processes within WinOLS or develop dedicated tools suited to the requirements of a particular project. This allows users to customize and expand their working environment according to their specific activities without having to modify the core software itself.

What Are Scripts Used For?

The application of scripts depends on the type of project and the user's requirements. Some scripts are designed to simplify everyday tasks, while others automate part of a larger workflow.

For example, a development team may create a script that performs a specific set of operations on a project or extracts the required information in a predefined format. In other projects, scripts may be used to perform specific calculations or integrate with a company's internal processes.

The important point is that EVC does not define one specific application for Scripts. Instead, it provides a framework that allows users to create dedicated tools according to their own requirements. This flexibility is one of the reasons why Scripts are particularly common among professional users and companies with established workflows.

If the goal is simply to edit ECU files or perform standard tuning projects, many users may never need to write or execute a Script. The core capabilities of WinOLS are sufficient for these types of projects. However, as projects become more complex or the workload increases, automating certain processes can save a significant amount of time and eliminate the need to repeatedly perform the same operations.

For this reason, Scripts are generally considered a productivity tool rather than an essential feature for every WinOLS user.

Checksum Modules

During the ECU file editing process, the primary focus is usually on modifying calibration maps. However, there is another important part of the workflow that, if ignored, can affect the entire result. This is the Checksum.

In simple terms, a Checksum is a method used by an ECU to perform numerical calculations and verify the integrity of data stored in its memory. When a file is written to or executed by the ECU, the controller checks the Checksum to ensure that the data has not been corrupted or improperly modified. If the calculated value does not match the structure expected by the ECU, the controller may identify the file as invalid or, in some cases, even prevent the ECU from booting.

During the remapping process, when changes are made to a Binary file, the data structure changes and therefore the original Checksum value may no longer be valid. For this reason, after modifications are made, the Checksum must be recalculated and corrected so that the file remains compatible with the ECU's internal logic.

In the past, this process was often performed manually or with separate software, and each ECU could require its own specific method for Checksum calculation. This made managing different projects more time-consuming and complicated.

Checksum Modules in WinOLS

To address this issue, EVC has developed a collection of Checksum Modules for WinOLS. These modules are specifically designed for different ECU families and are responsible for calculating and correcting the Checksum when a file is saved or exported.

When the appropriate Checksum Module is installed in WinOLS, the software can automatically detect changes made to the file and correct the Checksum according to the structure of that particular ECU. This makes the file-programming process more reliable and reduces the need for external tools.

However, this functionality is not universally available for every ECU. Each ECU family can have its own Checksum algorithm, which is why EVC provides these modules separately. As a result, users can purchase only the modules that are relevant to the projects they actually work on.

Furthermore, because of the large variety of ECUs used throughout the automotive industry, each manufacturer may use a different method for validating data. In some cases, even a single ECU family may have several different versions of its Checksum algorithm.

By providing separate modules for different ECUs, EVC allows users to select exactly the module required for their specific applications.

WinOLS Plugins

One of the reasons WinOLS has maintained its position among ECU calibration software for so many years is its modular architecture. The core software provides users with almost all the tools required for ECU analysis and editing, but not every possible capability is included by default.

Different projects may require support for specific file formats, communication with programming equipment, or data exchange with other software. For this reason, EVC provides many of these capabilities through separate plugins.

These plugins add new functionality to WinOLS, but their purpose is not to fundamentally change the software's core operation or increase its ability to edit maps. Their main purpose is to make WinOLS more compatible with different tools, file formats, and engineering environments while creating a simpler and more integrated workflow.

On the official EVC website, WinOLS plugins are divided into three main groups:

• Import / Export Plugins
• Map Plugins
• Special Plugins

Understanding the overall structure of these plugins provides a better picture of the WinOLS ecosystem.

Import / Export Plugins

In many projects, the ECU file is not provided to the user as a standard Binary file. Depending on the programming device or software used to read the ECU, the file may be stored in a proprietary format.

Import / Export Plugins allow WinOLS to open these formats directly or save the edited file again using the same structure after the editing process has been completed. As a result, there is no need to manually convert files, and the possibility of errors during the conversion process is significantly reduced.

Note: In this section, the term Slave Files refers to files generated by Slave versions of programming equipment. In many of these systems, importing or exporting such files still requires the software, license, or API of the Master version. Therefore, the term "Slave Files" does not mean that Master access is unnecessary.

Below are some of the most important plugins in this category.

NewGenius Connector

This plugin is designed for users who work with NewGenius programming equipment from Dimsport.

NewGenius Connector establishes direct communication between WinOLS and the NewGenius environment, allowing Master-version users to transfer files between the two software platforms without requiring manual conversion.

To use this plugin, the NewGenius software must be installed on the system.

CMD Flash Slave Files Connector

This plugin is designed for users who work with Slave files generated by CMD Flash.

Using this connector, Slave files can be imported directly into WinOLS and, after the editing process has been completed, exported again in the same format.

However, CMD Flash must be installed and access to the Master version is required, because the processing of Slave files is performed through the Master environment.

Autotuner Slave Import / Export

Users working with Autotuner equipment can also import their Slave files directly into WinOLS and export them again in the same format after making the required modifications.

In addition to simplifying the Import and Export process, this plugin also handles the encryption and decryption of Slave files automatically.

Access to the Autotuner Master API is required to use this functionality.

Magic Motorsport Slave Import / Export

EVC also provides a plugin for Magic Motorsport users that enables the Import and Export of Slave files within WinOLS.

With this extension, files generated by Magic Motorsport can be imported into a WinOLS project without manual conversion and, after editing, saved again in the same format.

ODX Import

ODX (Open Diagnostic Data Exchange) is a well-known automotive industry standard for exchanging diagnostic and software-related information.

The ODX Import plugin allows files based on this standard to be imported into WinOLS. This capability is primarily useful in development, engineering, and OEM environments where software information is provided in ODX format.

VBF Import / Export

VBF (Versatile Binary Format) is another format used in certain factory projects for packaging ECU software.

This plugin allows VBF files to be imported into and exported from WinOLS, eliminating the need to manually convert these files.

DCM Import / Export

DCM (Data Calibration Module) is a common format used for storing calibration information in automotive development environments.

The DCM Import / Export plugin enables this type of file to be exchanged with WinOLS, making it easier to connect WinOLS projects with other calibration tools.

Other Import / Export Plugins

In addition to the plugins mentioned above, EVC provides other extensions for supporting specialized formats and equipment, including:

1. BMW Original File Importer
2. Caterpillar FLS / FL2
3. CFF Import / Export
4. Cummins XCAL
5. EK1 Export
6. JCB Import

as well as other specialized plugins, each designed for a specific application and intended to be used only when a project involves the corresponding file format or equipment.

Map Plugins

Unlike Import / Export Plugins, whose primary purpose is to manage file formats, Map Plugins add engineering information related to the ECU calibration structure to a WinOLS project. With their help, tables, axes, and various parameters can be displayed with more detailed information within the software, making file analysis much easier.

DAMOS / A2L Import

This plugin transfers the information contained in DAMOS and A2L files into a WinOLS project. After importing, users can access information such as parameter names, axes, measurement units, conversion factors, and other engineering data.

As a result, the actual structure of the ECU calibration becomes much easier to understand, while the time required to analyze the file can be significantly reduced.

TunerPro XDF Import / Export

XDF is a map-definition format used by TunerPro.

This plugin allows XDF information to be transferred between TunerPro and WinOLS. For users who work with both software platforms, it eliminates the need to define the maps again manually.

EVC also provides other plugins for importing certain specialized formats, including:

Cummins ECFG

Mitsubishi XML

Mitsubishi MM3

PRM

This modular architecture has allowed WinOLS to remain compatible with new technologies and equipment despite its many years in the industry, while continuing to meet the needs of a wide range of users, from tuners to research and development centers.

Special Plugins, EVC Hardware and Programming Tools

So far, most of our discussion has focused on analyzing and editing ECU files. In practice, however, before WinOLS can even be opened, the ECU file itself has to be obtained first.

For many vehicles, the answer is simple: the file is read through OBD and then imported into WinOLS. However, this scenario does not always apply. Many ECUs, particularly older controllers or units that have experienced software-related problems, can no longer be accessed through OBD.

In such situations, the only way to communicate with the ECU may be through methods that directly interface with the controller's hardware.

To cover this part of the workflow, EVC has developed a range of programming and direct ECU-access tools. These products are not as widely known as WinOLS itself, but they play an important role in ECU repair, software recovery, ECU cloning, and even OEM software development.

BDM100

For many years, one of the most common methods of direct ECU access was the use of the BDM (Background Debug Mode) interface. Many ECUs based on Motorola/Freescale MPC5xx processors support this interface, and EVC developed the BDM100 specifically for this family of controllers.

Unlike OBD programming, this method requires the ECU to be opened so that communication can be established directly through the BDM points on the circuit board.

Although this process may take more time than OBD programming, it provides much more comprehensive access to the ECU's memory.

For this reason, BDM100 is more than simply a tool for reading and writing ECU files. In many situations, when an ECU no longer boots, its software has become corrupted, or information needs to be transferred from one ECU to another, BDM access can become one of the most reliable recovery methods.

According to EVC's documentation, the hardware and software design of BDM100 was developed entirely by the company itself, making it one of EVC's early specialized tools for direct ECU programming.

BdmToGo

Having hardware alone is not enough to perform ECU programming operations. Users also need an environment that allows them to communicate with the ECU and easily manage file reading and writing operations.

For this purpose, EVC provides the BdmToGo software.

This software is designed to be used with BDM100 and allows basic ECU operations to be performed without requiring the WinOLS environment. If the file needs to be analyzed or edited later, it can easily be imported into WinOLS and the rest of the process can continue there.

BSL100

With the introduction of newer ECUs based on Infineon Tricore processors, BDM alone was no longer sufficient for all controllers.

Many of these ECUs use another method for low-level memory access known as Boot Strap Loader, or BSL for short. The BSL100 tool was developed specifically for this generation of ECUs.

Like BDM, this method establishes direct communication with the ECU and does not depend on conventional OBD protocols. This has made BSL100 useful for applications such as damaged ECU recovery, ECU cloning, and full-memory programming.

An interesting point mentioned by EVC in its official documentation is that BSL100 was developed through cooperation between EVC and Frieling-Racing. The goal of this collaboration was to provide a specialized solution for Tricore-based ECU families.

BSL-ADP and BslToGo

In some Tricore-based ECUs, entering Boot Mode cannot be achieved simply by connecting a cable. Depending on the controller, a dedicated adapter may be required. For this reason, EVC provides the BSL-ADP range of adapters. These adapters simplify communication with different ECU families and help make the connection process faster, more reliable, and less prone to errors.

Alongside these adapters is the BslToGo software, which performs a role for BSL100 similar to the role BdmToGo performs for BDM100. The software manages ECU reading, writing, and programming operations through BSL. When necessary, the files can then be transferred to WinOLS for further analysis and editing.

EPROM Programmers

Today, most ECUs use internal Flash memory. However, many older vehicles stored software information on EPROM or EEPROM chips. With these ECUs, the memory chip generally has to be removed from the circuit board and placed into a programmer before it can be read or programmed.

For these types of projects, EVC provides a range of dedicated EPROM Programmers. These tools allow different types of memory chips to be read, erased, and reprogrammed. They are still useful for repairing older ECUs, recovering original software, and certain research and development projects.

EPROM Adapters

Because memory chips are manufactured in different packages and with different physical configurations, a programmer alone is not sufficient to work with every type of chip. For this reason, EVC provides a range of EPROM Adapters.

These adapters establish the correct connection between the programmer and the memory chip, allowing different types of memory to be programmed without requiring separate programming equipment.

Using the correct adapter not only simplifies the process but can also reduce the possibility of errors or damage to the memory chip.

EAD Adapter

Alongside its general-purpose adapters, EVC also provides another product called EAD (EPROM Adapter), which is designed for certain memory chips with specific structures or pin configurations.

This adapter makes it possible to connect these types of memory to compatible programming equipment.

Although its use has decreased compared with the past, it still has applications in older ECU repair, reverse-engineering projects, and certain specialized engineering applications.

Why Are These Tools Still Important?

With the development of OBD programming tools, it might seem that equipment such as BDM100 or BSL100 is no longer particularly useful. In practice, however, these tools are still required for many projects.

Whenever an ECU experiences a software problem, its information becomes corrupted or inaccessible, or communication through OBD is no longer possible, direct-access methods can often provide the most reliable solution. For this reason, these tools are still used regularly in many ECU repair centers.

In fact, EVC's goal in developing these products was not to replace OBD programmers. Instead, these tools were designed for situations where conventional programming methods are no longer sufficient and direct access to the ECU's memory is the only practical way to continue the work.

The Complete EVC Ecosystem

After becoming familiar with the different components of the WinOLS ecosystem, an important question may arise: Why does EVC offer so many different products alongside WinOLS?

If WinOLS is already such a powerful platform, what is the role of DAMOS, plugins, Checksum Modules, and hardware tools?

The answer lies in the way EVC's products are designed.

WinOLS was never intended to perform every stage of the ECU workflow on its own. From the beginning, the software was developed as the core of a larger ecosystem in which each product is responsible for a specific part of the process. Together, these products create a complete workflow.

The process begins with extracting the ECU file. Depending on the ECU and application, the file may be read through OBD, BDM, BSL, or directly from a memory chip.

The file is then imported into WinOLS, where its structure can be analyzed. Engineering information such as DAMOS or A2L can be added to the project, while different plugins can be used when communication with other file formats or equipment is required.

Finally, the appropriate Checksum Module can be used to correct the file's checksum so that the modified software remains compatible with the ECU's internal validation system.

One of the major strengths of this ecosystem is its modular structure. Users only need to acquire the tools that are relevant to their specific activities.

For example, a tuner may only need WinOLS, while an ECU development center or specialized repair facility may use WinOLS together with DAMOS, plugins, Checksum Modules, and EVC hardware.

This is what makes EVC's products complementary rather than redundant. Each tool covers a specific part of the overall process.

This systematic approach is one of the key reasons why WinOLS and the wider EVC ecosystem have remained among the most widely used solutions for ECU calibration after many years in the industry.