From OEM information to multi-brand workshop use

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.

The underlying service and repair task may be similar, whether it is performed in a single-brand workshop, such as an OEM dealership, or in a multi-brand workshop, such as an independent repairer. What differs is the information, tools and systems available to complete it.

To understand why an intermediary requests OEM information—and what an OEM may need to license—it helps to begin with the environment already available to the OEM’s dealer network.

WHAT MATTERS

• A dealer environment combines information, diagnostic functionality, software, vehicle identification, security controls and support—not just documents.
• A multi-brand intermediary creates a common layer across many manufacturer-specific environments.
• The OEM licence needs to describe the source information and the uses, recipients, territory and delivery model that the intermediary is actually supporting.

What an OEM provides within its dealer network

Within an OEM dealer network, technicians working on that manufacturer’s vehicles normally use a manufacturer-specific operating environment. The components may be delivered through several systems, but they are designed to support the same vehicles, terminology and repair processes.

• 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.

This is more than a collection of documents. It is a combination of technical information, diagnostic functionality, software, vehicle identification, security controls and support services.

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.

The cost is only part of the problem. Technicians must repeatedly change systems, remember how each interface works and translate different terminology for similar functions. Time spent navigating portals and confirming where to find information reduces productive workshop time.

For many multi-brand workshops, a practical solution is a multi-brand tool or platform that provides diagnostic functions and repair information through a common user interface while preserving the OEM-specific differences that matter to the repair. A workshop cannot create that common layer simply by subscribing to separate OEM systems. It requires an intermediary operating across brands.

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.

For each job, a workshop needs the correct information and functions for that vehicle. An intermediary must deliver that result consistently across many brands and users.

Two primary types of workshop information and access

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.

1. Diagnostics

Diagnostics is not one function. It ranges from reading information already stored in the vehicle to carrying out controlled changes that may require communication with an OEM system.

Workshop task	What the technician or tool may need
Vehicle and system scan	Correct vehicle and control-unit identification, communication protocols and the ability to read and clear DTCs. A DTC indicates the system or condition that reported a fault; it does not by itself prove which component has failed.
Service functions	Functions such as service-interval reset, component initialisation, relearn procedures and other routine maintenance operations.
Fault diagnosis	Live or actual values, freeze-frame data, actuator or functional tests, expected values, fault-code logic and links to test procedures or guided troubleshooting.
Calibration and setup	Vehicle-specific prerequisites and procedures for tasks such as ADAS calibration, steering-angle or sensor calibration, replacement-component setup and system adaptation. Some tasks also require separate calibration equipment.
Coding and configuration	The correct software function, vehicle configuration and controlled write access to code a module or configure a replacement component.
ECU programming	Compatible hardware and software, the correct calibration file and, where required, a live connection to an OEM server for authentication, software retrieval or information exchange during the programming event.
Security-related work	Verified access for restricted functions such as immobiliser, key or other anti-theft work, subject to the rules and authorisation process applying in the relevant market.

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 have a legitimate cybersecurity and vehicle-integrity purpose. Operationally, however, they mean that possessing a scan tool and knowing the procedure may still not be enough to complete the task. The tool, vehicle, user identity, subscription and OEM service may all need to work together.

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.

2. Repair and maintenance information

The second area is the information a technician reads or follows to service, diagnose, repair and restore the vehicle correctly.

Workshop task	Typical information need
Scheduled service and maintenance	Service schedules, inspection requirements, fluid grades and capacities, adjustment values, replacement intervals and reset instructions.
Mechanical or electrical repair	Removal and installation procedures, tightening specifications, special-tool requirements, warnings and post-repair checks.
Troubleshooting	Symptom-based or guided diagnostic procedures, DTC interpretation, test sequences, expected readings and technical service bulletins.
Electrical diagnosis	Wiring diagrams, connector views, pin assignments, component locations, network topology and test values.
Body and collision repair	Body dimensions, material identification, joining and sectioning methods, corrosion protection, restraint-system 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.

Why intermediaries play an important multi-brand role

No individual OEM system is designed to provide a common workflow across other manufacturers’ vehicles. Intermediaries already provide that multi-brand layer without asking each OEM to redesign its dealer systems.

For a workshop servicing several brands, this is often the most practical and scalable way to reduce the number of separate interfaces and processes technicians must use. Across different products, an intermediary commonly identifies the vehicle, maps OEM terminology and model structures, presents information through a consistent interface, and links workshop tasks to the relevant data or diagnostic function. It may also add its own workflow logic, technical guidance or service capability.

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.

Intermediaries can supply workshops directly or through another provider

The workshop-facing product is not always supplied by the business that first receives or processes the OEM information.

One intermediary may license and standardise information, then supply it directly through a multi-brand portal or diagnostic tool. Another may supply an aggregated dataset or controlled service to a scan-tool maker, software company or digital platform, which incorporates it into its own workshop solution.

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 purpose of the data licence is to allow the intermediary to receive OEM source information and use it within its multi-brand product. It cannot be defined effectively through a general description such as “all repair data”. The licence must identify the source data being supplied and the permitted uses within the intermediary’s product.

Practical question	What the licence needs to address
What will the primary product or service do?	The approved diagnostic, service, repair, claims, fleet, vehicle-record or training use cases.
What source data will the OEM provide?	The specific source documents, structured records, identifiers, diagnostic datasets, protocol information, update files, feeds or APIs included in the arrangement.
Which vehicles and markets are covered?	Brands, models, variants, model years, systems, territories, languages and any market-specific content limitations.
May derived outputs be created and commercialised?	Whether OEM information may be combined with other inputs to create estimates, recommendations, labour information, scores, forecasts, analytics or other outputs, and who owns or may use them.
What onward supply is allowed?	Whether information or derived outputs may be supplied through an API, sublicensed or embedded in another provider’s product, including permitted users, processors and recipients.
What AI use is allowed?	AI-assisted retrieval or inference should be distinguished from using OEM information to train or fine-tune an artificial intelligence large language model (LLM), with separate rules for source display, output controls and retention.
Is protected information included?	Whether safety- or security-related data or technical inputs supporting protected functions are included. Live access, user 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.

An intermediary’s role is not simply to place OEM documents behind another login. It is to take defined elements of the OEM information environment and make them practical to use across several brands, while preserving the source, technical meaning and controls that matter.

For the OEM, the data licence creates a defined route from its source information into the intermediary’s product. For the workshop, the resulting product can reduce unnecessary changes of tool, portal, terminology and workflow while retaining separate access to OEM-specific systems where the repair requires them.