PMU / Synchrophasor (IEEE C37.118) for Smart Grid
← Back to: Smart Grid & Power Distribution
This page brings together when a PMU is really needed, what IEEE C37.118 requires, and how timing, ADC, FPGA/SoC, clocking, Ethernet and security choices fit into those limits, so a synchrophasor design can be specified and verified with clear, practical constraints.
What this page solves
This page focuses on how to plan and implement a phasor measurement unit (PMU) that complies with IEEE C37.118. The goal is to turn vague requirements such as “synchrophasor support” into a concrete signal chain from CT/VT sensing through synchronous ADCs, timestamping, FPGA/SoC processing and out to Ethernet or TSN.
The content is written for situations where phasor data must feed protection, dispatch and situational awareness systems, and where latency, accuracy and availability are all under tight constraints. Instead of looking at the PMU as a black box, each block in the chain is mapped to practical design decisions and IC roles.
The focus is on the hard trade-offs that usually block progress: how fast ADCs actually need to be, how much timestamp jitter can be tolerated, how to split a latency budget across acquisition, compute and network, and when it is worth paying for higher performance clocks, ADCs or FPGAs.
- Clarify when a true IEEE C37.118 compliant PMU is required versus a “PMU-like” function.
- Translate phasor accuracy and frame rate targets into ADC, clock and FPGA/SoC requirements.
- Define a realistic latency budget from CT/VT through to SCADA and protection IEDs.
- Place the PMU correctly in the substation alongside protection, PQ and time-sync functions.
Where the PMU sits in the system
A grid PMU sits between high-voltage CT/VT sensing and the substation communication backbone. Its job is to turn synchronised ADC samples into phasor frames with timestamps that share the same time base as protection relays, power quality meters and SCADA or WAMS systems.
The PMU signal chain can be viewed as four time-critical stages: acquisition → timestamp → compute → publish. A practical latency budget often looks like: acquisition within about 1 ms, timestamp jitter below 1 µs, phasor computation within 5–10 ms, and end-to-end publish to downstream consumers within 20–100 ms depending on the application.
Upstream, the PMU consumes synchronised voltage and current channels from CT/VT AFEs and high-resolution ADCs. Downstream, it drives Ethernet or TSN links towards protection IEDs, PQ analyzers, SCADA gateways and wide-area monitoring systems. A shared time-sync infrastructure (GPS, PTP or TSN time) must feed the PMU alongside other time-aware devices so that all modules interpret phasor angles on the same time axis.
- Upstream: CT/VT, isolation, AFEs and synchronised ADC channels provide raw samples.
- PMU core: buffering, timestamp alignment and phasor computation implement IEEE C37.118 logic.
- Downstream: Ethernet or TSN transports phasor frames to IEDs, PQ, SCADA and WAMS.
- Time-sync: GPS/PTP/TSN time is shared across PMU, protection relays and PQ analyzers.
Key requirements & constraints
A PMU that complies with IEEE C37.118 is constrained by more than one headline metric. Practical design work must balance sampling and resolution, time synchronisation accuracy, compute and buffering delay, frame rate and network behaviour under realistic system loads.
The table below summarises typical target ranges that keep most transmission and substation projects within C37.118 limits while leaving margin for protection and control functions. Exact numbers still depend on grid frequency, voltage level, and whether the PMU also serves as a power quality front end.
| Parameter | Typical target / range | Why it matters |
|---|---|---|
| ADC sampling rate | ≥ 4–8 kSPS per channel (16 kSPS+ when PQ is combined) | Supports accurate synchrophasor estimation and gives enough points per cycle for frequency and ROCOF tracking without overloading the processing pipeline. |
| ADC resolution / ENOB | Effective > 16 bits, often 20–24-bit ΣΔ for high-performance designs | Reduces noise and quantisation error so that total vector error (TVE) remains within limits, and enables the same front end to support power quality analysis. |
| Input dynamic range | Covers normal operation plus expected overload and fault levels | Prevents clipping during faults so that phasors stay meaningful during the events that most need accurate phase, magnitude and frequency information. |
| GPS / PTP sync accuracy | ≤ 1 µs at the PMU time base | Keeps time error small enough that phase angles from different PMUs can be compared safely for wide-area protection, oscillation detection and stability studies. |
| Timestamp latency & jitter | Total path ≤ 10 µs, jitter in the low-microsecond range | Minimises angle noise introduced by timing uncertainty and keeps the relationship between sample windows and time tags predictable across the system. |
| Phasor compute delay | Group delay ≤ 1–2 cycles (for 50/60 Hz grids) | Keeps computed phasors close enough in time to the underlying waveform so that protection-assisted schemes can still act on the data. |
| Data publish rate (frame rate) | 30–120 frames per second, depending on class and use case | Higher frame rates improve observability and oscillation tracking, but raise network load and processing requirements in IEDs and WAMS applications. |
| End-to-end delay to consumers | Typically 40–80 ms for protection use, up to about 100 ms for WAMS | Sets limits on how much delay can be introduced by buffering, compute stages and network hops before phasor data becomes too stale for control actions. |
| Channel count & topology | Sized for all phases, busbars and lines that need synchrophasors | Drives requirements for ADC multiplexing, FPGA/SoC resources and time-sync distribution, especially when multiple voltage levels are monitored in one device. |
| Availability & redundancy | Redundant clocks, paths or PMU modules where protection depends on phasors | Ensures synchrophasor streams remain available during hardware failures or communication outages in stations that rely on PMU-assisted protection or control. |
In practice, these numbers are tuned per project. The most critical point is to assign a clear latency and error budget to each stage of the chain so that sampling, time-sync, computation and networking do not fight each other.
Architecture & implementation options
Several hardware and system architectures can deliver synchrophasor functionality. Choosing between them is mainly a question of latency targets, channel count, required precision, integration with power quality functions and the available design and maintenance skills.
The table below compares representative options, from low-latency FPGA-centric solutions through combined PQ and PMU platforms up to modular cards and native IED implementations. Each option can satisfy C37.118, but the trade-offs are very different.
| Architecture | Strengths | Limitations | Typical use cases |
|---|---|---|---|
| High-speed ADC + FPGA PMU | Lowest and most deterministic latency. Tight control over the complete measurement and phasor pipeline. Scales well to many channels and voltage levels. | Higher BOM and development cost. Requires strong FPGA and DSP expertise. Updates and feature changes demand careful verification. | Transmission substations, wide-area protection schemes, projects with strict delay limits and demanding channel counts. |
| ΣΔ ADC + SoC DSP (PQ + PMU) | High resolution front end supports power quality and PMU functions on the same hardware. SoC platforms offer flexible DSP capabilities and easier firmware updates. | ΣΔ converters and digital filters add delay. CPU load and scheduling must be controlled to avoid variable phasor latency. High frame rates can stress the SoC. | Substation meters and analyzers that combine revenue metering, PQ and synchrophasors. Stations where moderate latency is acceptable. |
| Modular PMU card with TSN/Ethernet | Adds PMU capability to existing IEDs or control cabinets without redesigning the main hardware. Clear responsibility boundaries between PMU card and host system. | Strong dependence on a robust PTP or TSN time backbone. Mechanical and EMC constraints of the host rack can limit performance. Integration still needs careful planning. | Retrofit projects, legacy substations that need synchrophasors, installations where host devices already provide suitable AFEs and time-sync. |
| IED with native FPGA C37.118 stack | Protection, control and PMU share a single hardware platform. Phasor data can feed local decision logic without leaving the device. Asset and spare management is simpler. | Very high design complexity. Firmware updates impact both protection and PMU behaviour. Users have limited visibility into internal implementation choices. | Vendor-specific flagship IEDs where PMU support is a built-in feature and tight coupling with protection logic is desired. |
| Lightweight PMU-like function on MCU/SoC | Uses relatively low-cost ADCs and MCUs to generate phasor-like data for monitoring. Simple to integrate in small-scale or distributed devices. | Typically does not meet full C37.118 requirements for accuracy and timing. Limited channel count and headroom for PQ analysis or advanced functions. | Microgrids, small substations and LV panels where phasor information is useful for visualisation and trend analysis rather than strict protection or compliance. |
A practical selection process starts by fixing end-to-end latency and frame rate targets, then checking which architectures can realistically meet those numbers for the required channel count and station topology. Power quality, budget and maintenance strategy usually decide the final choice.
Time sync & timestamping
A synchrophasor system relies on a precise and stable time base. The PMU itself does not create time; it consumes time from GNSS receivers, PTP or TSN networks and disciplined oscillators, and then applies this time to ADC sampling and phasor timestamps. Any error in this chain appears directly as angle noise and TVE.
In typical deployments, GNSS provides an absolute reference through PPS outputs to a station clock, which then drives PTPv2 or 802.1AS time distribution to PMUs, protection IEDs, PQ analyzers and SCADA gateways. NTP usually plays only a background role for management systems, because its accuracy is not sufficient for synchrophasor alignment across sites.
- GNSS/PPS: high-accuracy station reference for sub-microsecond master clocks.
- PTPv2 / IEEE 1588: primary mechanism to distribute time with hardware timestamp support.
- TSN (802.1AS): time-aware Ethernet profile that maintains a shared time domain.
- NTP: secondary role for general IT infrastructure, not for PMU timestamp alignment.
The distinction between hardware and software timestamping is critical. Hardware timestamping in PHYs, MACs and time-aware switches removes queuing and OS jitter from measurements and enables microsecond level alignment. Software timestamping through stacks and drivers introduces unpredictable delay and is rarely compatible with tight synchrophasor budgets.
Oscillator stability underpins time performance between sync updates. Station clocks often use OCXOs or better devices to keep PTP grandmasters stable during GNSS outages. PMU boards commonly use TCXOs or OCXOs disciplined by PTP so that ADC sampling clocks and internal timestamp counters track the common time domain with low drift and jitter.
Switches and PHYs in the path must support IEEE 1588 or 802.1AS hardware assist. Devices that simply forward packets without time awareness add variable latency and can degrade PTP performance from micro- second to tens of microseconds or more. PMU planning therefore starts with a clear view of the GNSS, PTP and TSN architecture of the substation.
C37.118 compliance & testing
Synchrophasor equipment is expected to conform to IEEE C37.118.1 for performance and IEEE C37.118.2 for communication. Together these documents define how accurate, how fast and how predictable PMU outputs must be, and how phasors, frequency and status information are encoded on the wire for downstream devices.
The standard introduces two main performance classes. P-class PMUs are optimised for protection and fast dynamic events, with tighter delay limits and specific requirements under transient conditions. M-class PMUs are optimised for measurement and analysis, with stronger accuracy requirements during steady-state operation and a focus on long-term observability.
- P-class: prioritises fast and predictable response during faults and switching events.
- M-class: prioritises accuracy under small disturbances and steady-state conditions.
- Some devices support both classes or selectable profiles to match different applications.
Compliance testing typically exercises three core performance metrics. Total Vector Error (TVE) quantifies combined magnitude and angle error of the reported phasor relative to a reference. Frequency Error (FE) evaluates how accurately the PMU tracks system frequency, and ROCOF (Rate of Change of Frequency) measures the quality of frequency ramp estimates during dynamic events.
In test laboratories, reference waveform generators inject controlled scenarios such as steady-state operation, frequency ramps, angle steps and voltage swings. The PMU under test streams C37.118 frames to an analyser, which computes TVE, FE and ROCOF versus the reference and verifies that results remain within limits defined for the selected class and test condition.
C37.118.1 also places bounds on the latency between the actual waveform and the corresponding phasor output. Protection-oriented profiles have tighter delay windows, while measurement-oriented profiles may allow slightly longer but more stable delays. The PMU must declare its nominal delay and remain inside an allowed tolerance band during all specified test cases.
C37.118.2 defines the structure of synchrophasor data frames. Each frame carries a timestamp, one or more voltage and current phasors, frequency and ROCOF values, plus status and quality flags. These flags indicate conditions such as data validity, test mode, time-sync state and configuration changes, and they are essential for downstream systems to interpret the stream correctly.
A practical compliance strategy aligns design choices for ADC, clocks, algorithms and networking with the C37.118 test plan from the beginning. This avoids late surprises when TVE, FE, ROCOF or latency measurements reveal limits that the chosen architecture cannot meet.
IC selection mapping (functional view)
This section links the PMU architecture and requirements to practical IC types and typical vendors. It groups devices by function, such as high-speed or sigma-delta conversion, timestamping PHYs, FPGA and SoC compute platforms, precision clocking, security elements and TSN-capable Ethernet components, so that system, hardware and sourcing teams can align decisions from the same map.
Exact part numbers are project-specific and depend on channel count, performance targets, form-factor constraints and preferred ecosystems. The focus here is on IC categories and representative suppliers that are commonly used in synchrophasor and smart substation designs.
| Function | IC type | Representative vendors |
|---|---|---|
| High-speed / ΣΔ conversion | High-speed SAR / pipeline ADC, ΣΔ metering ADC, AFE / ADC SoC | Analog Devices, Texas Instruments, Renesas, Microchip |
| Timestamping & PTP transport | PTP-capable PHY / MAC with IEEE 1588 / 802.1AS hardware timestamps | Texas Instruments, Microchip, Broadcom |
| FPGA / SoC compute platform | SoC FPGA (Zynq-type), FPGA with DSP slices, DSP SoC | AMD Xilinx, Intel, Texas Instruments |
| Clocking & timing tree | OCXO / TCXO, PLL / clock generator, clock buffer / fan-out | Renesas (IDT), SiTime, Analog Devices |
| Security & secure boot | HSM, secure element, crypto co-processor | NXP, Infineon, STMicroelectronics |
| TSN-capable Ethernet | TSN switch / bridge, TSN-capable PHY / MAC | NXP, Microchip, Analog Devices |
For each functional block the PMU design must still verify datasheet limits against the latency, accuracy and time-sync budgets defined earlier in this page. Vendor families listed here are typical starting points rather than exhaustive lists.
Request a Quote
Design checklist for PMU / synchrophasor implementation
Use this checklist to review a PMU design before lab testing and deployment. Each item links back to the section where the underlying assumptions, parameters and trade-offs are explained in more detail.
- Target C37.118 class defined: P-class, M-class or dual-class operation is explicitly defined, and performance targets match the selected class in terms of TVE, FE, ROCOF and delay (see C37.118 compliance & testing ).
- End-to-end delay window verified: The delay between reference waveform and phasor output is measured for all test conditions, and the nominal delay and tolerance fit within the allowed window for the chosen class (see C37.118 compliance & testing ).
- ADC conversion and jitter budgeted: Per-channel conversion delay, digital filter group delay and sampling jitter are included in the latency and TVE budget, with margins appropriate for the required accuracy (see Key requirements & constraints ).
- Compute and frame-rate capability validated: FPGA / SoC resources are sized and tested for the intended phasor frame rate (e.g. 30/50/60/120 fps) with full channel count, including protocol stack and optional security processing (see Architecture & implementation options ).
- PTP / TSN hardware timestamping confirmed end-to-end: All nodes in the time path (station clock, switches, PHYs and PMU ports) provide IEEE 1588 / 802.1AS hardware timestamp assist or are explicitly accounted for as legacy hops in the time-error budget (see Time sync & timestamping ).
- OCXO / TCXO stability and holdover analysed: Station and board-level oscillators meet the required ppm stability, phase noise and holdover performance so that FE and TVE limits are respected during temperature variation and short GNSS outages (see Time sync & timestamping ).
- Multi-channel and multi-voltage configurations covered: Testing includes maximum channel configuration (all voltage and current phasors) and any multi-board or modular PMU topology, with channel-to-channel alignment confirmed (see Key requirements & constraints ).
- Network and back-end capacity aligned with frame rate: Substation network, TSN schedule and SCADA / WAMS receivers are verified to handle the planned phasor frame rate and channel count without congestion or excessive buffering (see Architecture & implementation options & C37.118 compliance & testing ).
- IC categories mapped for all critical functions: ADC / AFE, FPGA / SoC, PTP-capable PHY, clocking devices, TSN Ethernet parts and security ICs are each mapped to at least one suitable IC family from preferred vendors (see IC selection mapping ).
- Watchdog and secure boot paths implemented: Hardware watchdog coverage and secure boot or equivalent integrity checks are in place for the PMU processing chain, with behaviour reflected in status and quality flags if a fault is detected (see IC selection mapping ).
- External documentation exposes key parameters: Datasheets and integration guides clearly state phasor class, nominal delay, frame-rate options, channel limits, time-sync method and security features so that system integrators can design around the PMU transparently.
Projects with more stringent grid codes or internal standards may tighten one or more of these checkpoints. The values and classes defined in this page provide a baseline for typical synchrophasor deployments.
Request a Quote
FAQs about PMU / synchrophasor design
These twelve questions capture the most common design and planning decisions around PMUs in smart grid and substation projects. Each answer stays compact enough to reuse in technical notes, design reviews and project specifications, while matching the FAQ structured data at the end of this page.
When do I actually need a PMU instead of a basic PQ analyzer?
A PMU is needed when phase angle relationships across buses matter, not just local voltage quality. Typical drivers are wide-area oscillation monitoring, stability studies, remedial action schemes and model validation. If protection, WAMS or planners require synchronized phasors from multiple locations, a PMU is the correct instrument class.
How accurate should GPS/PTP timestamps be to meet C37.118 class M?
Class M assumes that timestamp errors are small compared with the allowed Total Vector Error. In practice, PMUs targeting class M aim for end-point time alignment on the order of one microsecond or better. This usually requires GNSS-disciplined clocks, PTP or TSN networks and hardware time stamping throughout the time path.
What ADC sampling rate is required for synchrophasor applications?
Synchrophasor applications typically use sampling rates from a few kilohertz per channel up to tens of kilohertz, depending on desired bandwidth and dynamic response. Higher rates allow better harmonic discrimination and transient tracking, but also increase data and processing load. The chosen rate must align with the phasor algorithm and latency budget.
Is an FPGA mandatory for a PMU, or can a SoC handle it?
An FPGA is not mandatory, but it is often preferred when low and deterministic latency is critical. Many designs use SoC FPGAs that combine processors with programmable logic. For moderate channel counts and relaxed delay limits, a DSP or SoC can host synchrophasor algorithms, provided real-time scheduling and resource margins are proven.
How much latency is allowed between AFE and phasor data publish?
Allowable latency depends on the selected C37.118 class and application. The total delay from analog front-end through ADC, digital processing and communication must stay within the delay window defined by the standard. Protection-oriented use cases normally demand shorter and more tightly controlled delay than measurement-only PMUs.
What are the real differences between P-class and M-class PMUs?
P-class PMUs are tuned for protection, with emphasis on fast response and acceptable performance during large disturbances. M-class PMUs target measurement and analysis, with tighter accuracy under small deviations and steady-state conditions. Test sets, delay limits and disturbance responses differ, so selecting the class should follow the intended use of the data.
Do I need TSN Ethernet to deploy PMUs in modern substations?
TSN is not strictly required, but it simplifies building deterministic networks where time sync, control and synchrophasor streams share the same fabric. In many retrofit projects, conventional industrial Ethernet with IEEE 1588 is sufficient. New greenfield substations increasingly consider TSN to unify protection, automation and PMU traffic with one profile.
What clock sources are valid for PMU timestamping and holdover?
Typical PMU clock sources include GNSS-disciplined station clocks providing PPS and time-of-day, PTP or TSN networks distributing that time, and local OCXO or TCXO oscillators disciplined by the network. Free-running crystal oscillators without discipline rarely deliver the stability needed to maintain microsecond-level alignment during holdover intervals.
Can a PMU and a PQ analyzer be integrated on the same DSP or SoC?
A PMU and PQ analyzer can share the same DSP or SoC if the device has enough processing headroom and memory bandwidth. The design must prove that adding PQ algorithms does not violate synchrophasor accuracy or delay limits. Careful partitioning, scheduling and profiling are required, especially at higher phasor frame rates.
How does a PMU interact with protection relays and substation IEDs?
PMUs supply time-aligned phasors, frequency and ROCOF to relays, IEDs and wide-area controllers. These devices use synchrophasors for functions such as oscillation damping, system integrity protection schemes and post-event analysis. In some architectures, PMUs feed a gateway that redistributes processed information to protection and automation devices.
Should the FPGA or SoC include secure boot for a PMU design?
Secure boot is strongly recommended for PMU designs, especially when data influences protection or control decisions. A hardware root of trust, signed firmware and protected key storage reduce the risk of malicious or tampered code generating false phasors. Many utilities and cybersecurity profiles now treat secure boot as a baseline requirement.
What tests are required for PMU certification under C37.118?
Certification under C37.118 involves a defined set of steady-state and dynamic tests that measure Total Vector Error, Frequency Error, ROCOF accuracy and output delay across many operating conditions. Test equipment applies controlled voltage and current patterns, and the PMU output is compared against reference values to confirm compliance with the selected performance class.
