In short
Automotive Ethernet is IEEE 802.3 Ethernet carried over a single balanced twisted pair inside a vehicle, using T1 physical layers such as 10BASE-T1S, 100BASE-T1 and 1000BASE-T1. The Ethernet frame format is unchanged. The cabling, connectors, link start-up behaviour and the protocol stack above it, including VLANs, TSN, SOME/IP and DoIP, are automotive specific.
An engineer handed a 100BASE-T1 link for the first time usually has the same three questions in the same order. Is this real Ethernet? Why will it not come up? And how do I see what is on it?
This guide to automotive Ethernet answers all three, then fills in the map around them: the T1 physical layer family, the protocol stack above the pair, the OPEN Alliance conformance vocabulary, and the bench workflow that turns a two-wire harness into something you can observe.
Every figure here is traceable to a public IEEE, OPEN Alliance, AUTOSAR or Wireshark document named in the References; the IEEE task force objectives sheets are the source for reach, bit error ratio and connector counts.
What automotive Ethernet is, and what it is not
One balanced twisted pair, no RJ45
Automotive Ethernet is IEEE 802.3 Ethernet carried over a single balanced twisted pair. That is the whole structural change, and everything else follows from it.
The frame is untouched. Every T1 project in IEEE 802.3, from 10 Mbit/s to 25 Gbit/s, carries the same two objectives: preserve the IEEE 802.3 Ethernet frame format at the MAC client service interface, and preserve the minimum and maximum frame size of the current standard.
What changes is the physical layer and the environment it lives in. Office gigabit Ethernet uses four pairs; a T1 link uses one. Office Ethernet uses RJ45; a vehicle harness uses automotive connectors, and the 802.3bw and 802.3bp objectives describe link segments supporting up to four inline connectors: a harness description, not a patch panel one. Duplex depends on the family member: 100BASE-T1 and above are full duplex only, while 10BASE-T1S is half duplex, with full duplex optional on its point-to-point segment.
The video “AUTOMOTIVE Ethernet || OSI Layers, Signal Communication, SOMEIP” by Kaushik Naik, an independent embedded-systems educator, walks through this layering:
https://www.youtube.com/watch?v=ijiuH5j24Sw
How it differs from office Ethernet
Four differences matter on day one.
Cabling and connectors. One pair, unshielded on the lower rates, shielded at multi-gigabit, with automotive connectors rated for vibration, temperature and EMC.
Link start-up. IEEE P802.3bw carries an objective for fast-startup operation using predetermined configurations: from power_on false to transmitting and receiving valid data in under 100 ms. 802.3cg carries the same non-optional fast-startup objective, and 802.3bp, 802.3ch and 802.3cy each carry it as an optional startup procedure. Consumer gigabit Ethernet has no such requirement.
Auto-negotiation. A 100BASE-T1 link does not auto-negotiate. Master and slave roles are set by configuration, and if both ends are configured the same way the link simply does not come up. Linux exposes the setting through ethtool. 1000BASE-T1 adds optional Clause 98 auto-negotiation, and 802.3cg, 802.3ch and 802.3cy all list it as optional, so the master and slave question survives on the faster links too.
Power. There is no Power over Ethernet here. Power over Data Lines exists instead: 802.3ch and 802.3cy carry an objective for optional Clause 104 power over data lines, and 802.3cg one for optional power distribution. Optional again, and often not populated.
Why OEMs moved past CAN-only architectures
Bandwidth demand from cameras, radar, logging and software updates
The bandwidth pressure is visible in the IEEE 802.3 record itself. The multi-gig automotive PHY objectives, approved by the 802.3 working group in March 2017, set out 2.5, 5 and 10 Gbit/s over automotive link segments. In July 2022 the IEEE 802.3 Working Group approved the P802.3cy objectives for 25 Gbit/s. Camera and radar aggregation into central compute, logging for driver assistance development, and whole-image software updates are the loads that got it there.
Harness, connectors and the cost of a node
The harness argument is structural rather than numerical. One balanced pair carries fewer conductors than shielded four-pair cabling; unshielded single-pair cabling is permitted at 100 Mbit/s, and at 1 Gbit/s the standard’s Type A automotive link segment is specified on unshielded balanced copper; link segments are specified with a small, bounded connector count. Public per-vehicle mass and cost figures for specific programmes are OEM internal numbers, so this guide quotes none.
What CAN and LIN still do better, and why they are not going away
CAN and CAN FD do exactly what they were designed for: short, prioritised control messages, deterministic arbitration on a shared medium, and node cost low enough to put a transceiver on every actuator. LIN is cheaper still for slow body electronics. Debugging skills carry over too: if you already scope CAN FD, LIN and FlexRay edges, the same instrumentation approach extends to automotive Ethernet, and our CAN and LIN testing capability covers that side.
The T1 physical layer family, mapped
100BASE-T1 and 1000BASE-T1
100BASE-T1 is IEEE 802.3bw. It uses PAM-3 line coding at 66.67 MBaud, is full duplex only, and its task force objectives define a link segment over a single balanced twisted pair with up to four inline connectors for at least 15 m of reach, at a bit error ratio of 1e-10 or better. It is the rate you are most likely to be handed first.
1000BASE-T1 is IEEE 802.3bp, also PAM-3 but at 750 MBaud. The standard defines two link segments: Type A, an automotive segment on unshielded balanced copper for at least 15 m with up to four inline connectors, and Type B, a longer segment for at least 40 m aimed at industrial and transportation use. It also supports optional single-pair auto-negotiation, which became Clause 98.
10BASE-T1S multidrop and PLCA
10BASE-T1S is IEEE 802.3cg. It uses differential Manchester encoding and supports a multidrop mixing segment: the 802.3cg objectives define a mixing segment on a single balanced pair supporting at least 8 nodes over at least 25 m, alongside a point-to-point link segment for at least 15 m. Access on that shared medium can be arbitrated by PLCA, PHY-level collision avoidance, an optional reconciliation sublayer (Clause 148) that layers on top of CSMA/CD to give multidrop 10BASE-T1S bounded access latency. It can be enabled or disabled through the management interface, so confirm it is on before assuming deterministic access.
It is the only member of the family where more than two nodes share a pair.
Multi-gig: 2.5G, 5G, 10G and 25G
IEEE 802.3ch covers 2.5GBASE-T1, 5GBASE-T1 and 10GBASE-T1 using PAM-4 signalling, with objectives targeting at least 15 m over an automotive link segment with up to four inline connectors, and a bit error ratio of 1e-12 or better. The objectives permit several cabling types, but the PHYs as published in Clause 149 are specified on a shielded balanced pair. IEEE 802.3cy-2023 adds 25 Gb/s over a shielded automotive link segment, with objectives calling for at least 11 m and up to two inline connectors.
Two things follow: reach shortens as rate climbs, and shielding stops being optional.
BroadR-Reach and how an OPEN Alliance specification became an IEEE standard
Before 100BASE-T1 there was BroadR-Reach, a single-pair automotive PHY published through the OPEN Alliance. The IEEE P802.3bw objectives carry an explicit objective to provide electrical interoperability with that existing 100 Mbit/s single-pair interface, footnoted to the BroadR-Reach specification hosted on the IEEE 802.3 site. BroadR-Reach is the ancestor of 100BASE-T1, not a synonym for automotive Ethernet as a whole.
Lookup table
| Rate | Standard | Signalling | Reach objective | Where you meet it |
|---|---|---|---|---|
| 10 Mbit/s | IEEE 802.3cg (10BASE-T1S) | Differential Manchester, PLCA multidrop | At least 15 m; mixing segment at least 8 nodes over at least 25 m | Sensors and actuators |
| 100 Mbit/s | IEEE 802.3bw (100BASE-T1) | PAM-3, 66.67 MBaud | At least 15 m, up to 4 inline connectors | Control, cameras, diagnostics, backbone on many vehicles |
| 1 Gbit/s | IEEE 802.3bp (1000BASE-T1) | PAM-3, 750 MBaud | At least 15 m; optional longer segment goal at least 40 m | Backbone links, sensor aggregation, driver assistance |
| 2.5 / 5 / 10 Gbit/s | IEEE 802.3ch | PAM-4 | At least 15 m, up to 4 inline connectors | Sensor aggregation into central compute, shielded cabling |
| 25 Gbit/s | IEEE 802.3cy-2023 | PAM-4 | At least 11 m, up to 2 inline connectors | Next generation sensor fusion |
Reach values are task force objectives; your harness will have its own qualified numbers.
The automotive Ethernet protocol stack above the PHY
The PHY takes the least of your time once the link is up; the stack above it is where vehicle behaviour lives.
Switching, VLANs and priority inside the vehicle
An in-vehicle Ethernet network is a switched network. Traffic is separated with VLAN tags and prioritised with the priority field in the tag, so a control message and a camera stream sharing a backbone link do not compete on equal terms. IEEE 802.1 owns this material. Switch configuration is static, defined at design time and loaded at boot, so a misconfigured VLAN shows up as traffic that silently never arrives rather than as an error.
TSN in practice
Time-Sensitive Networking is a set of IEEE 802.1 amendments, one of which pairs with an 802.3 amendment, and in a vehicle four of them do most of the work:
- gPTP (802.1AS) distributes a common time base so that every node agrees what time it is. Everything else in this list depends on it.
- Scheduled traffic (802.1Qbv) opens and closes transmission gates on a schedule, so critical frames get the wire at a known instant.
- Credit-based shaping (802.1Qav) smooths streaming traffic so a camera cannot burst and starve control messages.
- Frame preemption (802.1Qbu with 802.3br) lets a long, low-priority frame be interrupted so an urgent frame does not wait behind it. It is the one item here that needs a MAC merge sublayer in 802.3 as well as the 802.1 side.
SOME/IP for service oriented communication
SOME/IP, Scalable service-Oriented MiddlewarE over IP, is how ECUs offer and consume services rather than broadcasting fixed signal frames. A server offers a service, clients find it through SOME/IP Service Discovery, specified in a companion AUTOSAR document, and then call methods, subscribe to events or read fields. The protocol specification is published openly by AUTOSAR, and Wireshark has dissected SOME/IP natively since version 3.2.
The shift it represents is bigger than the protocol. A signal-oriented CAN matrix says what is on the bus. A service-oriented architecture says what is available, and what is on the wire depends on who subscribed.
DoIP for diagnostics over IP
DoIP carries diagnostic communication, in practice UDS requests and responses, over TCP/IP instead of over CAN. The tester discovers a diagnostic entity, opens a connection, and routes requests to a logical address that may sit behind a gateway on an internal bus. Wireshark ships a DoIP dissector, so a diagnostic session on an Ethernet link is readable in the same capture as everything else.
Security layers side by side
Three mechanisms recur, protecting different things:
| Mechanism | Where it sits | What it protects |
|---|---|---|
| MACsec | Layer 2, link by link | The hop between two devices, including headers above the MAC |
| SecOC | AUTOSAR, on the PDU | The message payload end to end, independent of transport |
| TLS | Above TCP | A session between two IP endpoints |
They are different scopes rather than alternatives; a vehicle programme often uses more than one.
Where each bus sits in a modern vehicle
CAN vs Ethernet, and the rest of the in-vehicle networking picture
| Bus | Typical role | Why it is chosen |
|---|---|---|
| LIN | Slow body electronics, single master | Lower node cost than CAN, single wire |
| CAN / CAN FD | Prioritised control messages, powertrain, chassis | Deterministic arbitration, mature tooling, low node cost |
| FlexRay | Time-triggered control on legacy programmes | Determinism, redundancy; largely superseded by Ethernet plus TSN on new designs |
| Automotive Ethernet | Backbone, cameras, driver assistance, diagnostics, software update | Bandwidth, switching, IP stack, service oriented communication |
| SerDes camera links | Raw sensor video to a processing node | Uncompressed low-latency video over a single coax or pair |
Why camera and display links are not Ethernet
GMSL, FPD-Link, ASA-ML and MIPI A-PHY are point-to-point serialiser and deserialiser links carrying uncompressed video with very low latency. They are not Ethernet, they are not switched, and their frames will not appear in a Wireshark capture. Treat SerDes links as their own domain, and expect the aggregation point, not the camera, to be your first Ethernet-visible node.
Gateways and the coexistence pattern, and why a gateway is not a switch
Vehicles that carry Ethernet generally carry CAN alongside it, joined at a gateway. Two terms get used interchangeably here and should not be.
A switch forwards Ethernet frames between ports at layer 2 using MAC addresses, VLAN tags and priority. It does not change the payload.
A gateway translates. It takes CAN frames and repackages their content as Ethernet payloads, or accepts a diagnostic request over DoIP and reissues it onto an internal CAN bus toward a target ECU.
A modern zone controller usually contains both functions in one housing, which is why the words blur. On a bench, a frame that does not arrive at a switch port is a forwarding problem; a message that arrives with the wrong contents is a translation problem; the two are debugged in different places.
Conformance and interoperability vocabulary
The OPEN Alliance publishes the specification set that the automotive supply chain quotes at each other, hosted at opensig.org. Three names come up constantly.
TC8 is the ECU test specification: a conformance and interoperability suite covering an ECU’s Ethernet behaviour from the physical layer up through higher-layer protocol interactions. TC8 tested means measured against that published suite.
TC10 covers sleep and wake-up over the link. A network that cannot be put to sleep and woken again through the same pair is a quiescent current problem, so TC10 behaviour is a hard requirement.
TC14 covers 10BASE-T1S, the multidrop member of the family, because a shared medium with PLCA arbitration cannot be tested the same way as a point-to-point link.
What a conformance report does not tell you
A conformance report says a device passed a defined test suite on a defined setup. It does not say your two devices will interoperate on your harness; that your VLAN and priority configuration is correct; that gPTP converges in your topology; or anything about SOME/IP service discovery under your load. Treat it as a precondition, not as evidence that a system works.
Zonal architectures and the direction of travel
The architectural shift underneath all of this is from domain controllers grouped by function to zone controllers grouped by physical location, with an Ethernet backbone between them and central compute doing the heavy work. Local sensors and actuators connect to the nearest zone controller over short CAN, LIN or 10BASE-T1S runs.
Two consequences land on your bench. First, the interesting traffic moves from a bus you can tap anywhere to a switched link where a frame is only visible on the path it takes, so where you connect determines what you can see. Second, the diagnostic path lengthens: a request travels over DoIP to a gateway, gets translated, and continues on an internal bus, so a failure can be in the transport, the translation or the target. It is why Ethernet has moved into the vehicle communication architecture through to end-of-line processes.
How engineers actually work with automotive Ethernet
Getting a laptop onto a T1 link
Your laptop cannot speak T1. You need a media converter between the single-pair side and a standard interface, with its master or slave role set correctly, because on 100BASE-T1 there is no negotiation to sort it out for you. Get the role wrong and you get no link, not a degraded one. It is a configuration problem, not a hardware fault.
Capturing without changing behaviour
A port mirror on a switch is convenient, but it depends on the switch, it can drop frames under load, and it shows you what the switch chose to copy rather than what was on the pair. A tap sits inline on the physical link and reports what is genuinely there, at the cost of breaking into the harness. For timing-sensitive work, or to prove what was actually transmitted, inline capture is the stronger evidence.
Decoding SOME/IP and DoIP in Wireshark
The capture is ordinary Ethernet. The Wireshark community’s own answer to “how do I read a T1 capture” is that the file contains standard Ethernet frames. Wireshark dissects SOME/IP natively from version 3.2 onward and ships a DoIP dissector, so a single capture can show service discovery, a method call and a diagnostic session together. Start with the display filters someip and doip, then narrow by service ID.
Validating time sync before you trust any timestamp
If gPTP has not converged, every conclusion you draw about latency, jitter or ordering across nodes is unsafe: every timestamp in your capture is a guess. Establish that the time base is stable before you measure anything that depends on it. The step is easy to skip because unconverged numbers still look plausible, and the error is expensive to discover late.
Bringing ECUs up in manufacturing
Everything above is development bench work. Production is a separate discipline with separate equipment and cycle-time constraints, and Ethernet has changed it too; that side is covered in our post on Ethernet-based ECU handling in production.
A learning path using free public material
Which specifications to read first, in order
- The IEEE 802.3 task force objectives sheets for your rate: short, free, and a statement of what the standard was built to achieve. Start with 802.3bw on 100BASE-T1.
- The OPEN Alliance specification index at opensig.org, to learn the TC vocabulary your suppliers use.
- The AUTOSAR SOME/IP protocol specification, published openly and readable without a subscription.
- IEEE 802.1 working group material for VLANs and the TSN amendments, once the PHY has stopped being interesting.
Open source you can run today
Wireshark, with its SOME/IP and DoIP dissectors, costs nothing. COVESA’s vsomeip is an open-source SOME/IP implementation you can run on Linux to generate and consume real service traffic. Linux PHY tooling, including ethtool’s master and slave controls, lets you experiment with T1 link roles on supported hardware.
Further viewing
- Automotive Ethernet: The Definitive Guide by Colt Correa, Charles M. Kozierok, Robert B. Boatright and Jeffrey Quesnelle, a book-length treatment of the field.
Where GSAS fits
GSAS Micro Systems is an engineering partner, and on automotive Ethernet that means helping a team decide what its bench needs to prove before it spends anything.
If your team in India is starting an Ethernet programme, the useful first conversation is usually about scope rather than equipment: which links you have to observe, whether you need inline capture or a mirror will do, whether time synchronisation has to be validated, and where diagnostics over IP fits into your test plan. Our engineers work in IST, so a bench session happens in your working day, and quotations are issued in INR through the procurement channels Indian OEMs and tier-one suppliers already use.
Start with the automotive Ethernet capabilities page, and request a scoped conversation when you want to talk through a specific bench or programme. We will tell you what we think you need to validate first, including where the answer is that you do not need to buy anything yet.
References
- IEEE 802.3 Ethernet Working Group: https://www.ieee802.org/3/
- IEEE P802.3bw 100BASE-T1 Task Force objectives (frame format, full duplex, BER 1e-10, at least 15 m, up to four inline connectors, sub-100 ms fast startup, BroadR-Reach interoperability): https://www.ieee802.org/3/bw/public/20140717_V3_Objectives.pdf
- IEEE 802.3bw D1.2 approved ballot comments (66.666 MBd line rate, single-pair UTP cabling): https://www.ieee802.org/3/bw/comments/8023bw_D1_2_approved.pdf
- IEEE P802.3bp 1000BASE-T1 Task Force objectives (at least 15 m automotive segment, optional segment goal of at least 40 m, optional single-pair auto-negotiation): https://www.ieee802.org/3/bp/Updated_Objectives_0714.pdf
- IEEE P802.3bp D1.4 Clause 97 overview (PAM3 at 750 MBd, link segment Type A and Type B definitions): https://www.ieee802.org/3/bp/public/may15/tu_3bp_02a_0515.pdf
- IEEE P802.3cg 10 Mb/s Single Twisted Pair Task Force objectives (15 m link segment, 25 m mixing segment with at least 8 nodes, optional power distribution): https://www.ieee802.org/3/cg/objectives_3cg_0318.pdf
- IEEE P802.3ch Multi-Gig Automotive Task Force objectives (2.5, 5 and 10 Gb/s, BER 1e-12, at least 15 m, optional Clause 104 PoDL): https://www.ieee802.org/3/ch/0317_approved_objectives_3NGAUTO.pdf
- IEEE P802.3ch Task Force public area (published as IEEE Std 802.3ch-2020; the Clause 149 PHYs are specified on a shielded balanced pair): https://www.ieee802.org/3/ch/
- IEEE P802.3cy Task Force objectives (25 Gb/s, at least 11 m, up to two inline connectors): https://www.ieee802.org/3/cy/P802d3cy_OBJ_UPDATED_APPROVED_07_14_22.pdf
- OPEN Alliance BroadR-Reach automotive specification v3.0, hosted on the IEEE 802.3 site: http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
- OPEN Alliance automotive Ethernet specification index (published specification and test suite PDFs): https://opensig.org/automotive-ethernet-specifications/
- OPEN Alliance Technical Committees (TC8 ECU test specification, TC10 sleep/wake-up, TC14 10BASE-T1S interoperability and compliance): https://opensig.org/tech-committees/
- IEEE 802.1 Working Group (VLANs, 802.1AS, 802.1Qav, 802.1Qbv, 802.1Qbu): https://www.ieee802.org/1/
- Linux kernel mailing list discussion of master and slave configuration for single-pair PHYs via ethtool: https://lkml.iu.edu/hypermail/linux/kernel/2006.1/02234.html
- Wireshark SOME/IP display filter reference (fields documented from Wireshark 3.2 onward): https://www.wireshark.org/docs/dfref/s/someip.html
- Wireshark DoIP display filter reference: https://www.wireshark.org/docs/dfref/d/doip.html
- Wireshark Q&A on reading captures taken from single-pair automotive links as ordinary Ethernet: https://ask.wireshark.org/question/25298
- AUTOSAR SOME/IP Protocol specification (R24-11, Foundation): https://www.autosar.org/fileadmin/standards/R24-11/FO/AUTOSAR_FO_PRS_SOMEIPProtocol.pdf
- AUTOSAR SOME/IP Service Discovery Protocol specification (R24-11, Foundation): https://www.autosar.org/fileadmin/standards/R24-11/FO/AUTOSAR_FO_PRS_SOMEIPServiceDiscoveryProtocol.pdf
- COVESA vsomeip, open-source SOME/IP implementation: https://github.com/COVESA/vsomeip
- “AUTOMOTIVE Ethernet || OSI Layers, Signal Communication, SOMEIP”, Kaushik Naik (YouTube): https://www.youtube.com/watch?v=ijiuH5j24Sw
Also appears in:
Building for Automotive & Mobility?
Talk to our application engineers for personalized tool recommendations.
You might also like
View all →
