A custom project needs more than a target power figure. Original software, components, fuel, operating conditions and measurements define the development brief.
On this page3 topics ⌄
01
Supply a complete configuration
Include engine and control-unit identification, original files, reading method, hardware changes and intended use. Explain the target behaviour and any current faults. Clarify support for the exact data version.
02
Consider interacting systems
Torque management, load, fuelling and limits influence one another. Where the transmission is involved, include the TCU identification and engine configuration. Software changes do not establish mechanical capacity.
Discuss the logs or measurements needed for the project. Record the file version and test conditions so that feedback can be associated with a specific change. Feasibility and effort are assessed from the actual brief.
Define the project as a set of reviewable requirements
Describe the behaviour to be changed and the conditions in which the workshop will assess it. A request may concern delivery through an operating range, integration of documented component upgrades or a specific supported function. Explain the purpose of each requirement so that development can discuss the scope before the first file is prepared.
State relevant constraints as clearly as the target. These may include the fuel the vehicle will use, the installed transmission and the configuration that must remain part of the project. If the brief contains competing expectations, resolve them in the technical discussion rather than leaving development to infer the priority.
02
Give hardware changes enough detail to identify the setup
A component list should distinguish the installed versions where that information is relevant to the request. Include supporting specifications and workshop observations instead of describing the vehicle only as Stage 2 or Stage 3. The stage name gives context, but it does not explain the complete hardware or the data available for development.
Keep the list current throughout the job. If a component is changed after the first delivery, identify it before requesting another revision. This avoids comparing observations from different configurations as though only the software had changed and helps establish which previous findings remain useful.
Organise files and measurements around the development question
Send the appropriate original readout with ECU and, where relevant, TCU identification. Label the tool, protocol and file source. Keep recovery material distinguishable from the working data, and explain known previous tuning. That record lets development understand the starting point without guessing from filenames or screenshots.
Agree the measurements needed for each question before testing. Preserve the raw data, units, timing and conditions, together with the written version being assessed. A graph or screenshot may highlight an observation, but it should not replace the underlying recording when the sequence or surrounding conditions are important.
A supported Mapswitch project needs a description of the proposed calibration variants and the intended switching arrangement. Check the existing supported-ECU list and discuss the specific software before promising a function. Availability of a familiar ECU family elsewhere in the service catalogue is not an approval for every variant.
Definitions are a different deliverable. If the project needs a DAMOS file or WinOLS MapPack, provide the original BIN or ORI and specify the format and coverage being requested. CSV and JSON enquiries also need an agreed structure. Keep these requests separate from the finished calibration files supplied for writing.
A revision should address an identifiable observation or agreed development requirement. Explain what the current version does, what was tested and which part of the brief remains open. If the result points to another workshop check or missing information, record that before asking for further software changes.
At completion, retain the supplied starting data, final version and relevant workshop findings together. This provides a useful handover record and a basis for future changes to the vehicle. An individual project can then be understood through its configuration and development decisions, rather than only through its final filename.
