|
| 1 | +# PTP-P1.5 Runtime Completion |
| 2 | + |
| 3 | +PTP-P1.5 turns the PTP-P1 wire engine into a reusable runtime/control layer while preserving the ESP32-P4 hardware timestamp path. |
| 4 | + |
| 5 | +This remains a laboratory timing companion for troubleshooting and interoperability. It is not a GPS-backed clock, a certified grandmaster, or a formal IEC/IEEE 61850-9-3 conformance claim. |
| 6 | + |
| 7 | +## Portable runtime |
| 8 | + |
| 9 | +`include/ariec61850/time_sync/ptp_runtime.hpp` provides a platform-neutral PTP publisher runtime on top of the existing codec. |
| 10 | + |
| 11 | +The runtime owns: |
| 12 | + |
| 13 | +- publisher profile/configuration |
| 14 | +- ClockIdentity parse/format and EUI-64-style MAC derivation |
| 15 | +- lifecycle (`start`, `stop`, stopped-only `reconfigure`) |
| 16 | +- Announce/Sync due scheduling |
| 17 | +- per-message sequence counters |
| 18 | +- Announce, Sync, Follow_Up, Pdelay_Resp and Pdelay_Resp_Follow_Up frame preparation |
| 19 | +- publisher status and send/error accounting |
| 20 | + |
| 21 | +The runtime intentionally does not own: |
| 22 | + |
| 23 | +- an operating-system thread |
| 24 | +- a NIC or transport driver |
| 25 | +- a PTP clock servo |
| 26 | +- absolute UTC traceability |
| 27 | +- lock/holdover state |
| 28 | +- `smpSynch` promotion |
| 29 | + |
| 30 | +Those boundaries keep the core portable across desktop, embedded and analyzer applications. |
| 31 | + |
| 32 | +## Portable publisher options |
| 33 | + |
| 34 | +`PtpPublisherOptions` covers the relevant ARIEC61850 publisher profile: |
| 35 | + |
| 36 | +- `transport_specific` |
| 37 | +- `domain_number` |
| 38 | +- source MAC |
| 39 | +- optional VLAN ID / PCP |
| 40 | +- ClockIdentity and port number |
| 41 | +- Announce / Sync intervals |
| 42 | +- two-step policy |
| 43 | +- peer-delay response policy |
| 44 | +- priority1 / priority2 |
| 45 | +- clockClass / clockAccuracy |
| 46 | +- offsetScaledLogVariance |
| 47 | +- timeSource |
| 48 | +- currentUtcOffset |
| 49 | +- stepsRemoved |
| 50 | + |
| 51 | +Reconfiguration is deliberately rejected while the runtime is running. A control plane must perform a safe `stop -> reconfigure -> start` transaction instead of mutating live publisher state. |
| 52 | + |
| 53 | +## Publisher status |
| 54 | + |
| 55 | +`PtpPublisherStatus` exposes: |
| 56 | + |
| 57 | +- running state |
| 58 | +- start time |
| 59 | +- last send time |
| 60 | +- Announce sent |
| 61 | +- Sync sent |
| 62 | +- Follow_Up sent |
| 63 | +- peer-delay response frames sent |
| 64 | +- last runtime error |
| 65 | + |
| 66 | +This is the reusable status contract for future GUI and analyzer integrations. |
| 67 | + |
| 68 | +## ESP32-P4 hardware adapter |
| 69 | + |
| 70 | +`embedded/esp32p4_smv_injector/main/ptp_lab_task.cpp` is now an adapter around `PtpPublisherRuntime` rather than a second PTP runtime implementation. |
| 71 | + |
| 72 | +The adapter remains responsible only for ESP-specific work: |
| 73 | + |
| 74 | +- FreeRTOS task scheduling on CPU0, separate from the realtime SV task |
| 75 | +- ESP-IDF Ethernet transport |
| 76 | +- enabling the ESP32-P4 IEEE1588 hardware clock |
| 77 | +- hardware TX descriptor timestamp capture for Sync and Pdelay_Resp |
| 78 | +- hardware RX descriptor timestamp capture for Pdelay_Req |
| 79 | +- RX queueing and task notification |
| 80 | + |
| 81 | +Two-step timestamp evidence remains: |
| 82 | + |
| 83 | +- Sync carries zero originTimestamp |
| 84 | +- actual Sync hardware TX timestamp becomes Follow_Up preciseOriginTimestamp |
| 85 | +- Pdelay_Req hardware RX timestamp becomes Pdelay_Resp requestReceiptTimestamp (`t2`) |
| 86 | +- Pdelay_Resp hardware TX timestamp becomes Pdelay_Resp_Follow_Up responseOriginTimestamp (`t3`) |
| 87 | + |
| 88 | +The hardware implementation therefore remains stronger than the original desktop ARIEC61850 software-timestamped publisher. |
| 89 | + |
| 90 | +## ESP runtime control bridge |
| 91 | + |
| 92 | +The C-compatible adapter API is designed so a future GUI, USB/RPC control task, or embedded application can control PTP without recompiling the PTP core. |
| 93 | + |
| 94 | +Available operations: |
| 95 | + |
| 96 | +- `ar_ptp_lab_get_default_config` |
| 97 | +- `ar_ptp_lab_configure` |
| 98 | +- `ar_ptp_lab_get_config` |
| 99 | +- `ar_ptp_lab_start` |
| 100 | +- `ar_ptp_lab_stop` |
| 101 | +- `ar_ptp_lab_is_running` |
| 102 | +- `ar_ptp_lab_get_status` |
| 103 | + |
| 104 | +Runtime configuration is accepted only while PTP is stopped. The live status bridge exposes lock-free counters for Announce, Sync, Follow_Up, peer-delay response frames and TX failures. |
| 105 | + |
| 106 | +Kconfig remains the firmware default profile. A runtime configuration override can replace it before the task is started. |
| 107 | + |
| 108 | +## ESP Kconfig defaults |
| 109 | + |
| 110 | +The ESP32-P4 profile now exposes: |
| 111 | + |
| 112 | +- PTP enable |
| 113 | +- domain |
| 114 | +- transportSpecific |
| 115 | +- optional ClockIdentity override |
| 116 | +- port number |
| 117 | +- optional VLAN / VID / PCP |
| 118 | +- Announce interval |
| 119 | +- Sync interval |
| 120 | +- Pdelay response enable |
| 121 | +- priority1 / priority2 |
| 122 | +- clockClass |
| 123 | +- clockAccuracy |
| 124 | +- offsetScaledLogVariance |
| 125 | +- timeSource |
| 126 | +- currentUtcOffset |
| 127 | + |
| 128 | +Defaults remain intentionally conservative: clockClass 248, clockAccuracy Unknown, variance `0xFFFF`, timeSource Internal Oscillator. |
| 129 | + |
| 130 | +## Validation |
| 131 | + |
| 132 | +PTP-P1.5 has dedicated portable regression coverage for: |
| 133 | + |
| 134 | +- ClockIdentity parsing/formatting |
| 135 | +- profile validation |
| 136 | +- stopped-only reconfiguration |
| 137 | +- due scheduling |
| 138 | +- per-message sequence behavior |
| 139 | +- status accounting |
| 140 | +- two-step Sync/Follow_Up |
| 141 | +- one-step suppression of Follow_Up |
| 142 | +- Pdelay request sequence/log interval preservation |
| 143 | +- supplied `t2` / `t3` timestamp placement |
| 144 | + |
| 145 | +The strict PTP profile is built on GCC, Clang and MSVC with warnings treated as errors. The ESP workflow builds a non-default PTP profile on ESP-IDF 5.5.4, while the normal ESP32-P4 SMV firmware build verifies that PTP remains default-off and does not regress the injector. |
| 146 | + |
| 147 | +## Safety boundary |
| 148 | + |
| 149 | +PTP-P1.5 does **not** change Sampled Values synchronization claims. The generic SV default remains `smpSynch=0`, and the ESP injector must not promote it merely because PTP frames are being transmitted or observed. |
| 150 | + |
| 151 | +Promotion to `smpSynch=1/2` belongs to PTP-P2 after measured clock discipline, offset/delay qualification, lock/holdover state, and explicit policy evidence exist. |
0 commit comments