WinOLS Guide (6/10): Writing Your Own WinOLS Mappacks

If you’ve been tuning ECU files with WinOLS, you’ve almost certainly used someone else’s mappack. Mappacks are the backbone of efficient WinOLS workflows — they save hours of manual map identification on every project. But relying entirely on third-party mappacks limits you. Learning to write your own mappacks transforms you from a consumer of map definitions into a self-sufficient tuner who can tackle any ECU file, including those for which no public mappacks exist.

Why Create Your Own Mappacks?

There are several compelling reasons to invest time in creating your own map definitions:

• Coverage gaps — public mappacks don’t exist for every ECU type and software version. If you encounter a new or uncommon ECU, you’ll need to define maps yourself.
• Quality control — third-party mappacks vary wildly in quality. Some contain mislabelled maps, incorrect scaling, or missing axis definitions. Your own mappacks are as accurate as your analysis.
• Completeness — most shared mappacks include only the “big” tuning maps (IQ, boost, torque limiters). You may need maps for EGR, DPF, speed limiters, diagnostic thresholds, or other parameters that aren’t commonly included.
• Intellectual property — a comprehensive, well-maintained mappack library is a significant professional asset. It represents hundreds of hours of analysis work.
• Community contribution — if you’ve benefited from shared mappacks, creating and sharing your own is how you give back to the tuning community.

Structure of a Mappack File

A WinOLS mappack (typically saved with a .kp extension) is a binary file that contains a collection of map definitions. Each definition includes:

• Map name — a human-readable identifier (e.g., “Injection Quantity Limit — Smoke”)
• Signature/pattern bytes — a sequence of bytes surrounding the map in the binary that WinOLS uses to locate it when applying the mappack to a different file
• Address offset — the position of the map data relative to the signature pattern
• Data type — 8-bit unsigned, 16-bit signed, 16-bit unsigned, 32-bit, etc.
• Byte order — HiLo (big-endian) or LoHi (little-endian)
• Dimensions — number of rows and columns (1×N for a curve, M×N for a table, 1×1 for a scalar)
• X-axis definition — address, data type, scaling factor, offset, unit (e.g., “RPM”)
• Y-axis definition — same as X-axis but for the vertical axis
• Value scaling — factor and offset to convert raw data to physical values (e.g., raw × 0.01 = mg/stroke)
• Value unit — the physical unit of the map values (e.g., “mg/str”, “mbar”, “°CrkA”)
• Map folder/category — optional grouping (e.g., “Fuel System”, “Turbo Control”)

The signature pattern is the key mechanism that makes mappacks portable across software versions. Rather than storing a fixed memory address (which changes between ECU software versions), the mappack stores a unique byte pattern found near the map. When applied to a new binary, WinOLS searches for this pattern and calculates the map’s position relative to where the pattern was found.

Step-by-Step Mappack Creation

Step 1: Build a Complete Map Set in a Reference Project

Start with a clean project based on a binary file for which you have thorough knowledge of the maps:

1. Open the .bin file in WinOLS and create a new project.
2. Identify maps using any combination of Damos/A2L import, existing mappacks, comparison against tuned files, and manual search.
3. For every map you identify, set its properties completely (this is the most important step for mappack quality). Right-click the map and select Properties.

Step 2: Set Map Properties Thoroughly

For each map, configure the following in the properties dialog:

Name

Use a clear, descriptive name that follows a consistent convention (see naming conventions below). The name is the first thing you and other users will see, so it must unambiguously identify what the map does.

Address and Dimensions

Verify the start address, number of columns (X-axis breakpoints), and number of rows (Y-axis breakpoints). If the map looks fragmented or has obvious artefacts at the edges, the dimensions are probably wrong. Adjust the column/row count until the 3D surface view shows a clean, coherent shape.

Data Type and Byte Order

Confirm the correct data type. Most ECU maps use 16-bit unsigned integers, but some maps (especially temperature-related ones) use 8-bit or signed formats. Verify byte order matches the ECU architecture (Bosch ECUs on Tricore/C166 typically use big-endian/HiLo; Siemens/Continental on Tricore may vary).

Axis Definitions

For each axis, set:

• Address — where the axis breakpoint values are stored in the binary
• Data type — usually matches the map data type but not always
• Scaling factor and offset — to convert raw values to physical units. For example, if raw axis values are 500, 1000, 1500, 2000 and these represent RPM directly, factor = 1.0 and offset = 0. If raw values are 50, 100, 150, 200 and represent RPM × 10, factor = 10.0.
• Unit label — “rpm”, “mg/str”, “%”, “mbar”, “°C”, etc.

Value Scaling

Set the factor and offset for the map values themselves. This is critical for usability — a map showing raw values of 16384 is meaningless, but the same map with factor 0.0046875 showing 76.8 mg/stroke is immediately interpretable. If you have a Damos or A2L file, use the conversion formulas it provides. Otherwise, cross-reference against known physical values (e.g., stock boost pressure should be around 1500–2200 mbar for a typical turbo diesel).

Category/Folder

Assign each map to a logical category. This keeps the map list organised when dealing with mappacks that contain dozens or hundreds of maps. Common categories:

• Injection / Fuel System
• Turbo / Boost Control
• Torque Management
• Ignition (petrol)
• Emissions (EGR, DPF, SCR)
• Speed / Rev Limiters
• Diagnostics / Monitoring
• Thermal Protection

Step 3: Export the Mappack

Once all maps in your project have complete, verified property definitions:

1. Go to Maps → Export maps as mappack
2. Select which maps to include (typically all identified maps, or a filtered subset)
3. Choose the signature length — WinOLS will ask how many bytes of surrounding context to include as the search pattern. Longer signatures are more specific (fewer false matches) but less tolerant of software version differences. A signature length of 32–64 bytes is usually a good balance.
4. Save the mappack file (.kp)

WinOLS automatically generates the signature patterns based on the data surrounding each map in your reference binary. These patterns are what allow the mappack to be applied to other binaries of the same ECU family.

Step 4: Test the Mappack on a Different File

Before distributing your mappack, test it on at least one other binary file of the same ECU type (preferably a different software version):

1. Open the second binary as a new project.
2. Apply your mappack via Maps → Search for maps using mappack.
3. Check the match results — how many maps were found with high confidence (green)?
4. For each matched map, verify that the data looks correct: axis values make sense, map values are in physically plausible ranges, and the 3D surface has the expected shape.
5. If some maps don’t match or match incorrectly, adjust the signature patterns or try different signature lengths.

Sharing Mappacks Between Projects

One of the most powerful aspects of mappacks is cross-project portability. A well-crafted mappack for a Bosch EDC17C46 ECU can work across dozens of different software versions used in multiple vehicle models sharing that ECU platform. Here’s how to maximise compatibility:

• Choose signatures from stable regions — the bytes immediately surrounding a map sometimes change between software versions (especially if the map itself moves). The signature should come from a region that is consistent across versions, such as nearby code sections or constant data structures.
• Test across multiple versions — validate your mappack against as many different software numbers as possible for the same ECU type.
• Handle partial matches gracefully — it’s normal for some maps to not match on every version, especially if a particular software variant has a different map structure (e.g., a map was added, removed, or resized in a specific update).
• Version your mappacks — when you improve or expand a mappack, save it with a version number (e.g., EDC17C46_2.0TDI_CUNA_v3.kp) so you can track changes over time.

Best Practices for Map Naming Conventions

Consistent naming is crucial for usability, especially when mappacks are shared between tuners. Adopt a convention and stick to it:

Avoid vague names like “Map 1”, “Unknown table 3”, or “Important map”. If you’re unsure what a map does, name it descriptively based on what you can observe: “16x16 table at 0x7A200 — load x RPM — values 0–2500”. This is more useful than a guess that might be wrong.

Handling Multiple ECU Software Versions

Real-world tuning means encountering many different software versions of the same ECU. A single engine/ECU combination (e.g., BMW B47 with Bosch EDC17C50) can have dozens of software calibration numbers across model years, markets, and updates. Strategies for managing this:

• One master mappack per ECU family — maintain a single comprehensive mappack for each ECU type (e.g., one for EDC17C50_B47). Update it whenever you encounter a new software version.
• Document software version compatibility — keep a text file or spreadsheet listing which software numbers you’ve validated the mappack against and the match rate for each.
• Create version-specific supplements — if a particular software version has maps at unusual locations, create a small supplementary mappack rather than forking the entire master mappack.
• Use longer signatures for broad compatibility — when you need a mappack to work across many versions, longer signature patterns (64–128 bytes) that include code references tend to be more stable than shorter patterns anchored in adjacent calibration data.

Testing and Validating Your Mappack

A mappack is only useful if it reliably identifies the correct maps. Validation should be thorough:

1. Apply to the source project. Export the mappack from your reference project, then re-import it into the same project. All maps should match at 100% confidence to the same addresses. If any don’t, the signatures are not unique enough.
2. Apply to a known different version. Use a second binary of the same ECU type. Manually verify each matched map — correct axes, correct values, correct shape.
3. Compare against a tuned file. If you have a tuned file for the second binary, the maps identified by your mappack should show changes in the expected parameters (boost, IQ, torque limits, etc.).
4. Check for false positives. A map that matches at the wrong address is dangerous — you could edit the wrong parameter without realising. Review any map where the values or axes seem slightly off compared to the reference project.
5. Stress test with an unrelated ECU. Apply the mappack to a completely different ECU type — it should match zero or very few maps. If it matches many maps, the signatures are too generic and will produce false positives.

Tips for Building a Reusable Mappack Library

Over time, a well-maintained mappack library becomes one of your most valuable professional assets. Here are tips for building one:

• Start with the ECU types you see most often. If 60% of your work is Bosch EDC17 variants, invest your mappack development time there first.
• Build incrementally. You don’t need to identify every map in one session. Add maps to your mappack as you encounter and verify them across projects.
• Maintain a changelog. When you update a mappack, note what was added, changed, or corrected. This is especially important if you share mappacks with colleagues.
• Back up your mappack library. Store mappacks separately from project files and include them in your backup routine. Recreating a mappack from scratch after data loss is painful.
• Cross-reference with Damos when possible. If you later obtain a Damos or A2L for an ECU you’ve already mapped manually, compare your definitions against the OEM data. This validates your work and may reveal maps you missed or misidentified.
• Standardise your naming across all mappacks. Whether you’re working on a Bosch EDC17, a Siemens SID, or a Denso ECU, use the same naming convention so that “IQ Limit — Smoke” always means the same thing regardless of ECU platform.

Next in the Series

WinOLS Guide (7/10): Multi-Map Editing & Understanding Linked Maps will explain how ECU maps are interconnected — why editing one map often requires editing others, and how to trace the dependencies from driver demand through torque, fuel, air, and protection systems. Stay tuned.

If you don’t have the time or expertise to tune files yourself, upload your original ECU file to fileservice24.at and receive your professionally modified file in about 60 seconds.