Aftersales
From OEM information to multi-brand workshop use
- Author
- John Bright
- Published
- Reading time
- 10 min read
A vehicle arrives with an intermittent electrical fault.
The technician may need to identify the vehicle, complete a system scan, read the Diagnostic Trouble Codes (DTCs), examine live values, find the wiring diagram, follow the test procedure and confirm the repair. If a control unit is replaced, the job may continue into coding, configuration or programming.
A dealer technician and an independent repairer may follow a similar repair sequence. The difference is the information, tools and systems available to them.
The dealer environment provides a useful starting point for understanding what an intermediary needs to support that work across several brands.
What an OEM provides within its dealer network
Dealer technicians normally work with systems designed around one manufacturer’s vehicles, terminology and repair processes. These typically include:
- an OEM diagnostic platform and compatible vehicle-communication hardware;
- service schedules, repair procedures, wiring diagrams and technical bulletins;
- VIN and vehicle-build information that selects the correct content;
- coding, configuration, calibration and programming functions;
- software files and controlled connections to OEM servers;
- verified access for security-related tasks;
- technical support, training and escalation routes; and
- user accounts, subscriptions and regular information or software updates.
For that brand, dealer technicians learn its model structure, diagnostic logic, terminology and route to support. The OEM may also manage user identity, information updates, system access and technical instructions within a defined network.
Why a multi-brand workshop is different
A multi-brand workshop must achieve comparable service and repair outcomes across vehicles from several manufacturers. Direct access to the diagnostic tools and RMI portals of every relevant OEM can become commercially prohibitive and operationally impractical. Each additional brand may require another tool, subscription, account, password, portal, terminology set and authentication process.
Australia’s 2026 Treasury review of the Motor Vehicle Information Sharing Scheme found that multi-brand repairers are likely to need brand-specific tools and subscriptions. All-makes workshops reported multiple accounts, subscription costs and substantial differences between OEM portals, while nearly half of survey respondents identified the burden of navigating multiple websites. The review also found that proprietary diagnostic hardware for several brands can be prohibitive for smaller workshops.
Technicians also spend time changing systems, finding information and interpreting different terminology for similar functions. That reduces the time available for the repair itself.
A multi-brand tool or information platform can bring common tasks into one interface, while retaining the manufacturer-specific detail needed for the repair. Building and maintaining that service is the intermediary’s work.
Intermediaries already provide a range of multi-brand products and services. These have been built through different combinations of licensed or sublicensed OEM information, published sources, and the intermediary’s own technical development and content.
Where an intermediary uses OEM source data to support a multi-brand service in a particular territory, it needs appropriate rights to receive, use, integrate and update that information for that purpose. Direct OEM licensing can therefore extend coverage, improve technical depth and make updates more efficient without replacing the intermediary product that already exists.
Diagnostics and repair information
Workshop requirements generally fall into two areas: diagnostics and repair and maintenance information.
This distinction reflects the tasks performed by technicians. It is not a universal legal classification: some legislation uses “repair and maintenance information” more broadly to include diagnosis, reprogramming and reinitialisation.
Diagnostics
Diagnostic work ranges from reading information stored in the vehicle to making controlled changes that may require communication with an OEM system.
| Workshop task | What the technician or tool may need |
|---|---|
| Vehicle and system scan | Vehicle and control-unit identification, compatible protocols and functions to read and clear DTCs. |
| Service functions | Service-interval reset, component initialisation, relearn procedures and routine maintenance functions. |
| Fault diagnosis | Live values, freeze-frame data, actuator tests, expected values, fault-code logic and test procedures. |
| Calibration and setup | Vehicle-specific prerequisites and procedures for ADAS, steering-angle or sensor calibration, component setup and adaptation. Separate calibration equipment may be required. |
| Coding and configuration | The required software function, vehicle configuration and controlled write access. |
| ECU programming | Compatible hardware and software, the correct calibration file and, where required, a live OEM connection for authentication, retrieval or information exchange. |
| Security-related work | Verified access for immobiliser, key and other restricted functions under the relevant market’s rules and authorisation process. |
A DTC identifies a reported system or condition; it does not prove which component has failed. The technician still needs to investigate the fault.
Access can also depend on the vehicle architecture. A secure gateway may allow basic information to be read while restricting active tests, coding or other higher-level functions. Some protected functions or components may require manufacturer-specific challenge-response or server-side authentication.
These controls protect cybersecurity and vehicle integrity. To complete the task, the workshop may need a compatible tool, verified user identity, an active subscription and access to the OEM service as well as the procedure.
The Treasury review distinguishes basic DTC retrieval from advanced procedures such as ECU reprogramming, module coding and system adaptation. It also explains how diagnostic platforms may need compatible protocols, secure authentication and integration with OEM or aggregator systems. The review notes that secure gateways and proprietary hardware can affect functions including ADAS calibration.
Repair and maintenance information
Repair and maintenance information supplies the instructions and specifications used throughout the job.
| Workshop task | Typical information need |
|---|---|
| Scheduled service and maintenance | Schedules, inspections, fluid specifications, adjustment values, replacement intervals and reset instructions. |
| Mechanical or electrical repair | Removal and installation procedures, tightening specifications, special tools, warnings and post-repair checks. |
| Troubleshooting | Diagnostic procedures, DTC interpretation, test sequences, expected readings and technical service bulletins. |
| Electrical diagnosis | Wiring diagrams, connector and pin details, component locations, network topology and test values. |
| Body and collision repair | Dimensions, materials, joining and sectioning methods, corrosion protection, restraint precautions and calibration requirements. |
Australian ACCC guidance for data providers gives examples including manuals, technical service bulletins, wiring diagrams, component and lubricant specifications, testing procedures, diagnostic and reprogramming software, updates and computer-system codes.
In practice, these areas overlap. A DTC may lead to a wiring diagram and guided test. Replacing the confirmed faulty component may then require coding, initialisation or calibration. An effective product supports that sequence without implying that the fault code alone is a diagnosis.
What the intermediary adds
An intermediary connects manufacturer-specific information to a shared workshop workflow. Its product may identify the vehicle, map terminology and model structures, and link a task to the relevant data or diagnostic function. It may also add its own technical guidance and service capability. Each OEM can continue operating its own dealer systems.
Standardised terminology can make multi-brand navigation easier, but it must not erase a technical difference. Two manufacturers may use different words for comparable functions; they may also use the same word for functions that behave differently. Warnings, prerequisites, sequences, units and vehicle-specific exceptions must remain clear.
An intermediary will not necessarily provide every OEM system or function. Programming, coding, VIN-specific information or protected functions may still require an OEM portal, server connection or specialist service. Its value is to make common multi-brand work easier and provide a clear hand-off when an OEM-specific system is required.
Direct workshop use and derived use
Two uses of OEM information should be distinguished.
The direct use is the product or service delivered for the immediate workshop, repair, claims or vehicle-management task. A derived use occurs when the intermediary further combines, transforms, analyses or supplies the information to create another commercial output.
| Intermediary product | Direct use | Possible derived or commercial use |
|---|---|---|
| Diagnostic product or remote service | Diagnose faults, perform service functions, access protected systems, code or program a vehicle. | Multi-brand diagnostic databases, guided diagnosis, remote-expert services, repair intelligence or AI-assisted fault analysis. |
| RMI publisher or platform | Give technicians the procedures, specifications, wiring and maintenance information needed for a job. | Normalised multi-brand databases, labour-time information, APIs, technical search or AI-assisted answers. |
| Collision or claims platform | Use repair procedures, parts information, labour operations and calibration requirements to estimate and plan a collision repair. | Estimating logic, repair-versus-replace recommendations, claims automation and repair-cost analytics. |
| Workshop or fleet platform | Identify required maintenance or repair and support quoting, approval and job completion. | Maintenance forecasting, cost analysis, automated authorisation and workflow services. |
| Service-history or vehicle-data platform | Create or retrieve a consolidated service and maintenance record. | Provenance or condition indicators, warranty checks, valuation, predictive maintenance, analytics or data services. |
These categories can overlap. From a licensing perspective, an important distinction is whether OEM information is being used to complete the immediate task, transformed into a new output, or supplied as part of another product. The original OEM information may remain a material input even when it is no longer visible to the end user.
Direct supply, onward supply and remote services
An intermediary may supply its own workshop portal or diagnostic tool. It may instead provide a dataset or controlled service to a scan-tool maker or software company, which incorporates it into another product. The licence needs to account for the proposed supply route.
Delivery may take several forms:
- a structured dataset or scheduled file delivery;
- an application programming interface (API);
- a hosted search or information-retrieval service; or
- an AI-assisted retrieval layer that helps a user find relevant source information.
AI-assisted retrieval is a way to find and present information, not a separate source of technical authority. The result still needs to match the correct vehicle and current source information.
For indirect supply, the arrangement may need to address who may receive, process and provide the information. Australia’s Treasury review recognises both direct and indirect supply by intermediaries. The review also notes that the current Australian scheme does not require OEMs to supply information directly to intermediaries, and that intermediary access is often provided through commercial licensing arrangements.
Specialist remote services
Some OEM-server-based functions, such as programming, coding, calibration or advanced diagnostics, sit outside many broad multi-brand products. A specialist remote provider can perform these tasks using the relevant OEM systems.
The workshop connects a compatible interface to the vehicle. The specialist connects remotely and completes the task, allowing the workshop to purchase the service when needed instead of maintaining access to every OEM tool itself.
This differs from a diagnostic subscription for one tool, user or workshop. A provider serving many workshops may therefore need the relevant OEM’s permission for that use. The OEM’s end-user terms or a separate agreement may set rules for authorised users, credentials, remote access, server transactions and per-vehicle or per-task charges.
Access to OEM tools for this service does not necessarily include the underlying OEM source data or permission to reuse it in another multi-brand product.
Licensing OEM source data to an intermediary
The data licence defines which OEM source information the intermediary may receive and how it may use that information in its product. A request for “all repair data” needs to be broken down into the sources, activities and permissions involved.
| Practical question | What the licence needs to address |
|---|---|
| What will the primary product or service do? | Approved diagnostic, repair, service, claims, fleet, vehicle-record or training uses. |
| What source data will the OEM provide? | Included documents, structured records, identifiers, diagnostic and protocol data, updates, feeds and APIs. |
| Which vehicles and markets are covered? | Brands, models, variants, years, systems, territories, languages and local content limitations. |
| May derived outputs be created and commercialised? | Permitted outputs such as estimates, recommendations, labour information, scores or analytics, and who may own or use them. |
| What onward supply is allowed? | Agreed API supply, sublicensing or embedding in another product, with permitted users, processors and recipients. |
| What AI use is allowed? | Separate treatment of retrieval or inference and large language model (LLM) training or fine-tuning; source display, output controls and retention. |
| Is protected information included? | Included safety or security data and technical inputs. Live access, credentials and server transactions remain separate unless expressly agreed. |
Static or structured repair information and diagnostic or protocol data can form part of a data licence. Live server transactions and restricted security functions may require separate access arrangements.
The scope of permissions and safeguards is likely to require closer consideration as use moves from information for a defined task, through aggregation and derived outputs, to downstream API supply, AI model training or redistribution of substantially equivalent OEM information. The exact risk still depends on the information, product, users, safeguards and applicable law.
The workshop requirement does not by itself establish a legal or contractual entitlement. Australia’s current scheme in Part IVE of the Competition and Consumer Act 2010 has defined scope, exclusions and controls for safety and security information. Other content, functions and onward uses may depend on commercial agreement.
European Regulation 2018/858 and the Court of Justice decisions in Case C-390/21 and Case C-319/22 illustrate how an intermediary’s role can affect permitted processing and information format. They do not determine the Australian position.
Back to the vehicle with the electrical fault. A useful multi-brand product helps the technician move from the scan to the wiring diagram, test procedure and confirmed repair, then to a separate OEM system if coding or programming requires it.
The OEM licence supports that work by defining the source information, permitted use and supply route. The intermediary’s job is to make those inputs usable across brands without losing the vehicle-specific meaning or controls needed for the repair.