ECU remapping developed from your original software.
We develop ECU software for workshop orders using WinOLS. The original file, control-unit identification and vehicle specification define the starting point. Requested changes are considered as a complete calibration.
On this page4 topics ⌄Original software and the actual vehicle configuration define the calibration work.
01
Maps work together
Load requests, torque management, injection, boost and ignition where applicable affect one another. The relevant maps depend on the ECU architecture. Raising one limit alone does not describe a complete engine calibration.
02
Choose the work around the vehicle
Stage 1 is intended for a suitable stock configuration. For changed components, provide the hardware specification and fuel. Individual functions, Mapswitch and extensive conversions need an agreed development scope.
Submit the original software, identification, tool and requested changes in the portal. Processing takes 15–30 minutes on average. Questions or individual development can require more time. The version and job details remain linked for download and subsequent feedback.
A file comparison documents software changes. Diagnosis and relevant measurements assess the result at the vehicle. Development or reference measurements do not replace checks on each customer vehicle. Agree on the measurements needed for your order.
A useful remapping request describes where the customer wants a change: response in a particular driving mode, torque delivery through the working range, or calibration for documented component upgrades. Explain what already works and what needs attention. This helps distinguish an adjustment to driving characteristics from a project that needs a different hardware specification.
Include relevant constraints, such as the fuel the customer will actually use, the existing transmission and the intended operating conditions. Agree which observations will be used to review the result. A clear brief gives the workshop and development team a common reference when they discuss the first delivered version.
02
Keep software identity separate from the vehicle badge
Vehicles sold under the same model and engine description can have different software revisions. A manufacturer update or a previous workshop intervention may also change the starting point. Use the identification produced by your tool, rather than choosing a file because the model, year and nominal output look familiar.
If the readout may already contain tuning, say so before development begins. Retain that readout and explain what is known about the vehicle history. A stock file supplied by a virtual-read service and a normal read of modified software describe different starting situations; neither should be relabelled to make the order appear simpler.
The most useful feedback relates to the operating conditions agreed for the job. Depending on the project, those may include progressive acceleration, changes in load or a particular engine-speed range. Record the conditions and the active driving mode. A maximum-output figure alone cannot explain how the vehicle responds throughout that range.
Requested and actual values can help development assess a specific question, provided the channels, units and time axis are clear. Ask which measurements are useful before recording large quantities of data. A shorter, relevant recording is easier to interpret than a file containing many unrelated channels at an unsuitable recording rate.
A ready-to-write tuning file contains the software work agreed for a vehicle. A DAMOS description or WinOLS MapPack supports the interpretation of software data; it does not become a finished calibration simply because it includes familiar map names. The correct choice depends on whether you need file development or definitions for your own analysis.
For a definition enquiry, send the original BIN or ORI and the ECU identification. For a remapping order, describe the vehicle and requested result as well. Keeping these enquiries distinct avoids confusion over the deliverable and allows the required software match to be checked before work is confirmed.
Close the job with an identifiable delivered version
Keep the final file, order reference and workshop observations together. Record any changes to hardware or fuel that took place during development. If the customer later returns with a different configuration, that record explains which conditions the previous software was prepared for and prevents an old assumption from carrying into a new request.
The same discipline is useful when selecting a file service for recurring work. You need an understandable route from the supplied software to the delivered version, a defined communication channel and a way to submit technical feedback. Our overview of tuning files explains how these parts fit together.
