Before you write any straton logic, find out whether your zenon installation includes a native IEEE C37.118 driver. If it does not, do not build Phasor Data Concentrator (PDC) behaviour in a soft-PLC. A PDC collects synchrophasor streams from several Phasor Measurement Units (PMUs) and lines them up by source timestamp. A SCADA polling cycle or a PLC scan cannot do that reliably. The layout that works puts a dedicated PDC in front of zenon. zenon then handles visualisation, alarming, and logic on data that is already aligned.
Check the zenon driver list before designing anything
Everything else depends on this answer, so check it first.
- Open the zenon Editor and create a new driver in the project.
- Look through the driver list for an entry that names IEEE C37.118 or synchrophasor data.
- Read the driver documentation for your installed zenon version. Note whether the driver acts as a client (receives PMU streams) or as a server (sends a concentrated stream). A client driver reads PMUs. PDC behaviour also needs time alignment across several PMUs.
- Do the same check in the straton runtime's list of supported protocols.
Check: Write down one of two results: "native C37.118 client available" or "not available". If no driver is listed, stop looking for a workaround inside zenon and go to the external-PDC layout below. If you cannot tell from the documentation, ask COPA-DATA support. Give them your exact version and ask whether a C37.118 driver exists and whether it time-aligns multiple PMUs.
Skip the quick fixes that fail on PMU streams
Three shortcuts come up again and again. All three produce data that looks plausible but is wrong.
| Quick fix | Why it fails |
|---|---|
| Parse C37.118 frames with a raw TCP/UDP socket in straton logic | You have to handle configuration frames, command frames to start and stop transmission, per-PMU channel scaling, and data-valid and time-quality flags. You also need a reorder buffer. Scan jitter and buffer limits drop or misorder frames at continuous reporting rates. |
| Poll each PMU through a generic or Modbus driver | Polling returns the latest value at poll time. It does not return the measurement tied to a specific timestamp. Values from two PMUs read in the same poll can come from different instants, so angle comparisons are meaningless. |
| Use the zenon receive timestamp as the measurement time | A synchrophasor is only useful with its GPS-derived source timestamp. Receive time includes network and processing delay, and that delay differs per PMU. Phase angles compared on receive time are shifted by that delay. |
A PDC does more than collect data. It sorts incoming frames into buckets by source timestamp. It waits a set window for late frames, flags PMUs whose data is missing or whose clock has lost synchronisation, and then sends one combined frame per timestamp. That buffering and waiting is exactly what a cyclic PLC task and a SCADA poll cycle are not designed to do.
Check: Before moving on, confirm that nobody on the project is counting on phase angles compared across PMUs that were read by polling.
Restore visibility now, then install a dedicated PDC
Temporary restore:If operators need to see magnitudes and frequency right away, read those values with the matching zenon driver. Label the screens as non-synchronised. Do not calculate angle differences between devices from this data.
Permanent repair: Put a hardware or software PDC between the PMUs and zenon.
- Set the PMU IDs, IP addresses, and ports in the PDC exactly as they appear in each PMU's own configuration. Read the values from the PMU. Do not assume defaults.
- Set the PDC reporting rate to match or evenly divide the PMU reporting rates, following the PDC manual.
- Set the PDC wait window to cover the worst-case network delay you have measured from the farthest PMU.
Check: The PDC diagnostic page shows every PMU as connected, with a valid configuration received, time quality locked, and a data-valid flag set. If any PMU reports unlocked time, fix the GPS antenna or clock source at that PMU before continuing.
Map the concentrated output into zenon with source timestamps
- Create the zenon driver that matches the PDC output protocol.
- Create variables for each phasor magnitude, angle, frequency, and rate of change of frequency that the PDC publishes.
- In the driver or variable settings, set the value timestamp to come from the telegram or source, not from the local receive time. Read the exact option name in the driver documentation for your version.
- Map the PDC's per-PMU quality or data-valid bits to zenon status. Invalid samples then show as invalid instead of as the last good value.
Check: Open the variable diagnosis in zenon Runtime. Compare the timestamp of one angle value against the PDC's own display for the same instant. They must match to the frame. If the zenon timestamp lags by a steady offset, it is still using receive time.
Run straton logic on aligned values only
Use straton for decisions based on concentrated data: angle-difference alarms, frequency deviation thresholds, and interlocks. Do not use it for alignment. Angle difference must handle wrap-around at plus or minus 180 degrees. The Structured Text below uses placeholder names; replace them with your own variables.
Compare timestamps before acting. After a communication hiccup, the two variables can briefly come from different PDC frames.
Check: Force one PMU's data-valid bit false at the PDC, or disconnect that PMU. The alarm logic must stop evaluating. It must not freeze on the last difference.
Verify the chain from PMU to zenon screen
- Compare the angle difference between two PMUs on the same bus. It should be close to zero, apart from the known instrument transformer and phase offsets. A large, steady offset points to a wrong phase or channel mapping.
- Disconnect one PMU's network cable. The PDC flags it missing, zenon shows the related variables as invalid, and the straton logic stops evaluating that pair.
- Reconnect it. The PDC receives the configuration again and data resumes without restarting zenon.
- Take the GPS antenna off one PMU, if the site allows it. Time quality degrades at the PDC, and that status reaches zenon.
- Trend frequency from all PMUs on one zenon trend. The traces should overlay closely during a system disturbance.
FAQ
What happens if I poll PMUs directly from zenon without a PDC?
Each poll returns the latest value from each device at slightly different moments. Magnitudes and frequency are usable for display, but phase-angle comparisons between PMUs are invalid.
What happens if zenon uses receive time instead of the PMU timestamp?
Every value is shifted by its own network and processing delay, so angles from different PMUs no longer refer to the same instant. Set the driver to use the source timestamp and confirm it against the PDC display.
What happens if the PDC wait window is too short?
Frames from distant PMUs arrive after the window closes, so the PDC marks them missing even though the PMU sent them. Measure worst-case delay to the farthest PMU and set the window above it, following the PDC manual.
Can straton logic parse IEEE C37.118 frames itself?
It can be attempted with raw sockets. However, handling configuration frames, command frames, scaling, quality flags, and timestamp reordering inside a cyclic task is fragile at continuous reporting rates. Use a dedicated PDC and give straton the aligned output.
What happens if one PMU loses GPS lock?
Its timestamps drift, and the PDC should flag its time quality as degraded. Pass that status into zenon and block angle-based alarms for that PMU until lock returns.
Stop and contact COPA-DATA support if you cannot confirm from the driver list and documentation whether your zenon version supports IEEE C37.118. Also contact them if the PDC output driver does not carry source timestamps into zenon. Contact the PDC or PMU manufacturer's support if configuration frames are rejected or time quality stays unlocked after the clock source has been checked.