| Aspect | IEEE 1588-2019 (PTP) | IEEE 802.1AS-2020 (gPTP) |
|---|---|---|
| Scope | Any Ethernet/IP network | Bridged Ethernet networks (automotive) |
| Messages | Multicast or unicast | Always multicast (01:80:C2:00:00:0E for L2) |
| Transport | UDP/IP or Ethernet (L2) | Ethernet L2 only (EtherType 0x88F7) |
| Clock classes | 16 classes (0–255) | Automotive: GNSS=6, crystal=248 |
| Correction field | Optional | Mandatory: each bridge adds residence time |
| Profile | Various (default, telecom, etc.) | Automotive profile (AVNU / AUTOSAR) |
| Accuracy | Sub-microsecond feasible | < 1 µs sub-domain; < 500 ns with hardware timestamping |
gPTP: IEEE 802.1AS Generalised PTP
gPTP Clock Hierarchy
gPTP Domain: GrandMaster and Boundary Clocks
GrandMaster (GM): highest-quality clock source in the domain ├── GNSS receiver (GPS/Galileo): TAI time, ±100 ns accuracy ├── TCXO (temperature-compensated crystal): ±50 ppm (startup / GNSS fallback) └── Selected by Best Master Clock Algorithm (BMCA) Domain: ┌─────────────────────────────────────────────────────────────────┐ │ GrandMaster (Domain Controller ECU with GNSS) │ │ └── Sync messages every 125 ms → all bridges │ │ ↓ ↓ ↓ │ │ [Zone Switch 1] [Zone Switch 2] [Zone Switch 3] │ │ (Transparent Clock) (Transparent Clock) (Transparent Clock) │ │ Adds residence time Adds residence time Adds residence time │ │ ↓ ↓ ↓ │ │ ECU1 ECU2 ECU3 ECU4 ECU5 ECU6 │ │ (Slave clocks: sync to GM via PDelay + correction field) │ └─────────────────────────────────────────────────────────────────┘ Transparent Clock: switch measures frame residence time; adds to Correction Field Boundary Clock: switch has its own clock; slaves to GM; masters to downstream slaves
Peer Delay Measurement
Cgptp_pdelay.c
/* gPTP Peer Delay Request/Response sequence */
/* Each link-local measurement; runs every 1 s (by default) */
/* Hardware timestamping essential: software timestamps add 10–100 µs error */
/* Requires: MAC with IEEE 1588 hardware clock (most automotive MACs include this) */
#include "EthTrcv.h"
#include "GptpTrcv.h"
typedef struct {
uint64_t t1; /* PDelay_Req sent (local clock) */
uint64_t t2; /* PDelay_Req received at peer (peer clock) */
uint64_t t3; /* PDelay_Resp sent by peer (peer clock) */
uint64_t t4; /* PDelay_Resp received (local clock) */
} PdelayTimestamps_t;
/* Link delay = ((t4 - t1) - (t3 - t2)) / 2 */
int64_t GptpTrcv_ComputePathDelay(const PdelayTimestamps_t *ts)
{
int64_t round_trip = (int64_t)(ts->t4 - ts->t1);
int64_t peer_time = (int64_t)(ts->t3 - ts->t2);
int64_t path_delay_ns = (round_trip - peer_time) / 2;
return path_delay_ns; /* typical: 100–500 ns for 1–5 m cable */
}
/* Sync correction: slave adjusts local clock by offset */
/* offset = master_time_at_receive - local_time_at_receive - path_delay */
/* AUTOSAR: Gpt_SetSubSeconds() or OS counter correction */Summary
gPTP is the timing foundation for all TSN features: TAS gate schedules are based on a shared gPTP clock domain, and CBS Class A/B timing is measured relative to the domain time. Accuracy < 1 µs requires hardware timestamping in the MAC — software-only gPTP implementations achieve only 10–100 µs accuracy, which is insufficient for TAS scheduling (guard bands would need to be 100× larger). The automotive gPTP profile (per AUTOSAR and AVNU) mandates hardware timestamping on all bridges. GNSS as grandmaster provides TAI (International Atomic Time) traceability, which is required for V2X communication time alignment.
🔬 Deep Dive — Core Concepts Expanded
This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.
Key principles to reinforce:
- Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
- Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
- Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.
🏭 How This Topic Appears in Production Projects
- Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
- Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
- Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.
⚠️ Common Mistakes and How to Avoid Them
- Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
- Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
- Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
- Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.
📊 Industry Note
Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.