ISO 11898-2:2026 High-Speed CAN: What ECU Workshops Should Review

ISO 11898-2:2026 is the fourth edition of the high-speed Controller Area Network physical medium attachment standard, published in May 2026. ISO’s public abstract says it covers high-speed PMA variants, including options related to low-power operation, selective wake-up, signal improvement capability and a FAST mode described in an annex. It explicitly places the physical medium dependent sublayer outside the document’s scope. For an ECU workshop, the practical takeaway is not “replace every CAN tool.” It is to verify what each interface, breakout box, transceiver and measurement process actually supports before diagnosing newer networks or blaming software for a physical-layer problem.

This article stays within ISO’s public metadata and does not reproduce the standard. Exact conformance requirements require access to the published document and qualified engineering review.

What is confirmed about ISO 11898-2:2026?

The official ISO 11898-2:2026 page lists Edition 4, publication date May 2026 and stage 60.60. The lifecycle records publication on May 21, 2026 and shows that the 2024 edition was withdrawn.

The page does not say that every vehicle implements every option. It also does not state that an existing diagnostic interface is unsuitable merely because a new edition exists. Vehicle architecture, transceiver implementation and the tool’s intended operating mode still determine what is required.

Where does Part 2 sit in the CAN stack?

It helps to separate three layers that workshops often call simply “CAN.”

ISO 11898-1 covers data link and physical coding

ISO 11898-1:2024 covers the CAN data link layer and physical coding sublayer. Its public page describes implementation options involving Classical CAN, CAN FD and CAN XL. That is different from Part 2’s PMA focus.

ISO 11898-2 addresses the high-speed physical attachment

The PMA is where the abstract bits become electrical behavior through a transceiver implementation. A workshop does not need to design a transceiver to benefit from this distinction. It simply needs to recognize that corrupted communication can originate below the diagnostic protocol.

DoCAN adds diagnostic transport and network services

ISO 15765-2:2024 defines transport and network-layer services for diagnostics over CAN-based vehicle networks and supports the abstract service interface associated with UDS. Its public note also says that the document does not decide whether CAN CC, CAN FD or both are required by other standards that reference it.

In plain workshop terms: UDS describes diagnostic services, DoCAN carries diagnostic messages across CAN networks, Part 1 defines core CAN link behavior, and Part 2 addresses the high-speed physical attachment. A fault at one layer can look like a fault at another unless the test plan separates them.

What should workshops review in their equipment?

Start with documentation, not assumptions. Ask each tool or interface supplier for precise support statements:

• Which CAN frame families and physical-layer modes are supported?
• Does the statement apply to diagnostics, ECU programming, logging or engineering measurement?
• Which hardware revision and firmware version were evaluated?
• Is support limited to a specific connector, adapter or vehicle cable?
• Can the interface identify or report the active network mode?
• What are the supported recovery and error-reporting behaviors?
• Which standard edition does the supplier reference?

A label such as “CAN FD compatible” is not a complete answer to a Part 2 question. Conversely, the existence of SIC or FAST mode in the standard does not prove that a vehicle in the workshop uses it.

For a broader interface comparison, the J2534, DoIP and CAN FD workshop guide explains why transport, physical connection and software authorization should not be treated as interchangeable.

A diagnostic workflow for suspected physical-layer problems

1. Define the symptom. Record whether the problem is no communication, intermittent communication, programming interruption, wake-up failure or errors under a specific vehicle state.
2. Identify the network and target. Use authoritative vehicle information to determine which bus and controller are involved. Do not infer the network generation from model year alone.
3. Record tool capability. Capture interface hardware, firmware, driver and application versions, plus the supplier’s documented network support.
4. Check the basic physical condition. Inspect connectors, harness damage, corrosion, prior repairs and accessory installations without probing unverified pins.
5. Compare with a known-good process. Confirm the same tool and cable can perform an appropriate, authorized operation on a supported system. Do not turn a customer vehicle into a tool-development experiment.
6. Separate power-state behavior. Note whether the network is awake, entering low power or being selectively awakened. Avoid repeated cycling that conflicts with OEM procedures.
7. Escalate measurements responsibly. Use equipment and test points approved for the exact vehicle. Measurement bandwidth, loading and grounding can change what is observed; follow OEM and instrument instructions.
8. Preserve logs and stop conditions. Save timestamps, error messages and vehicle state. Stop if communication becomes unstable during a programming operation or if the test requires unknown connector access.

Why can a physical-layer issue resemble a software problem?

A diagnostic application sees messages and timeouts, not the complete physical cause. A marginal connector, unsuitable interface, sleeping network or transceiver mismatch can appear as a failed session, negative response or dropped programming transfer. Reinstalling software may change timing and temporarily change the symptom, but it does not prove the software was the root cause.

The reverse is also true: a valid physical link does not prove that the application, authorization or protocol selection is correct. Good troubleshooting moves from evidence to layer, rather than changing several variables at once.

What changes for ECU programming?

Programming places different demands on a diagnostic path than a short fault-code scan. The session lasts longer, the vehicle may change power states, and an interruption can leave the target needing recovery. Before a job on a newer network, verify the programmer, interface, adapter, cable, workstation and vehicle procedure as one system.

• Confirm the exact ECU and vehicle support entry.
• Use the current licensed software and approved interface firmware.
• Preserve the original file or authorized update package.
• Follow the vehicle-maker power-state and access procedure.
• Record the recovery route before writing.
• Do not assume a protocol name proves physical-layer compatibility.

The ISO 14229-1:2026 UDS workshop article is useful related reading because it addresses diagnostic services at a different layer. Keeping these layers separate makes tool selection and fault escalation clearer.

What should not be claimed from the new edition?

ISO 11898-2:2026 does not, by itself, prove that a workshop tool is compliant, that a vehicle uses every named capability or that a network fault is caused by outdated hardware. It also does not certify an ECU programmer, provide vehicle pinouts or replace OEM service information.

A workshop should avoid marketing claims such as “fully ISO 11898-2:2026 compliant” unless the scope, hardware version, assessment method and evidence are documented. Ask whether the claim concerns a transceiver component, an interface, a complete toolchain or a vehicle implementation.

Frequently asked questions

Is ISO 11898-2:2026 officially published?

Yes. ISO lists Edition 4 as published in May 2026 at stage 60.60, with a publication lifecycle date of May 21, 2026. The 2024 edition is shown as withdrawn.

Does the standard mean older CAN tools will stop working?

No. The new edition does not automatically invalidate every existing tool. Suitability depends on the network used by the vehicle, the required operation and the documented capabilities of the interface hardware and firmware.

What is signal improvement capability?

ISO’s public abstract names SIC mode as a PMA capability covered by the document. Detailed electrical requirements belong to the standard itself. Workshops should ask suppliers for exact support evidence rather than relying on a marketing abbreviation.

Is CAN FD the same as high-speed CAN PMA?

No. CAN FD is a frame-format and data-rate capability addressed within the wider CAN stack, while Part 2 focuses on high-speed physical medium attachment. A complete tool must align across the relevant layers.

Does DoCAN require CAN FD?

The public ISO 15765-2:2024 page says that document does not determine whether CAN CC, CAN FD or both are required by other referencing standards. Check the vehicle and application specification.

Should technicians probe a bus to identify the mode?

Only with verified test points, appropriate equipment and an OEM-approved method. Unknown probing can load or damage the network. Start with vehicle documentation and interface capability records before making physical measurements.

Conclusion

ISO 11898-2:2026 makes high-speed CAN physical-layer terminology more important for workshops buying interfaces and diagnosing newer networks. The sensible response is a capability audit: know which layer each tool supports, record hardware and firmware versions, and separate physical faults from transport and application problems. Subscribe to the News blog for further standards updates, and confirm vehicle-specific support before any ECU programming job.