ISO/AWI 17978-4 SOVD Remote Access: What Workshops Should Watch
Remote vehicle diagnostics is moving from vendor-specific portals toward a standards conversation. That is commercially important for independent workshops, but a newly approved project is easy to mistake for a finished rulebook.
Direct answer: ISO records ISO/AWI 17978-4, Service-Oriented Vehicle Diagnostics Remote Access, as an approved work item registered on August 18, 2026. Its public scope describes a standardized framework for generic clients to remotely discover, access and use diagnostic capabilities for high-performance computers and legacy ECUs. It is under development at stage 20.00, not a published International Standard. Workshops should monitor it, improve identity and audit controls now, and avoid buying equipment on claims that Part 4 already defines complete protocols, certification or access rights.
What ISO has confirmed
The ISO project page names the document, scope, edition and development stage. A working group has prepared a draft, but the text can still change through committee, enquiry, approval and publication stages. The public abstract is deliberately high level.
| Item | Confirmed public status | Practical meaning |
|---|---|---|
| Reference | ISO/AWI 17978-4 | It is an approved work item, not yet a finished standard. |
| Topic | SOVD Remote Access | The project concerns access beyond a purely local workshop connection. |
| Scope | Discovery and use of diagnostic capabilities and methods | It addresses generic clients, HPCs and legacy ECUs at framework level. |
| Approval date | August 18, 2026 | The topic is current and early in its formal lifecycle. |
| Stage | 20.00, project registered | Requirements, interfaces and timelines must not be inferred from the title. |
The correct headline is “a remote-access standardization project has started,” not “remote SOVD is finalized.” That distinction protects buyers from premature compatibility claims.
How does Part 4 fit the SOVD series?
ISO 17978-1:2026 provides the series overview, basic principles and terminology, while ISO 17978-2:2026 defines technology-independent use cases. Part 4 extends the work program toward remote access. The public page says the future framework is intended to cover both high-performance computers and legacy ECUs.
That wording matters because the vehicle fleet will remain mixed. New centralized computers, domain controllers and service-oriented endpoints will coexist with conventional ECUs reached through gateways. A useful remote workflow cannot assume that every target behaves like a cloud-native service.
ISO 14229-1:2026 remains relevant because it specifies data-link-independent UDS services for diagnostic communication with ECUs. The appearance of SOVD does not erase UDS, local pass-through devices or OEM procedures. Workshops should expect layers to coexist.
What remote access changes operationally
Identity becomes part of the toolchain
A local cable offers physical context: the technician, vehicle and interface are in the same bay. Remote access separates those elements. The system needs a trustworthy way to identify the vehicle, client, organization, user and requested function.
Authorization must be narrower than connectivity
Reaching a gateway should not imply permission to execute every diagnostic service. A mature workflow distinguishes discovery, read-only diagnosis, actuator control, coding, programming and security-sensitive functions. Authorization also needs time, vehicle state and job context.
Evidence has to cross system boundaries
A remote session may involve a vehicle-side agent, network service, identity provider, diagnostic client and workshop management system. If each keeps a different log, reconstructing a failed job becomes difficult. Clock alignment, correlation identifiers and tamper-evident records become practical service issues.
Network failure becomes a workshop risk
Local power stability remains essential, but remote workflows add latency, service availability, credentials and transport security. A read-only session and a programming session should not share the same interruption assumptions.
A readiness checklist that does not depend on draft text
- Map the actors. Identify the vehicle owner, workshop, technician, remote service provider, tool vendor and OEM service involved in a job.
- Separate permissions. Define which roles may discover, read, control, code or program each system.
- Preserve consent. Link customer authorization to the vehicle, requested work, date and responsible technician.
- Protect credentials. Use individual accounts and suitable multifactor controls rather than shared passwords.
- Record the session. Preserve start and end time, vehicle and module identity, client version, requested functions, results and failures.
- Plan interruption handling. Distinguish operations that can safely retry from programming steps that require a controlled recovery path.
- Test locally first. Validate new remote tooling on non-production systems and representative gateways before customer use.
These controls are valuable even if the final Part 4 text changes. They are basic requirements for accountable remote service, not guesses about unpublished clauses.
Questions to ask tool vendors now
- Which ISO 17978 parts are implemented, and which are only on the roadmap?
- Is “SOVD compatible” based on a published standard, a draft or a proprietary interpretation?
- How are user, organization, client and vehicle identities bound together?
- Can permissions be limited by diagnostic function and vehicle state?
- Where are session logs stored, and can the workshop export them?
- What happens if connectivity fails during a write or coding operation?
- Does the system support local fallback or documented recovery?
- How are legacy ECUs reached without overstating their native capabilities?
A vendor should be able to answer without suggesting that an early-stage work item is already a certification program. ISO's public page does not describe conformance testing, licensing terms, cybersecurity profiles or a publication date.
Remote access is not the same as unrestricted access
Standardized discovery and service use do not automatically settle who is legally entitled to reach a vehicle, which functions an OEM must expose or how national repair-information rules apply. Those questions involve contracts, cybersecurity, privacy, safety and regional law.
Workshops should keep four boundaries visible:
| Boundary | Question |
|---|---|
| Technical | Can the client reach and correctly invoke the diagnostic capability? |
| Security | Is the requester authenticated and authorized for that operation? |
| Legal | Is the access permitted by owner consent, regulation and contract? |
| Operational | Can the workshop complete or recover the job safely? |
A yes in one column does not answer the others.
What this means for ECU programming shops
KT200II and similar programmers primarily serve local OBD, bench, boot, BDM or JTAG workflows. A future SOVD remote framework does not convert those tools into remote OEM programming platforms. The immediate relevance is architectural: newer vehicles may expose diagnostic capabilities through centralized computers and controlled gateways, while the target ECU still uses familiar services behind that layer.
Shops should maintain both capabilities. Keep local recovery, stable power, original-file backups and physical interfaces strong. At the same time, build account management, audit records and network resilience for authorized remote services.
What the work item does not tell us
- It does not provide a final protocol that a workshop can implement today.
- It does not publish detailed security or authorization requirements on the public page.
- It does not guarantee access to any specific vehicle or OEM function.
- It does not define a commercial certification for current tools.
- It does not replace UDS, DoIP, CAN, J2534 or physical ECU recovery methods.
Any product claim that goes beyond those limits needs separate evidence.
Frequently asked questions
Is ISO 17978-4 already published?
No. ISO lists it as an approved work item at stage 20.00. A draft exists within the working group process, but it must progress through later development stages before publication as an International Standard.
What is the confirmed scope?
The public abstract describes a standardized framework for generic clients to remotely discover, access and use vehicle diagnostic capabilities and service-oriented methods for high-performance computers and legacy ECUs. Detailed requirements are not public on the project page.
Will it replace UDS?
There is no basis for that conclusion. ISO 14229-1:2026 remains the published application-layer standard for UDS services. SOVD can provide a service-oriented layer while vehicles continue using established diagnostic services and transports underneath.
Does this give independent workshops guaranteed remote access?
The public project scope does not grant legal access rights. Actual access will still depend on implementation, authorization, cybersecurity controls, owner consent, OEM systems and applicable regional law.
Should I buy a tool advertised as Part 4 compliant?
Ask what the claim means. Because Part 4 is an early-stage work item, request the implemented specification, version, tested functions and evidence. Avoid treating a roadmap statement as conformance to a finished International Standard.
What can a workshop do today?
Strengthen individual accounts, multifactor authentication, consent records, exported session logs, network resilience and recovery planning. Those controls improve current remote support and remain useful while the standard develops.
Conclusion
ISO/AWI 17978-4 signals that remote, service-oriented vehicle diagnostics has entered a formal standardization path. The opportunity is real, but the document is still early; disciplined identity, authorization, evidence and recovery matter more today than speculative compatibility badges.
For related context, review the ECUToolStore introduction to ISO 17978-1 and the workshop guide to DoIP. Subscribe to ECUToolStore News for updates as the Part 4 project advances.