SmpSynch, holdover and the fate of complex protections at a digital substation

What IEC 61869-9 actually requires, and where the boundary lies between "still synchronized" and "no longer synchronized"

This article uses the IEC terminology for SV stream sources:

• SAMU — Stand-Alone Merging Unit (a separate device that produces an SV stream from conventional analog inputs);
• NCIT — Non-Conventional Instrument Transformer (a current or voltage transformer with its own digital output per IEC 61869-9).

For brevity, we write SAMU/NCIT to mean the generalized SV stream source.

By complex protection function we mean a function meeting both of the following conditions:

1. the protection IED receives several independent SV streams from different SAMUs/NCITs (e.g., a separate SAMU for currents and a separate NCIT for voltages; or branch currents from different SAMUs);
2. the protection algorithm vector-compares signals across these streams — i.e., the result depends on their mutual time and angular alignment.

Examples include distance, differential, directional protections, etc. If, on the other hand, all the required signals (both currents and voltages) come from the same SAMU/NCIT, the status of its external time synchronization does not affect the operation of the protection — Section 6.904.6 of IEC 61869-9 states this directly:

Regardless of whether the merging unit is synchronized to an external time source or not, all sampled values from the same merging unit shall be synchronized to each other. (IEC 61869-9, §6.904.6)

In other words, the issue addressed in this article applies specifically to the multi-stream architecture — where the protection assembles its picture from samples produced by different physical SAMU/NCIT devices.

Statement of the problem

Two related questions are commonly raised by substation designers and protection commissioning engineers. We summarize them here:

• Scenario 1. All SV streams initially carried the global synchronization marker (SmpSynch=2). At some moment one SAMU/NCIT continues publishing SmpSynch=2, while another switches to SmpSynch=1. May these SVs be considered mutually synchronized for some period of time?
• Scenario 2. A protection IED running a complex protection receives two SV streams: currents — with SmpSynch=2 (global), voltages — with SmpSynch=1 (local). Should the corresponding protection function be blocked, or do the measurements still combine correctly for some period?

The answer to both questions follows directly from Section 6.904 "Synchronization" of IEC 61869-9. We work through its provisions below and contrast them with the misconceptions that frequently come up in discussions.

How the standard describes SmpSynch

The SmpSynch attribute is present in every ASDU of an SV message and tells the subscriber which clock source the samples are tied to. IEC 61869-9 §6.904.4 defines four classes of values:

The key prescriptions of §6.904.4 quoted verbatim:

While sampled values are synchronized to a global area clock to the degree required to meet the measuring accuracy class phase displacement limit, the value of the "SmpSynch" attribute in the SV messages shall be 2. (IEC 61869-9, §6.904.4)

All sampled values synchronized to any global area clock are synchronized to each other. (IEC 61869-9, §6.904.4)

While sampled values are synchronized to a local area clock to the degree required to meet the measuring accuracy class phase displacement limit, the value of the "SmpSynch" attribute in the SV messages shall be the unique identifier of the specific local area clock if known, or 1 if the identifier is not known. (IEC 61869-9, §6.904.4)

All sampled values synchronized to the same local area clock are synchronized to each other, but may not be synchronized to sampled values synchronized to some other clock. (IEC 61869-9, §6.904.4)

While sampled values are not synchronized to a global or local area clock to the degree required to meet the measuring accuracy class phase displacement limit, the value of the "SmpSynch" attribute in the SV messages shall be 0. (IEC 61869-9, §6.904.4)

The main takeaway from these statements is this: the SmpSynch value of an individual stream alone does not allow you to assert whether that stream is synchronized with any other stream. A subscribing complex protection function must compare the values pairwise across all streams supplied to its algorithm (in particular, the clock IDs in the case of local synchronization).

Holdover and the popular misconception

A commonly heard interpretation goes: "after the loss of global synchronization, flag 2 stays for some time and then transitions to 1." This is incorrect. The standard describes a different behavior. We quote §6.904.5 verbatim:

When the external synchronization signal is lost, the merging unit shall go into a holdover mode. For the duration of the holdover mode the merging unit shall continue to send samples maintaining the sample timing required for the measuring accuracy class. During holdover, the "SmpSynch" attribute in the SV messages shall remain unchanged, and the "SmpCnt" attribute in the SV messages shall increment and wrap as if a synchronization signal were present. (IEC 61869-9, §6.904.5)

The minimum holdover duration shall be 5 seconds under stable temperature conditions. (IEC 61869-9, §6.904.5)

That is, during holdover the SmpSynch value remains equal to 2. Once holdover expires, the SAMU/NCIT moves to free-running mode (§6.904.6) and publishes SmpSynch=0, not 1. The standard explicitly enumerates the causes of SmpSynch=0:

• the synchronization signal was never received;
• the synchronization signal was interrupted and the SAMU/NCIT has been operating longer than its declared holdover;
• the synchronization signal has not been acquired;
• the sampling timing accuracy does not meet the requirements of the accuracy class.

In practice, manufacturers declare holdover times ranging from tens of seconds to hours — depending on the class of the internal oscillator (TCXO, OCXO, rubidium). 5 seconds is the lower normative limit.

Symmetry of the holdover rule

The phrase "SmpSynch shall remain unchanged" is deliberately worded in general terms and is not tied to the value 2. The rule is therefore symmetric for any starting value:

• value 2 (Global) → signal lost → holdover with SmpSynch=2 → holdover expires → SmpSynch=0;
• value 1 (Local without ID) → signal lost → holdover with SmpSynch=1 → holdover expires → SmpSynch=0;
• value 5–254 (Local with ID) → signal lost → holdover with the same ID → holdover expires → SmpSynch=0.

The underlying logic: SmpSynch reflects what class of source the SAMU/NCIT was tied to and continues to maintain the accuracy of the measurement class through its own internal oscillator. During holdover the internal oscillator "remembers" the previous reference and holds it for as long as its stability allows.

The full map of SmpSynch transitions for a single SAMU/NCIT:

stateDiagram-v2
    direction LR
    [*] --> S0: startup without signal<br/>SmpSynch=0
    S0: SmpSynch = 0<br/>(not synchronized)
    S2: SmpSynch = 2<br/>(Global / traceable)
    S1: SmpSynch = 1 / 5–254<br/>(Local)
    HOLD2: holdover (value 2 unchanged)<br/>lasts T_h ≥ 5 s
    HOLD1: holdover (value 1 unchanged)<br/>lasts T_h ≥ 5 s

    S0 --> S2: traceable GM appeared<br/>(timeTraceable=TRUE)
    S0 --> S1: non-traceable GM appeared<br/>(timeTraceable=FALSE)

    S2 --> HOLD2: PTP signal lost
    HOLD2 --> S2: PTP restored before T_h
    HOLD2 --> S0: T_h expired

    S1 --> HOLD1: PTP signal lost
    HOLD1 --> S1: PTP restored before T_h
    HOLD1 --> S0: T_h expired

    S2 --> S1: GM moved to clockClass 52<br/>(timeTraceable: TRUE→FALSE)
    S1 --> S2: GM returned to clockClass 6/7<br/>(timeTraceable: FALSE→TRUE)

Fig. 1. States and transitions of the SmpSynch attribute for a single SAMU/NCIT. Key observation: the 2 → 1 transition is not possible "internally" during holdover — it only arises from a change in the grandmaster status.

So when does SmpSynch=1 actually appear?

The 2 → 1 transition is indeed possible, but it is not a consequence of the SAMU/NCIT itself losing GPS — it follows from a change in the status of the PTP-domain grandmaster (time server) the SAMU/NCIT is connected to.

§6.904.2 of IEC 61869-9 prescribes interpreting the synchronization signal based on the Power Profile timeTraceable flag:

A synchronizing signal received with the Power Profile timeTraceable flag TRUE shall be deemed to be sourced by a global area clock. A synchronizing signal received with the Power Profile timeTraceable flag FALSE shall be deemed to be sourced by a local area clock. (IEC 61869-9, §6.904.2)

The mapping to the SmpSynch value works as follows:

• a signal with timeTraceable=TRUE → the SAMU/NCIT publishes SmpSynch=2;
• a signal with timeTraceable=FALSE → the SAMU/NCIT publishes SmpSynch=1 (or 5–254 if a byte-sized source identifier is conveyed in the GRANDMASTER_ID TLV).

When the grandmaster loses GPS/GLONASS and itself enters holdover, then according to Power Profile rules it will after a certain time set timeTraceable=FALSE. From that point onwards the SAMUs/NCITs connected to it will switch to SmpSynch=1 — while still being physically synchronized between themselves, since they are taking time from the same source.

When a redundant grandmaster is available, some SAMUs/NCITs may stay on the "traceable" grandmaster (SmpSynch=2), while others may switch to a "non-traceable" one (SmpSynch=1). Synchronization between these two groups is no longer guaranteed.

Where timeTraceable and clockClass are conveyed

Both values — timeTraceable and clockClass — reach the subscriber inside the same PTP Announce message. This message is sent by every grandmaster (Ordinary Clock) and every Boundary Clock; under Power Profile it is repeated at 1 Hz. In addition to the time stamp itself, Announce carries information about the source quality, which the BMCA (Best Master Clock Algorithm) uses to select the best grandmaster in the domain, and which the SAMU/NCIT uses to derive SmpSynch.

timeTraceable: a bit in flagField

The timeTraceable flag is not a separate message — it is one of the bits of the flagField in the header of the Announce message. Specifically, it is the lower byte of flagField, bit 4 (denoted PTP_TIMETRACEABLE per IEEE 1588-2008/2019, mask 0x10). Adjacent in the same flagField is the frequencyTraceable flag (mask 0x20), which indicates whether the frequency reference is traceable; under Power Profile its value typically matches that of timeTraceable.

The timeTraceable value is set by the grandmaster according to its internal state:

• it is locked to an external reference (e.g., GNSS) with the accuracy required by Power Profile → timeTraceable=TRUE;
• it is in its own holdover, and the accuracy is still within limits → timeTraceable normally remains TRUE;
• the accuracy has gone beyond the normative Power Profile limits → timeTraceable=FALSE.

clockClass: a byte in grandmasterClockQuality

The clockClass attribute is conveyed in the body of the Announce message, as part of the grandmasterClockQuality structure (per IEEE 1588-2008/2019, §13.5). This structure occupies 4 bytes and contains three fields:

• clockClass — 1 byte (UInteger8); the actual "quality class" of the grandmaster — this is the one of interest to us;
• clockAccuracy — 1 byte (Enumeration8); a coarse estimate of the actual accuracy (values such as "better than 100 ns", "better than 1 µs", etc.);
• offsetScaledLogVariance — 2 bytes (UInteger16); a characteristic of the oscillator's stability.

Power Profile (IEC/IEEE 61850-9-3 and IEEE C37.238) uses only four normative clockClass values:

• 6 — locked to a PRC (Primary Reference Clock; typically GNSS), actual accuracy ≤ 250 ns;
• 7 — in holdover after previously locked to a PRC, accuracy still within profile (≤ 250 ns relative to the last lock);
• 52 — in holdover, accuracy has drifted into the 250 ns – 1 µs range;
• 187 — in holdover, accuracy worse than 1 µs.

A smaller clockClass value corresponds to a higher-quality source, and BMCA, all else being equal, picks the grandmaster with the smallest clockClass.

Relationship between clockClass and timeTraceable

clockClass and timeTraceable are two independent fields of the same Announce message, so theoretically a grandmaster may set them in any combination. However, Power Profile normatively links them: timeTraceable=TRUE may be set only when the actual time accuracy meets the profile's traceability requirements. Hence the standard correspondence followed by both the grandmasters and the subscribers:

Table 1. Correspondence between the grandmaster's clockClass, the timeTraceable flag in Announce and the SmpSynch value at the SAMU/NCIT subscriber, per Power Profile (IEC/IEEE 61850-9-3 and IEEE C37.238).

This is exactly why a stream's SmpSynch transition from 2 to 1 is, in effect, an indicator that the grandmaster has moved from clockClass 6/7 to clockClass 52: timeTraceable drops to FALSE, and the SAMU/NCIT must change SmpSynch accordingly.

What else is conveyed in Announce, and where it is visible

In addition to timeTraceable and clockClass, the subscriber receives one more important field via Announce:

• GMID (Grandmaster ID) — conveyed as a Power Profile TLV in the Announce message. Its lower byte, per §6.904.2 of IEC 61869-9, is copied into SmpSynch for values 5–254 — i.e., the local clock ID seen by the complex protection physically comes from this TLV.

A subscribing SAMU/NCIT (and any protection IED having its own PTP stack) does not pass these fields outward — it uses them internally to derive SmpSynch. Therefore, during digital substation commissioning the "Announce → SmpSynch" chain is conveniently checked with standard PTP analyzers capable of parsing Announce messages byte-by-byte (Wireshark with the PTPv2 dissector, dedicated IEEE 1588 Time Test Set instruments, professional PTP/SV test software, etc.).

The resulting causal chain is therefore: "grandmaster state → its clockClass and timeTraceable in Announce → their interpretation in the SAMU/NCIT PTP stack → SmpSynch in the SV message → the complex protection's decision."

flowchart TB
    GM["Grandmaster<br/><i>internal oscillator state</i>"]
    ANN["PTP Announce message<br/>(1 Hz per Power Profile)"]
    FF["flagField · timeTraceable bit<br/>TRUE / FALSE"]
    CC["grandmasterClockQuality.clockClass<br/>6 · 7 · 52 · 187"]
    GMID["GRANDMASTER_ID TLV<br/>(IEEE C37.238)"]
    PTP["SAMU/NCIT PTP stack<br/>Announce interpretation"]
    SV["SV message<br/>SmpSynch attribute"]
    DEF["Complex protection<br/>SmpSynch pair comparison<br/>across all streams"]
    DEC{"All streams<br/>mutually synchronized?"}
    OK["Full accuracy<br/>function operates"]
    BLK["Blocking / fallback<br/>to backup algorithm"]

    GM --> ANN
    ANN --> FF
    ANN --> CC
    ANN --> GMID
    FF --> PTP
    CC --> PTP
    GMID --> PTP
    PTP --> SV
    SV --> DEF
    DEF --> DEC
    DEC -->|yes| OK
    DEC -->|no| BLK

    style GM fill:#e8f4fd,stroke:#4a90d9
    style ANN fill:#fff8e1,stroke:#e6a23c
    style PTP fill:#f3e5f5,stroke:#9c27b0
    style SV fill:#e8f5e9,stroke:#67c23a
    style DEF fill:#fde8e8,stroke:#f56c6c
    style OK fill:#e8f5e9,stroke:#67c23a
    style BLK fill:#fde8e8,stroke:#f56c6c

Fig. 2. Causal chain from grandmaster state to the complex protection's decision. Every link is a separate failure point and a separate test object.

Back to the scenarios from the discussion

Scenario 1: one SAMU/NCIT remains at 2, another switches to 1

The formal answer of the standard: such streams cannot be considered mutually synchronized. The subscriber has no means of knowing whether the local source of the second SAMU/NCIT actually coincides physically with the global source of the first.

Physically, this situation usually means one of two things:

• Both SAMUs/NCITs are connected to the same grandmaster, which has lost GPS and now sets timeTraceable=FALSE. In that case the two streams are in fact still synchronized (common source), but the second SAMU/NCIT should also have switched to SmpSynch=1 — if it has not, one of the devices is malfunctioning.
• The SAMUs/NCITs are connected to different grandmasters, one of which still has GPS and the other no longer does. In that case a phase drift between the streams emerges due to the local oscillators, and the accuracy of their alignment degrades.

Since the subscriber cannot distinguish between these two cases from the SV content, it is safer to treat the "2 + 1" pair as out of sync and block the complex protection.

Scenario 2: currents SmpSynch=2, voltages SmpSynch=1

This is a typical situation where currents and voltages are produced by different SAMUs/NCITs — i.e., precisely the multi-stream architecture for which the synchronization question is meaningful. A complex protection (e.g., distance) computes its quantities by vector-comparing current and voltage, and any phase error between them propagates directly into the result.

IEC 61869-9 does not describe protection IED behavior — it only provides the subscriber with a means (the SmpSynch attribute) for making a decision. The decision itself is governed by the requirements of the protection function and the logic of the protection IED. The common practice is:

• if both streams have SmpSynch=2 — the function operates;
• if both streams have SmpSynch=N (the same local ID 5–254) — the function operates;
• if one stream is =2 and the other =1, or the local clock IDs differ, or at least one is =0 — complex protection functions are blocked.

When the question "to combine or not to combine" does not arise at all

If the complex protection works with a stream from a single SAMU/NCIT (i.e., both currents and voltages are produced by the same device), the question of external synchronization does not arise — per §6.904.6 already quoted above, samples from the same device are always mutually synchronized regardless of the state of its external synchronization. External synchronization in this case is needed only for "global" alignment with other subsystems (e.g., synchrophasors), but does not affect the operation of the protection function itself.

What a SAMU/NCIT must do on loss of source

A summary of the requirements of §6.904.5–6.904.6 and the test of §7.2.902 of IEC 61869-9:

• on loss of external synchronization, the SAMU/NCIT must enter holdover and continue to emit SVs with the previous SmpSynch and an incrementing SmpCnt as if no signal had been lost;
• the holdover duration is declared in the device data sheet (the hold attribute in PhyNam.d, see §6.903.5); the minimum is 5 s;
• once holdover expires, the SAMU/NCIT moves to free-running, sets SmpSynch=0, and maintains the sampling rate within ±100 ppm of the nominal value;
• when the signal is restored before holdover expires, the stream continues seamlessly; when restored after — the standard allows a step in SmpCnt and/or a change in SmpSynch in adjacent ASDUs, and the subscriber must detect this (NOTE 912 in §6.904.7).

Graphically:

{
  "title": {
    "text": "SAMU/NCIT behavior on PTP signal loss",
    "subtext": "SmpSynch and accumulated |Δt| · IEC 61869-9 §6.904.5 / 7.2.902",
    "left": "center", "top": 8,
    "textStyle": { "fontSize": 14, "fontWeight": "bold" },
    "subtextStyle": { "fontSize": 11, "color": "#888" }
  },
  "tooltip": { "trigger": "axis" },
  "legend": { "bottom": 8, "itemGap": 24, "data": ["SmpSynch", "|Δt| / class limit"] },
  "grid": { "left": 70, "right": 70, "top": 75, "bottom": 70 },
  "xAxis": {
    "type": "value",
    "name": "Time (in fractions of nominal T_h)",
    "nameLocation": "middle", "nameGap": 32,
    "min": -0.4, "max": 1.6,
    "axisLabel": { "formatter": "{value}·T_h" },
    "splitLine": { "show": false }
  },
  "yAxis": [
    {
      "type": "value", "name": "SmpSynch",
      "nameLocation": "middle", "nameGap": 38, "nameRotate": 90,
      "nameTextStyle": { "color": "#409EFF", "fontWeight": "bold" },
      "min": -0.3, "max": 2.6, "interval": 1,
      "position": "left",
      "axisLabel": { "color": "#409EFF" },
      "splitLine": { "show": false }
    },
    {
      "type": "value", "name": "|Δt| / class limit",
      "nameLocation": "middle", "nameGap": 40, "nameRotate": -90,
      "nameTextStyle": { "color": "#E6A23C", "fontWeight": "bold" },
      "min": 0, "max": 1.6,
      "position": "right",
      "axisLabel": { "color": "#E6A23C" },
      "splitLine": { "show": false }
    }
  ],
  "series": [
    {
      "name": "SmpSynch",
      "type": "line", "step": "end", "yAxisIndex": 0,
      "data": [[-0.4, 2], [0, 2], [0.95, 2], [0.95, 0], [1.6, 0]],
      "lineStyle": { "width": 4, "color": "#409EFF" },
      "symbol": "circle", "symbolSize": 8, "z": 10,
      "markLine": {
        "silent": true, "symbol": ["none", "none"],
        "label": { "show": false },
        "data": [
          { "xAxis": 0, "lineStyle": { "color": "#F56C6C", "type": "dashed", "width": 2 } },
          { "xAxis": 0.95, "lineStyle": { "color": "#F56C6C", "type": "dashed", "width": 2 } }
        ]
      },
      "markArea": {
        "silent": true,
        "label": { "fontSize": 12, "fontWeight": "bold", "color": "#555", "position": "insideTop", "distance": 6 },
        "data": [
          [{ "name": "Normal", "xAxis": -0.4, "itemStyle": { "color": "rgba(103,194,58,0.12)" } }, { "xAxis": 0 }],
          [{ "name": "Holdover", "xAxis": 0, "itemStyle": { "color": "rgba(230,162,60,0.18)" } }, { "xAxis": 0.95 }],
          [{ "name": "Free-running", "xAxis": 0.95, "itemStyle": { "color": "rgba(245,108,108,0.18)" } }, { "xAxis": 1.6 }]
        ]
      }
    },
    {
      "name": "|Δt| / class limit",
      "type": "line", "smooth": true, "yAxisIndex": 1,
      "data": [[-0.4, 0.04], [0, 0.04], [0.15, 0.10], [0.30, 0.22],
               [0.50, 0.40], [0.70, 0.62], [0.85, 0.85], [0.95, 0.98],
               [1.10, 1.18], [1.30, 1.32], [1.6, 1.45]],
      "lineStyle": { "width": 2, "color": "#E6A23C" },
      "areaStyle": { "color": "rgba(230,162,60,0.18)" },
      "showSymbol": false,
      "markLine": {
        "silent": true, "symbol": ["none", "none"],
        "data": [{
          "yAxis": 1,
          "lineStyle": { "color": "#909399", "type": "dotted", "width": 1.5 },
          "label": {
            "formatter": "class accuracy limit", "position": "middle",
            "fontSize": 11, "fontWeight": "bold", "color": "#555",
            "backgroundColor": "rgba(255,255,255,0.9)",
            "borderColor": "#909399", "borderWidth": 1, "borderRadius": 3,
            "padding": [3, 8]
          }
        }]
      }
    }
  ]
}

Fig. 3. SmpSynch and the accumulated timestamp error |Δt| over time after a PTP signal loss. Green zone — normal operation, orange — holdover (SmpSynch=2 unchanged, accuracy still within class), red — free-running (SmpSynch=0). Key point: SmpSynch flips to 0 before |Δt| actually exceeds the class accuracy limit (per §7.2.902).

How the declared holdover value is verified

The procedure for confirming the declared holdover duration of a SAMU/NCIT is described in §7.2.902 "Loss of synchronization tests" of IEC 61869-9 — one of the mandatory type tests. The standard formulates it very concisely, so it is worth quoting verbatim:

Verify under worst-case conditions that on loss of synchronizing signal, the merging unit continues to send samples maintaining the sample timing required for the measuring accuracy class for the published duration of the holdover period. Verify that over this period, the SmpSynch attribute in the SV messages remains unchanged, and the SmpCnt attribute in the SV messages increments and wraps as if synchronization signal were present. Verify that before the sample timing fails to meet that required for the measuring accuracy class, the SmpSynch attribute changes to zero. (IEC 61869-9, §7.2.902)

This wording unfolds into four statements that the verification must confirm quantitatively: (1) the timestamp accuracy of the samples remains within the class throughout the entire declared holdover T_h; (2) over this interval SmpSynch does not change; (3) SmpCnt increments without steps or gaps; (4) when the time error approaches the class limit, SmpSynch flips to 0 — earlier than the accuracy actually leaves the limit.

Test bench

The test bench concept is to feed the device under test simultaneously with a stable analog signal and a controlled PTP, to break PTP at t = 0, and to record the SV stream output with a reference time pegged to an external clock. Then, in post-processing, the timestamp error is computed for each ASDU, compared against the class limit, and the values of SmpSynch and SmpCnt are checked.

flowchart LR
    REF["Time reference<br/>Cs/Rb or<br/>GNSS-disciplined oscillator"]
    GM["PTP grandmaster<br/>Power Profile<br/>(IEC/IEEE 61850-9-3)"]
    CUT["PTP cut-off point<br/>(switch ACL or<br/>physical break)"]
    SW["PTP-aware<br/>network switch"]
    AN["Analog source<br/>(calibrated I/U)"]
    DUT["DUT — SAMU/NCIT<br/>declared holdover T_h"]
    SVA["SV analyzer<br/>(hardware timestamping)"]
    PP["Post-processing<br/>per §7.2.902 criteria"]

    REF -- "1 PPS / 10 MHz" --> GM
    REF -- "1 PPS / 10 MHz" --> SVA
    GM -- PTP --> CUT
    CUT -- PTP --> SW
    SW -- PTP --> DUT
    AN -- "I, U" --> DUT
    DUT -- "SV stream" --> SVA
    SVA --> PP

    style REF fill:#e8f4fd,stroke:#4a90d9
    style GM fill:#fff8e1,stroke:#e6a23c
    style CUT fill:#fde8e8,stroke:#f56c6c
    style DUT fill:#f3e5f5,stroke:#9c27b0
    style SVA fill:#e8f5e9,stroke:#67c23a
    style PP fill:#e8f5e9,stroke:#67c23a

Fig. 4. Test bench structure for the holdover type test (IEC 61869-9, §7.2.902).

The key elements:

• Time reference — a Cs/Rb source or GNSS-disciplined oscillator with stability 1–2 orders of magnitude better than that of the SAMU/NCIT under test. It remains the ground truth even when synchronization is taken away from the DUT.
• Controlled PTP grandmaster, synchronized from the same reference. It feeds PTP Power Profile (IEC/IEEE 61850-9-3) to the device under test.
• PTP cut-off point — a switch with an ACL, a programmable filter, or a physical break of the PTP line. Important: the cut must affect only PTP, not the SV channel of the DUT itself (otherwise SV reception will also be interrupted).
• Analog source — a calibrated current/voltage source with a known phase. Phase stability must be better than the accuracy class of the channel under test.
• DUT — the SAMU/NCIT itself with the declared holdover T_h.
• SV analyzer with hardware timestamping, pegged to the reference via PPS/10 MHz. Records every ASDU with reception time stamps. In practice, this can be done with a dedicated PTP/SV test instrument or with a NIC supporting PHC + Wireshark with the PTPv2/SV dissector (the latter typically achieves ~50–100 ns).
• Post-processing — computes the time error Δt = t_capture − (t_SmpCnt + t_d) for each ASDU and compares it with the class limit. Here t_d is the SAMU/NCIT's specified delay (the "delay" attribute in PhyNam.d, see §6.903.5).

Test scenario

The basic §7.2.902 scenario consists of four steps:

• Step 1. Stabilization. Synchronization and the analog signal are fed to the DUT. Wait for Lock, confirm that the SV stream has the correct SmpSynch (typically 2 for the "Global" case) and that Δt is within the class limit.
• Step 2. PTP break. At t = 0, the PTP is broken at the cut-off point. The analog signal and the SV channel itself are not touched. The exact break time is recorded against the reference.
• Step 3. Capture. The SV stream is captured for a duration ≥ T_h plus margin (typically T_h × 1.5). In parallel, the reference log saves PPS marks so that absolute reception times can be assigned to every record.
• Step 4. Analysis. From the recording, the four §7.2.902 criteria are verified: |Δt(t)| ≤ class limit for all t ≤ T_h; SmpSynch unchanged on [0, T_h]; SmpCnt without steps; SmpSynch flips to 0 before |Δt| exceeds the class limit.

It is also useful to check how the device behaves on signal restoration: if restored before holdover expires, the stream must continue seamlessly; if after — a step in SmpCnt and/or a change in SmpSynch in adjacent ASDUs is allowed (NOTE 912, §6.904.7), and the subscriber must detect this.

What counts as "worst-case conditions"

§7.2.902 mandates testing under worst-case conditions. In practice this means a combination of factors that accelerate drift of the internal oscillator:

• operating at the boundaries of the DUT's specified temperature range (typically tested in a thermal chamber at the lower and upper limits);
• pre-conditioning at the boundary temperature to exclude the initial self-heating phase;
• if applicable — testing under EMC stress (see the relevant EMC sections of IEC 61869-9).

If the declared T_h is given only for "stable temperature" (a wording explicitly permitted by §6.904.5), a thermal chamber is not required, but the absence of those conditions must be recorded in the test report.

What usually happens in practice

A full holdover test cycle is a long-duration test (for T_h of tens of minutes or hours, the actual test time is comparable), and is performed in full only by accredited laboratories (KEMA/DNV, VDE, KERI, etc.) during type-approval — the result is recorded in the type-test certificate. During factory acceptance and substation commissioning, a "short" version is usually used: PTP is removed for 5–10 seconds and one confirms that during this time the SV stream continues, SmpSynch does not change, and SmpCnt runs without steps. This confirms the holdover mechanism is functional, but not its declared duration.

A long test (for the full T_h) is worth including in the technical specification for prototype devices, when releasing a new generation, and in expert investigations after incidents where the actual holdover behavior is in doubt. Note that the PTP grandmaster itself has its own holdover, verified by a similar method described in IEC/IEEE 61850-9-3.

What IEC 61850-9-3 and the PTP Power Profile state

IEC 61869-9 describes the SAMU/NCIT behavior and the SmpSynch values, but the quality of the synchronization network itself is governed by another pair of standards: IEC/IEEE 61850-9-3 (Power Profile for PTP) and IEEE C37.238. It is important to keep this link in mind, otherwise the SmpSynch attribute is perceived as a "thing in itself".

The Power Profile defines the clockClass attribute at the grandmaster (conveyed in Announce, see the previous section) and its typical values for power systems:

• clockClass = 6 — locked to an external reference (typically GNSS), accuracy ≤ 250 ns. Subscribers receive a signal with timeTraceable=TRUE → the SAMU/NCIT publishes SmpSynch=2.
• clockClass = 7 — in holdover after previously locking to a reference, accuracy still ≤ 250 ns. timeTraceable normally remains TRUE; SmpSynch at the SAMU/NCIT remains 2.
• clockClass = 52 — holdover, accuracy drifted to the 250 ns – 1 µs range. timeTraceable=FALSE; the SAMU/NCIT moves to SmpSynch=1 (or 5–254 if a GRANDMASTER_ID is conveyed in the TLV).
• clockClass = 187 — holdover, accuracy worse than 1 µs. The SV stream with such synchronization no longer meets the measuring channel class and must be published with SmpSynch=0.

In other words, an SmpSynch transition 2 → 1 (rather than 2 → 0) on a stream is not "the SAMU/NCIT lost its signal", but "the grandmaster moved from clockClass 7 to clockClass 52". If the grandmaster degrades to the point of clockClass 187, the SAMU/NCIT's own holdover kicks in, and SmpSynch=0 appears via the logic described in the section on SAMU/NCIT obligations.

Hence the typical recommendations:

• Redundant grandmasters, each with its own GNSS receiver, with coordinated BMCA. The failure of a single receiver or a single device must not move the domain to clockClass 52.
• Boundary clocks in every control building / GIS room. When the link between buildings fails, the local time reference is preserved, and the SAMU/NCIT does not need to switch SmpSynch.
• Uniform PTP profile configuration: domain numbers, delay mechanism (E2E/P2P), Sync/Announce rates, BMCA priorities, and holdover behavior must be coordinated across grandmasters, PTP-aware switches, SAMUs/NCITs and protection IEDs.
• Holdover headroom on the network: devices with oven-controlled OCXO hold clockClass 7 for tens of minutes; devices with Rb hold it for hours. This is critical for facilities subject to a complete loss of GNSS on the substation side.
• Test transitions — not only loss of signal at the SAMU/NCIT (the §7.2.902 test of IEC 61869-9), but also grandmaster transitions 6 → 7 → 52 → 187 — on the subscriber side, test the logic of reaction to 2 → 1 → 0 and to SmpCnt steps.

Practical recommendations for design and commissioning

• Compare pairs of SmpSynch, not individual values. A subscribing complex protection function must check whether the sources of all streams used by its algorithm match.
• Allow for holdover headroom. The 5-second minimum in the standard is the lower spec limit. To keep protections robust against transient PTP/1PPS dropouts, choose SAMUs/NCITs and grandmasters with holdover of tens of minutes.
• Make the time source redundant. Duplicate the grandmaster, each with its own GPS/GLONASS receiver.
• Aim for a single source per protection. Where topology permits, take currents and voltages used by a complex protection from the same SAMU/NCIT — then the SmpSynch alignment question does not arise at all.
• Uniform PTP profile configuration: domain numbers, delay mechanism (E2E/P2P), Sync/Announce rates, BMCA priorities, holdover behavior — coordinated across grandmasters, PTP-aware switches, SAMUs/NCITs and protection IEDs.
• Boundary clocks in every control building / GIS room. When the link between buildings fails, local time reference is preserved and the SAMU/NCIT does not need to switch SmpSynch.
• Test transitions. The §7.2.902 IEC 61869-9 test is a requirement on the SAMU/NCIT; on the subscriber side, test your own logic for reactions to 2→0, 2→1, SmpCnt steps; on the network — grandmaster transitions 6 → 7 → 52 → 187.

Conclusion

The "2 → 1 → 0" picture sometimes used in discussions oversimplifies the actual behavior of the SAMU/NCIT and leads to incorrect conclusions. IEC 61869-9 describes a different transition: "2 → (holdover, SmpSynch stays 2) → 0", and the value 1 appears in a different scenario — when the status of the grandmaster itself changes, which is physically conveyed via the timeTraceable flag in the PTP-domain Announce messages.

For a subscribing complex protection, this gives a simple rule: the pair "SmpSynch=2 and SmpSynch=1" is not, in general, considered synchronized, and under such a combination the protection functions that rely on cross-stream comparison must be blocked.

And a final architectural point: the question "is it still synchronized" does not arise at all where the complex protection receives signals from a single SAMU/NCIT. So when designing a digital substation, look not only at the synchronization system itself, but also at the distribution of functions across SAMUs/NCITs — the fewer cross-device dependencies a protection has, the fewer SmpSynch-related failure points it carries.