What this page solves

In many HVDC projects, most design effort goes into the main converter, protection relays and PMUs. Auxiliary control around the valve hall is treated as a side board, which often leads to scattered valve health data, poorly supervised optical links and unknown clock quality until an incident happens.

This page focuses on the auxiliary control system that keeps the valve hall observable and explainable: monitoring valve and high-voltage submodule status, keeping isolated sensing and optical links online in all operating modes, and maintaining redundant clocks and event logs even when the main power loop is stopped or in commissioning.

To avoid overlap with other topics, this page deliberately covers health and availability, not core protection, not billing metering and not synchrophasor analytics.

• This page is not a protection relay tutorial — trip decisions belong to the Protection Relay page.
• This page is not about synchrophasor calculations — PMU and IEEE C37.118 live on the Synchrophasor page.
• This page is not a generic HV isolation design guide — insulation rules sit under HV Isolation & Sensing.
• This page is not about grid-tie control loops — those are discussed on the PV Inverter / STATCOM pages.

This page is for you if:

• Valve health, optics and clocks need a clear place in the HVDC system architecture.
• Devices and modules for isolated sensing, optical links and clock trees in converter stations must be selected and compared.
• Specifications or RFQs for an “HVDC auxiliary control board” need concrete hooks instead of vague bullet points.

Where auxiliary control fits in an HVDC link

Along the HVDC link, auxiliary control sits between the noisy valve hall and higher-level systems. Physical quantities such as valve currents, blocking states, module voltages, temperatures, cooling flow and cabinet interlocks are sensed close to the valves, digitized and pushed across the insulation barrier. On the safe side, an auxiliary controller aggregates these streams, checks basic sanity and exposes consistent health information and events.

The chain can be thought of as three stages: sensing in the valve hall, isolating and transporting the data over kV insulation distance, and cleaning it up for SCADA, protection and time-sync modules. Auxiliary control is an information source for those systems. Trip decisions stay with protection relays, wide-area time alignment stays with PMUs and station time-sync nodes.

Core building blocks of HVDC auxiliary control

An HVDC auxiliary control system can be viewed as four core domains working together: optical links that bridge the insulation barrier, isolated measurements that capture valve and support-system behavior, valve drive monitoring that tracks gate health and events, and redundant clocks that keep timing stable for all of the above. Each domain pulls in different IC families and has its own design hooks.

The following overview highlights what each domain watches, the typical performance targets and the IC categories that usually appear in converter station designs. Later sections expand these blocks in more detail, but this grid can act as a quick map when planning or reviewing an auxiliary control stack.

Optical links for high-voltage environments

In an HVDC converter station, the valve hall sits at high potential and inside a harsh EMI environment. Large dV/dt and dI/dt, ground potential differences and long physical distances make it difficult for copper links to provide reliable, noise-free communication between the valve hall and the control room. Optical links break galvanic paths, tolerate large potential differences and simplify insulation layouts.

A typical auxiliary-control link starts from isolated ADCs or ΣΔ modulators near the valves, passes through a serializer and line driver into an optical module, travels over multimode or single-mode fiber, and is recovered on the control-room side by a receiver, deserializer and clock-data recovery block feeding the auxiliary controller. Design parameters such as reach, data rate, BER target and temperature grade guide module and IC selection.

Typical IC and module roles in an optical link:

• Line coder and SerDes blocks that serialize digitized measurements into robust high-speed streams.
• Optical modules such as industrial SFP or custom optical engines with defined reach, diagnostics and temperature grade.
• Supervisory logic that monitors link status, loss-of-signal, error counters and supports dual-link failover where required.
• Optional retimers or clock-data recovery ICs when jitter margins and longer links push the physical layer limits.

Isolated measurement chain for HVDC valves

HVDC valves require a dedicated isolated measurement chain on the auxiliary side, separate from the primary protection path. This chain captures valve currents, arm and module voltages, capacitor voltages, cooling system status and cabinet temperatures with a focus on stability, repeatability and long-term trend visibility rather than ultra-fast trip decisions.

Typical architectures combine shunts or CTs with isolated amplifiers or sigma-delta modulators for current, high-voltage dividers with isolation amplifiers or ΣΔ converters for valve and module voltages, and standard ADCs for cooling and auxiliary sensors. Key parameters include common-mode transient immunity, linearity, temperature drift and latency, which are tuned for clean steady-state data and predictable timing.

The primary protection chain often measures similar quantities but prioritizes speed and robustness for trip decisions. The auxiliary measurement chain prioritizes accurate baselines, long-term trends and health indicators, even if that means slightly lower bandwidth or higher latency.

Valve drive monitoring & event logging

Valve drive monitoring and structured event logging make misfires, stuck conditions and repeated retries visible instead of hidden inside the valve hall. Gate drivers, drive supplies and local sensors expose status pins and counters that auxiliary control can observe, time-stamp and store, creating a usable history for diagnostics and maintenance planning.

The resulting information supports primary protection and SCADA without taking over trip authority. Protection relays still decide when to trip; auxiliary control provides context and trends: when gates started responding slowly, when temperatures drifted upward, and when optical or drive rails caused recurrent disturbances.

Typical event types tracked by the auxiliary system include:

• Gate not responding within a defined time window after a firing command.
• Valve stuck-on or stuck-off indications from gate-drive diagnostics.
• Valve or module over-temperature trends and repeated thermal warnings.
• Excessive retries of a start or blocking sequence for a given valve group.
• Undervoltage events on gate-drive supplies and auxiliary power rails.
• Frequent optical link dropouts affecting valve-related communication.

How valve-drive events are consumed by higher-level systems:

• SCADA uses the events for alarms, operator dashboards and trend plots that highlight deteriorating valves and cooling paths.
• CMMS and asset-management tools use the logs to open work orders, schedule inspections and compare valve performance against vendor expectations.
• Protection relays receive status inputs that indicate degraded or unavailable valves but retain full trip authority and their own measurement chains.

Redundant clocking & timing distribution

Auxiliary control in an HVDC converter station depends on a stable local time base. System clocks drive the auxiliary controller MCU or FPGA, reference clocks feed optical links and sigma-delta or ADC devices, and fan-out networks distribute timing to measurement and communication domains. Redundant clocking ensures that these functions survive failures of individual oscillators or time sources.

This section focuses on local redundancy and distribution, not on how absolute time is obtained. Station time sources such as PTP, NTP or GNSS, and synchrophasor algorithms, belong to the Substation Time Sync and PMU pages. Here the emphasis is on how to combine oscillators, PLLs and clock switches into robust local clock trees for auxiliary control.

Typical local clocking schemes

Single OCXO with simple fan-out

A single oven-controlled crystal oscillator provides a stable frequency reference that is buffered and fanned out to the auxiliary controller, optical transceivers and measurement converters. This approach keeps part count low and is easy to debug, making it attractive for smaller stations or less critical deployments, but the OCXO becomes a single point of failure.

Dual OCXO with clock switch and supervision

Two independent OCXOs feed a clock mux or switch that monitors amplitude, frequency and phase drift on the active reference. When the primary source fails or moves beyond defined limits, the switch cleanly transfers to the backup. This scheme provides real failover at the cost of additional oscillators, mux devices and supervisory logic.

OCXO with PTP-disciplined PLL

A high-quality OCXO is combined with a PTP-aware PLL or digital PLL that disciplines the oscillator using network time stamps. When PTP is available, the PLL aligns local time to the station reference; when PTP is lost, the OCXO provides holdover. This option offers strong long-term accuracy and good holdover for mixed auxiliary control, PMU and Ethernet timing, at the expense of higher configuration complexity.

Reliability patterns & fail-safe / fail-operational strategies

Auxiliary control in an HVDC system sits between critical protection functions and long-term asset management. Its reliability strategy must balance fail-safe behavior, where untrustworthy data is explicitly marked as degraded, with fail-operational behavior, where monitoring and logging continue even when parts of the main converter are offline or communication paths are limited.

Fail-safe behavior means that when measurements, clocks or communication no longer meet defined quality thresholds, auxiliary control does not silently continue as if nothing happened. Instead it exposes “unknown” or “degraded” states so that protection and SCADA can fall back to conservative logic. In contrast, fail-operational behavior keeps local monitoring and logging active wherever possible, turning planned outages or disturbance periods into opportunities for diagnostics rather than blind spots.

Reliability patterns for HVDC auxiliary control

IC roles & vendor mapping

HVDC auxiliary control for valve monitoring and health supervision depends on a set of well-defined IC roles. Each role supports a specific part of the chain: optical links across high-voltage barriers, isolated measurement for valve currents and voltages, redundant clocking, local processing and robust power supervision. This section organises these roles, maps them to major vendors and lists example part numbers that can be used as starting points for BOM and RFQ work.

The focus is on role-level mapping rather than detailed part-to-part comparisons. The goal is to help narrow a wide device catalogue down to a shortlist per function, and to show where the main IC vendors have mature offerings for HVDC auxiliary control boards.

IC role overview for HVDC auxiliary control

Isolation & measurement ICs: vendor mapping and example parts

Optical links and clocking devices

Controllers, FPGAs, power and supervision ICs

RFQ preparation checklist for HVDC auxiliary control boards

When approaching distributors or original manufacturers for HVDC auxiliary control designs, detailed context helps them recommend suitable IC combinations much faster than a bare part-number request. Including the following information in RFQs and BOM submissions makes it easier to converge on the right isolated measurement, optical link, clocking and control devices.

• Electrical and insulation environment: valve-side voltage range, main DC bus level, expected current ranges, insulation class, surge and lightning requirements (for example, target IEC 61000-4-5 levels).
• Timing and synchronisation needs: whether alignment with substation PTP or PMU time is required, allowable jitter and phase error for sampling clocks, and desired holdover time in case station time sources are lost.
• Optical link parameters: fibre type (multimode or single-mode), typical and maximum cable lengths, required data rates and whether the link carries proprietary frames or standard Ethernet-based traffic.
• Environmental conditions: operating temperature range, humidity and condensation risks, presence of pollution or corrosive atmospheres, and whether the design is located in the valve hall or control room.
• Reliability and maintenance strategy: desired lifetime, allowance for online replacement or redundant switchover, expectations for diagnostic coverage and whether a central maintenance platform or CMMS is used.
• System architecture constraints: preferred MCU or FPGA ecosystem, existing tool chains in the organisation, footprint constraints and acceptable power budgets for the auxiliary control board.

Combining this RFQ information with the IC roles and vendor mapping in this section allows suppliers to propose focused shortlists rather than generic catalogues, and helps auxiliary control designs converge quickly on robust, maintainable device selections.

Design checklist & engineering inputs

Design checklist for HVDC auxiliary control

This checklist turns the architectural and reliability considerations on this page into concrete design questions. Working through each item helps define a consistent set of requirements for HVDC valve auxiliary control boards before schematic capture, device selection and RFQ work begin.

• Confirm HVDC pole voltage and configuration (for example ±320 kV, ±500 kV or ±800 kV, single or bipolar), and decide whether higher future voltage levels need to be supported by the same auxiliary control platform.
• Define the converter topology and number of valves and submodules that one auxiliary control board is expected to supervise, as this drives channel counts, link density and processing headroom.
• Specify the typical and worst-case distance between valve halls and control rooms for each link, so that optical budget, connector style and potential need for repeaters or intermediate nodes can be evaluated.
• List all quantities to be measured by auxiliary control (valve current, valve voltage, submodule capacitor voltage, cooling loop temperatures and flow, insulation resistance and so on) together with their normal operating ranges and absolute limits.
• Set target sampling rates for each measurement class, such as 50–100 kS/s per channel for valve currents and voltages, and 1–10 samples per second for temperatures and slow process variables.
• Define accuracy and drift targets for key measurements (for example ≤ 1 %FS over temperature, annual drift ≤ 0.2 %FS) and clarify whether the data will be used only for trends or also for supporting protection decisions.
• Confirm isolation ratings, working voltages and minimum CMTI requirements for the measurement chain so that isolated sigma-delta modulators, isolation amplifiers and digital isolators can be filtered accordingly.
• Decide the required data rate per optical link and the framing strategy: raw sampled streams, compact status frames or standards-based transports such as Ethernet or TSN for certain segments.
• Choose fibre type (multimode or single-mode), connector standard and industrial form factor (SFP, LC patch panels and so on) suitable for installation practices in valve halls and control rooms.
• Define the redundancy strategy for optical links: single link with monitored health, dual links with automatic failover, or separate upstream and downstream paths with independent diagnostics.
• Select a local clocking scheme for auxiliary control (single OCXO, dual OCXO with monitored switch or OCXO plus PTP-disciplined PLL) and state the expected holdover time when station time sources are lost.
• Specify timing alignment requirements towards station PTP or PMU time, including acceptable timestamp error (for example ±1 ms or tighter) and jitter targets for sampling clocks and SerDes references.
• Set target availability or MTBF figures for the auxiliary control function and clarify whether auxiliary outages are allowed during planned maintenance windows or must be masked by redundancy.
• Decide the redundancy level for controllers, measurement chains and power domains, for example dual auxiliary controllers per pole, dual optical links and dual-channel health monitoring for critical currents.
• Define a clear policy for fail-safe versus fail-operational behaviour: which functions must declare data as unknown when quality is low, and which functions should continue logging and trending even when main converters are offline.
• Describe self-diagnosis expectations, including minimum fault coverage for internal loops, memory and clock supervision, and how diagnostic results should be exposed to SCADA and maintenance tools.
• Set the required log retention window for detailed events and trends (for example at least 30 days) and define the maximum acceptable logging resolution to keep storage and bandwidth under control.
• Specify which systems will consume auxiliary data (traditional SCADA, asset health platforms, CMMS) and which protocols are preferred for exporting health metrics, events and configuration snapshots.
• Confirm expectations for firmware upgrade, remote diagnostics and service access, including whether secure remote connections or off-line log export are required for fault investigation.
• Define board-level constraints such as form factor, mounting style and power budget (for example total auxiliary control board power ≤ 20 W with derating at high ambient temperature).

Engineering inputs form for vendors and internal teams

The fields below capture the most important engineering inputs that device vendors and module suppliers need to recommend suitable isolated measurement, optical link, clocking, controller and power ICs for HVDC auxiliary control. Filling them in with realistic ranges and constraints greatly reduces the number of design iterations.

FAQs about HVDC auxiliary control

This FAQ section collects the most common boundary and design questions around HVDC auxiliary control: when to introduce a dedicated auxiliary layer, how it interacts with protection relays and SCADA, how optical links and clocks should be chosen, and which inputs vendors need before recommending concrete IC and module options.

When do I actually need a dedicated HVDC auxiliary control system instead of folding everything into the main control or protection platform?

Dedicated auxiliary control becomes necessary when valve health monitoring, logging and maintenance grow beyond what the main controller and protection relays can reliably handle. If the scheme needs many measurement points, long trend storage, complex diagnostics or independent reliability modes, a separate auxiliary layer keeps critical functions observable without overloading the core control platform.

Who has the final say in critical decisions: the auxiliary controller or the protection relays, and how should that boundary be defined?

Protection relays and main control retain authority over trips and blocking, while the auxiliary controller supplies high-quality status, health indicators and recommended actions. Define clear interfaces: auxiliary outputs data quality and suggested states, protection logic consumes these as inputs, but final tripping decisions and interlocks stay in the dedicated protection and converter control layer.

If the substation already has PMUs and a time-sync system, why does the auxiliary controller still need its own redundant local clocks?

Substation PMUs and time-sync systems provide global time, but local redundant clocks keep auxiliary sampling, optical links and event logs stable whenever the station reference is disturbed or unavailable. Local oscillators and PLLs limit jitter, maintain deterministic timing for converters and links, and preserve meaningful timestamps through network outages or sync transients.

Where is the practical boundary between optical fibre and copper links for HVDC auxiliary control in terms of distance, insulation and EMC?

In HVDC environments, optical fibre is preferred whenever long distances, high insulation levels, large ground potential differences or severe EMC conditions are expected. Copper may be acceptable over short runs in controlled environments, but for typical valve hall to control room routes, fibre links minimize common-mode stress, noise coupling and lightning-induced disturbances.

Can the HVDC auxiliary controller replace some parts of the traditional SCADA system, or should it only act as a data source and health monitor?

An auxiliary controller is best treated as a specialised data and health layer that sits between field equipment and SCADA. It aggregates measurements, performs local checks, manages logs and exposes concise health views. High-level operator commands, interlocks and cross-station coordination remain in SCADA and gateway systems rather than on the auxiliary board.

How should fail-safe and fail-operational behaviour be defined for the auxiliary controller in an HVDC scheme?

Fail-safe behaviour means that when data quality or internal health is doubtful, the auxiliary controller clearly marks information as unknown or degraded so protection is never misled. Fail-operational behaviour focuses on staying available during converter outages, continuing to monitor, log and diagnose while signalling reduced function, instead of silently dropping offline.

How long should event and trend logs be retained in the auxiliary controller to be practically useful for fault analysis and maintenance planning?

Log retention should be long enough to cover at least one full maintenance cycle and the investigation window for rare faults. Many HVDC projects target about thirty days of detailed local logs, with optional longer-term, lower resolution storage in central systems to support seasonal analysis, asset health trending and warranty discussions.

How can lifetime and ageing be estimated for optical links, isolated measurement chains and clock modules in an HVDC auxiliary control design?

Lifetime estimates combine device datasheet information, environmental stress and derating strategy. For optical links, consider optical power margin, connector cleanliness, temperature and vibration. For isolated measurement chains, review insulation ratings, CMTI margin and drift over time. For clock modules, evaluate ageing, frequency stability and holdover performance under expected temperature and supply conditions.

When does it make sense to use an FPGA or SoC FPGA in the auxiliary controller instead of a pure MCU solution?

An FPGA or SoC FPGA becomes attractive when many high-speed channels must be time stamped, voted, filtered or bridged across different protocols in parallel. If auxiliary control requires complex redundancy logic, deterministic latency and future protocol upgrades, programmable logic offers more headroom, while simpler, lower bandwidth schemes usually remain well served by MCUs.

How should the auxiliary controller be scoped relative to the HV isolation and protection relay pages so that responsibilities do not overlap?

HV isolation content focuses on generic insulation components, creepage, surge performance and isolation technologies. Protection relay material covers fault types, settings and trip algorithms. The auxiliary controller page concentrates on valve health, long-term trends, event logs, local redundancy and supporting links, reusing isolation devices and protection signals instead of duplicating their design handbooks.

Is it realistic to retrofit an HVDC auxiliary control layer to an existing scheme, or should it always be planned from the first design phase?

Retrofitting an auxiliary layer is feasible when existing schemes already expose measurement points, spare communication paths and cabinet space. If wiring, interfaces and time-sync were never planned, integration effort and downtime rise sharply. For new projects, auxiliary control should be planned from the first design phase so sensing, links and timing are provisioned cleanly.

What information should be shared with IC and module vendors so that auxiliary control requirements are understood correctly and not reduced to a vague part-number request?

Sharing only a desired part number rarely leads to good outcomes. A more effective RFQ bundles pole voltage, distances, sampling rates, accuracy and drift targets, redundancy strategy, log retention, environmental limits and preferred MCU or FPGA ecosystems. With these inputs, vendors can propose coherent auxiliary control solutions instead of generic catalogue suggestions.