Emissions-related software: clarify scope and permitted use.
Software requests involving AdBlue, DPF or EGR require a defined technical brief and a permitted application. They are not a substitute for diagnosing a defective vehicle.
On this page3 topics ⌄
01
Start with diagnosis and identification
Provide the exact control-unit data, fault information and vehicle configuration. Investigate the technical cause before requesting software changes. A fault code by itself does not describe the complete system behaviour.
02
Clarify the application before ordering
These topics are presented for appropriately permitted applications such as specific motorsport, export or non-road projects where applicable. Do not assume that a software change is legal for public-road use; establish the requirements for the actual vehicle and jurisdiction.
03
Confirm availability and the order
The option catalogue lists separate prices. Confirm scope, software support and permitted use with the team before uploading. The workshop retains responsibility for vehicle assessment and checks.
An enquiry labelled AdBlue, DPF or EGR does not explain the condition of the vehicle or the proposed work. Include the controller identification, relevant diagnostic findings and the workshop's description of the system behaviour. Distinguish an existing fault from a separate software-development request so the intended scope can be assessed.
Where the customer reports intermittent symptoms, record the conditions under which they occur. Attach useful diagnostic context rather than only a list of codes without explanation. The file-service discussion should begin with an identified vehicle and a defined application, not with an assumption that every fault can be resolved by changing software.
02
Clarify intended use before requesting file work
Tell the team where and how the vehicle or machine will operate, and which requirements apply to that application. A description such as export, competition or non-road use is not by itself proof that a proposed modification is permitted. The responsible workshop must establish the requirements for the actual case.
For example, official UK guidance explains that removing a DPF will almost invariably make a vehicle illegal for road use. International customers therefore need to consider their own jurisdiction and application rather than treating the availability of an option as authorisation to use it. Discuss the case before placing a software order.
Provide the original file from the supported reading procedure, the ECU or relevant controller identification and the tool details. Include known earlier changes and explain whether the supplied software is a normal read or a matched virtual-read file. This allows the data source to be understood before any development scope is agreed.
Do not substitute a file from another vehicle with the same engine description. A different software revision or configuration can make an apparently familiar file unsuitable for the job. Preserve the original readout and any documented recovery data separately from working copies and attachments being prepared for technical review.
A clear order states the controller involved, the permitted application and the work being requested. Where several functions are mentioned, have them assessed individually rather than describing them as an automatic package. Scope and availability depend on the software and the technical information supplied.
Ask which diagnostic or measurement information is needed to review the result. The absence of a displayed fault is not a complete description of system operation. Keep the delivered version, workshop findings and relevant observations associated with the same order so that any later question has a documented starting point.
Review current pricing after technical scope is clear
The option list and prices are maintained in the central price list. Check the required service and any additional work there, then confirm the actual order through the portal. A price entry describes a commercial option; it does not confirm software support or the permitted use of a particular vehicle.
If a revision is requested, explain the observed behaviour and attach the relevant material in the existing order. State any hardware or software changes made since the first enquiry. Keeping that history together helps the team distinguish a question about the delivered data from a new technical case.
