This post builds on the EthTrcv series and picks up where the previous post on gPTP left off. That post was about time synchronization over Ethernet — this one is about the question every safety engineer eventually asks: what happens when the PHY fails to report a fault that actually occurred?
Ethernet started life as a best-effort medium for IT networks. In the vehicle, it now carries frames for ADAS sensor fusion, brake requests, and steering angle commands. That shift — from "data usually arrives" to "data must arrive, or the system must notice it didn’t" — is the core of this post.
Why Functional Safety Matters for EthTrcv at All
As long as Ethernet only carried diagnostic or infotainment traffic, a PHY failure was a comfort problem. That has changed.
Zonal architecture — Ethernet as the backbone
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Sensor ECU │ 1000 │ Zonal │ 1000 │ Domain │
│ (radar/camera)├─BASE-T1─► Controller ├─BASE-T1─► Controller │
└──────────────┘ └──────┬───────┘ │ (ADAS/brake │
│ │ control) │
EthTrcv + PHY └──────────────┘
on every linkIf the only path between a radar ECU and a domain controller is Ethernet — no redundant CAN path left for the safety-relevant message — then the EthTrcv link is part of the safety chain. A silent fault on that link (a frame arrives corrupted, but link status still reports "up") is potentially more dangerous than a full link loss, because nobody notices.
The PHY itself is usually not an ASIL D component. The actual safety function (e.g. "detect a brake request within timeout X") is typically implemented at a higher software layer — E2E protection, plausibility checks. But the PHY supplies the diagnostic information those layers depend on, and for that reason still needs to be qualified as "safety-related" in its own right. |
ISO 26262 & AUTOSAR — ASIL Decomposition in the Ethernet Stack
ISO 26262 doesn’t require every single component to be qualified at ASIL D end to end. Instead, ASIL decomposition (ISO 26262-9) distributes responsibility across multiple sufficiently independent elements, so that each element carries a lower ASIL share — provided the elements are genuinely independent of one another (freedom from interference).
Example: ASIL D safety goal "detect brake request"
decomposed across two independent paths
ASIL D = ASIL B(D) + ASIL B(D)
│ │
Ethernet path Redundant path
(EthTrcv, E2E) (e.g. second sensor,
different medium/timing)In practice, the split across the EthTrcv-adjacent software stack usually looks like this:
| Layer | Contributes to | Typical ASIL share |
|---|---|---|
PHY hardware (e.g. TJA1101) | Fault detection at the line level, diagnostic registers | Usually QM with a "Safety Element out of Context" (SEooC) case, sometimes up to ASIL B |
EthTrcv (BSW driver) | Forwards link/error status to higher layers, no error correction of its own | QM up to ASIL B, depending on the decomposition concept |
Eth (MAC driver) / EthIf | Transparent forwarding, statistics counters | QM up to ASIL B |
E2E library (above PduR/Com) | Detects loss, reordering, corruption at message level | Usually carries the largest ASIL share (up to ASIL D via decomposition) |
Application software (SWC) | Plausibility checks, timeout monitoring, release logic | ASIL of the safety goal |
A common misunderstanding: "EthTrcv is ASIL B qualified" usually does not mean the driver itself executes a safety function. It usually means the driver was developed following the corresponding safety lifecycle (tool qualification, verification, traceability) and that its fault propagation (freedom from interference) has been analyzed and bounded. |
The actual safety function almost always lives above EthTrcv — in E2E protection and application logic. But EthTrcv is the source of the raw data those layers build on: without reliable link status and error reports from the PHY, no higher layer can meaningfully decide whether a timeout stems from a genuine communication fault or a physical defect.
Fault Detection Mechanisms in the PHY
The PHY chip itself provides several diagnostic mechanisms that can be read out over MDIO (see the Hardware Deep Dive). These mechanisms are the foundation for everything EthTrcv later reports to higher layers.
Cable Diagnostics — TDR (Time Domain Reflectometry)
TDR sends a defined test pulse onto the line and measures the reflection caused by impedance discontinuities — a short, an open circuit, or a badly seated connector.
PHY sends test pulse ──────────────►
Impedance discontinuity (e.g. cable break)
PHY measures reflected energy ◄─────────
Round-trip time of reflection → distance to fault location
Amplitude of reflection → fault type (open / short / partial damage)| TDR finding | Interpretation |
|---|---|
No reflection, signal fully absorbed | Cable intact, correctly terminated |
Strong positive reflection | Open circuit — distance computable from round-trip time |
Strong negative reflection | Short between conductors or to ground |
Weak, distributed reflection | Insulation damage, pinching, incipient corrosion at a connector contact |
TDR typically does not run continuously during normal driving, but is triggered at power-on (as part of the self-test) or on explicit diagnostic request, since the test pulse briefly disrupts regular data traffic.
Relevant for the software integration: TDR results live in vendor-specific PHY registers (Clause 45 vendor space) and must be read via a vendor-specific driver extension (an EthTrcv vendor API or callout) — AUTOSAR standardizes the generic diagnostic path here, not the register mapping itself. |
RMS Amplitude Monitoring
The PHY continuously monitors the RMS voltage of the received signal on the line. A deviation from the expected level band indicates an emerging signal quality degradation — often before a hard link loss occurs.
Expected level range (100BASE-T1, differential): ±1 V nominal
RMS measurement over time:
100 % ┤ ██████████████████████▓▓▓▓░░░░
│ Nominal range Degradation Link loss
└──────────────────────────────────────────────────► Time
↑
Early warning possible,
before the link actually dropsThis early-warning capability is particularly valuable for functional safety: it enables a graceful degradation path (e.g. reduced data rate, switch to a redundant path) instead of an abrupt, unprepared communication loss.
Internal Loopback Self-Tests
The PHY can short-circuit the transmit and receive paths internally to verify its own digital — and partly analog — signal processing, independent of the connected cable.
Near-end loopback (digital):
MAC → TX path → [internally shorted] → RX path → MAC
Tests: PCS/PMA logic, scrambling/descrambling, clock domain crossing
Far-end loopback (over the cable, with a peer):
ECU A → cable → ECU B (loopback active) → cable → ECU A
Tests: entire transmission path including cable and peer device| Loopback type | Tests | Typical trigger point |
|---|---|---|
Near-end (internal) | PHY-internal digital/analog logic | Power-on self-test, periodically in the background (off-line test) |
Far-end (over cable) | Entire point-to-point connection | Workshop diagnostics, rarely during driving (interrupts payload traffic) |
Loopback tests interrupt regular data transmission for their duration. A self-test triggered during an active safety-relevant data stream can become a fault source in its own right if it isn’t coordinated with the application layer — e.g. via a defined diagnostic state in which safety-relevant communication is already quiesced. |
Temperature and Voltage Monitoring
Automotive PHYs typically integrate on-chip sensors for junction temperature and the various supply voltages (compare the voltage domains from the Hardware Deep Dive).
Monitored quantities (example values, vendor-dependent):
Junction temperature warning threshold ~125 °C, shutdown ~150 °C
VDD_Core tolerance band ±5 % around nominal
VDD_MDI tolerance band ±10 % around nominal
On threshold violation:
→ status bit set in diagnostic register
→ optional: interrupt pin (if wired)
→ optional: automatic shutdown of the transmit stage (self-protection)These mechanisms primarily protect the chip itself, but they also provide valuable context for root-cause analysis: a link loss reported alongside an overtemperature warning points to a thermal cause rather than a cable defect — a distinction that can meaningfully change the fault handling strategy at the application layer.
Safety Mechanisms in the AUTOSAR Stack
The PHY-side mechanisms supply raw data. The actual safety architecture only emerges from the interplay with the mechanisms above EthTrcv.
E2E Protection at Higher Layers
The AUTOSAR E2E library (End-to-End Protection) secures individual messages independently of the underlying communication medium — it does not "trust" EthTrcv, Eth, or the network, but checks every received message itself.
Sender Receiver
┌─────────────┐ ┌─────────────┐
│ SWC │ │ SWC │
│ Payload │ │ Payload │
├─────────────┤ ├─────────────┤
│ E2E wrapper │ + counter, CRC, ID │ E2E wrapper │ checks:
├─────────────┤ ├─────────────┤ counter consecutive?
│ Com / PduR │ │ Com / PduR │ CRC correct?
├─────────────┤ ├─────────────┤ timeout met?
│ EthIf/EthTrcv│──── Ethernet link ──────►│ EthIf/EthTrcv│
└─────────────┘ └─────────────┘E2E detects exactly the fault classes a "silent" PHY failure can produce:
| E2E check | Detects |
|---|---|
Sequence counter | Lost or reordered frames while EthTrcv still reports "link up" |
CRC / checksum | Bit errors that slip through despite Ethernet’s own FCS (Frame Check Sequence) |
Timeout monitoring | Complete loss of the data stream while the link nominally remains up |
Data ID | Addressing errors, routing misconfiguration when switching through EthSwt |
Ethernet’s own FCS (CRC-32 in the frame trailer) already discards corrupted frames at the MAC — that substantially reduces the probability of silent data corruption, but it does not replace E2E checking. FCS protects against transmission errors on the medium, not against faults that originate in software layers above the MAC (e.g. buffer overruns, addressing errors during switching). |
Watchdog Supervision
In addition to content-level E2E checking, a watchdog mechanism (AUTOSAR WdgM) supervises whether the software parts responsible for safety-relevant communication — including the EthTrcv status polling — are still executing at all.
EthTrcv_GetLinkState() must be called cyclically
→ the call is reported as an "alive" checkpoint to WdgM
→ if the checkpoint is missed (e.g. task blocked, deadlock)
→ WdgM triggers a reaction (reset, safe state)This guards against a different fault class than E2E: not "the data is wrong" but "the supervision itself has stopped running" — for instance because the task polling link status is hung or starved.
DEM Integration — Mapping Fault Events
The Diagnostic Event Manager (DEM) module is the central collection point for fault events across the AUTOSAR stack. EthTrcv reports PHY-side faults via produced diagnostic events, which the DEM debounces, prioritizes, and forwards to freeze-frame handling as needed.
PHY diagnostic registers
│ (MDIO read, vendor-specific)
▼
EthTrcv detects fault condition
│
▼
Dem_ReportErrorStatus(EventId, DEM_EVENT_STATUS_FAILED)
│
▼
DEM: debouncing (counter / time) ── not yet confirmed ──► no entry
│
▼ (threshold reached)
DEM: event confirmed
│
├─► entry in event memory (persisted, UDS-readable)
├─► freeze frame (context data: timestamp, operating state)
└─► callback to SWC / FiM (Function Inhibition Manager)Standard EthTrcv Fault Events
AUTOSAR defines the following produced events for EthTrcv. Note that
ETHTRCV_E_ACCESS ("transceiver access failed") is the only
standardized DEM (production/runtime) event for EthTrcv, referenced via
the EthTrcvDemEventParameterRefs ECUC container; the remaining entries
below are development errors (Det), which are a separate reporting
path:
| Event / error code | Meaning | Typical debounce strategy |
|---|---|---|
| Transceiver/MDIO access failed (PHY does not respond) — the standardized DEM event for EthTrcv | Counter-based, usually with immediate escalation on repeated failure |
| Invalid pointer or invalid transceiver index on API call (development errors, not runtime errors) | Not DEM-relevant — Det report (Development Error Tracer) |
| API call before initialization | Not DEM-relevant — Det report |
A persistent loss of the physical link ("PHY down") is not itself a
standardized DEM event name in AUTOSAR — projects that need to report it
as a distinct diagnostic event typically add a vendor-specific extension
to the EthTrcvDemEventParameterRefs container (the container is
designed to support such additions) rather than relying on a standard
identifier for it.
Not every AUTOSAR fault event is a DEM event. Development errors
( |
Vendor Safety Events
Beyond the standard events, many automotive PHYs bring additional, vendor-specific safety diagnostic registers that are not mapped 1:1 in the AUTOSAR specification, but that still need to be wired into the DEM through the vendor API or a callout mechanism.
Examples of vendor-specific safety events (illustrative):
VENDOR_E_TDR_FAULT cable diagnostics located a fault
VENDOR_E_TEMP_WARNING temperature warning threshold exceeded
VENDOR_E_RMS_DEGRADED signal quality below warning threshold
VENDOR_E_SELFTEST_FAILED internal self-test (BIST) failedWhen integrating a new PHY, it pays to ask early: which vendor diagnostic registers exist, and which of them are actually safety-relevant according to the vendor’s safety manual? That list determines how many additional DEM events need to be engineered on top of the standard EthTrcv fault catalog — a point that effort estimates routinely underestimate. |
Vendor Example: NXP TJA1101 (ASIL B)
A concrete example worth walking through is the NXP TJA1101, a widely used 100BASE-T1 PHY with ASIL B qualification per ISO 26262. The following details are illustrative and do not replace the vendor’s current datasheet or safety manual.
| Safety feature | Description |
|---|---|
ASIL B qualification (SEooC) | Developed as a "Safety Element out of Context" per ISO 26262-10 — the vendor supplies safety goals and assumptions that the system integrator must adopt and validate |
Cable Diagnostic Toolkit | TDR-based cable diagnostics, readable via MDIO registers, detects short/open circuits including distance-to-fault |
Signal Quality Indicator (SQI) | Continuous signal quality assessment as a metric — the basis for an early warning before link loss |
Loopback modes | Internal, external, and remote loopback for self-test and field diagnostics |
Overtemperature protection | Warning and automatic shutdown of the transmit stage when a temperature threshold is exceeded |
Diagnostic interrupt | Configurable INT pin that raises an interrupt on the SoC for safety-relevant events, instead of relying purely on polling |
Simplified flow: TJA1101 diagnostic evaluation by EthTrcv
1. EthTrcv_MainFunction() (cyclic)
│
▼
2. MDIO read of diagnostic registers (Clause 22 extended register / Clause 45)
│
▼
3. Interpret status bits:
- link status
- cable diagnostic result
- temperature warning
- SQI below threshold?
│
▼
4. On fault condition: Dem_ReportErrorStatus() for the mapped event
│
▼
5. On critical condition (e.g. overtemperature shutdown):
additionally notify EcuM / safe-state handling"ASIL B" for the TJA1101 does not mean every single function of the chip is qualified at ASIL B. It means the vendor documents in the safety manual the boundary conditions — diagnostic coverage, fault reaction times, usage profile — under which the component can be used up to ASIL B in a safety concept. Responsibility for correctly embedding it remains with the system integrator. |
Certification Questions — What the PHY Vendor Must Deliver
Integrating a PHY into a safety-relevant ECU requires more from the vendor than a datasheet. ISO 26262-8 (supporting processes) and -10 (guideline) define what is needed to use the component as an SEooC and to secure the interface.
| Document / artifact | Purpose |
|---|---|
Safety Manual | Describes safety goals, assumptions about the usage context (assumptions of use), the supported ASIL level, and required external measures (e.g. wiring, software-side evaluation of diagnostic registers) |
FMEA (Failure Mode and Effects Analysis) | Systematic analysis of possible failure modes, their effects, and the detection the component itself provides (diagnostic coverage per failure mode) |
FMEDA (FMEA + Diagnostic Coverage) | Quantitative extension of the FMEA — provides metrics such as SPFM (Single Point Fault Metric) and LFM (Latent Fault Metric) needed for the safety case at system level |
Development Interface Agreement (DIA) | Contractual/organizational clarification of which safety activities the semiconductor vendor performs and which remain with the Tier 1 / OEM |
Proof of tool/process qualification | Evidence that the development process and any tools used meet the requirements of the targeted ASIL (ISO 26262-8) |
Errata / known issues list | Known silicon defects with an assessment of whether and how they affect the safety argument |
A PHY without a safety manual cannot readily be used for an ASIL-relevant safety goal — even if it technically has the right diagnostic functions on board. Without documented diagnostic coverage and assumptions of use, there is no basis for correctly evaluating the component in a system-level FMEDA. This is one of the most common reasons an otherwise suitable PHY fails a safety review. |
For the integration into the EthTrcv software stack, this translates into concrete questions:
Which failure modes does the PHY itself cover (diagnostic coverage), and which must be additionally secured by E2E / application software?
What reaction time does the PHY guarantee between fault occurrence and diagnostic report (fault detection time) — does that fit the required Fault Tolerant Time Interval (FTTI) of the safety goal?
Which registers must be polled cyclically, and which trigger an interrupt? That directly shapes how
EthTrcv_MainFunctiongets implemented.
Summary
| Topic | Key takeaway |
|---|---|
Why safety matters for EthTrcv | Ethernet increasingly carries safety-relevant messages without a redundant non-Ethernet path — silent PHY faults become safety-relevant as a result |
ASIL decomposition | The actual safety function usually lives above EthTrcv (E2E, application logic); EthTrcv supplies the raw data those layers need, reliably and with bounded fault propagation |
PHY fault detection | TDR, RMS amplitude monitoring, loopback self-tests, and temperature/voltage monitoring form the diagnostic basis, mostly via vendor-specific MDIO registers |
E2E & watchdog | E2E checks message content and ordering independently of the medium; WdgM checks that the supervision itself is still running |
DEM integration | The standard event |
Vendor example TJA1101 | ASIL B PHY with a cable diagnostic toolkit, SQI, and loopback modes — SEooC qualification assumes correct embedding by the integrator |
Certification | Safety manual, FMEA/FMEDA, and assumptions of use are mandatory artifacts — without them a system-level assessment isn’t possible |
Next in the EthTrcv series: EthTrcv & MACsec — Automotive Cybersecurity at Layer 2