Low-voltage path · Division 18: Industrial fiber and resilient networks · Lesson 349

Document control-network redundancy requirements

Free for apprenticesRead it or play it. No card, no account, nothing to cancel.
Document control-network redundancy requirements

What you should be able to do

Write a testable requirement for a control-network service that states its endpoints, covered failure, performance limit, dependencies and acceptance evidence.

From a label to a requirement

“Provide redundancy” leaves essential questions unanswered. Identify the service that must remain available and the event it must tolerate. Then state the measurable result required by the application owner. Cisco’s CPwE resiliency guidance identifies application considerations including physical distribution, recovery performance, media and tolerance to latency and jitter [1]. Those factors support selecting a suitable architecture. They do not supply a universal interruption limit for every industrial process.

Original requirement record R-01

All identifiers, values and scenarios in this exercise are fictional. Service: exchange the defined application updates between PLC-1 and remote I/O-1. Configuration: the version-controlled topology and device/configuration list in drawing NET-01 revision A. Covered event: loss of any one link in the four-link ring, evaluated one link at a time under the approved test plan. Assumptions: both service endpoints and the surviving network equipment remain powered and functional. Traffic: the application’s defined cyclic traffic plus the background load in test profile TP-01. That profile must be attached before a real test could proceed. Required outcome: the maximum interval between consecutive valid received application updates at the receiving endpoint shall not exceed 100 ms during the defined event. Additional condition: no controller or remote-I/O restart and no application communication-fault indication attributable to the tested event. Evidence: timestamped received-update records, event timestamps, equipment logs and the exact configuration tested. Owner: the designated control-system owner accepts the evidence and records the disposition.

Defining the metric

For this exercise, “update gap” means the interval between consecutive valid application updates recorded at the receiving endpoint. It is not simply the time between a switch detecting a fault and announcing that the ring is healthy. The measurement plan must establish timestamp accuracy, resolution, event correlation and what counts as a valid update. Rejected or stale data must not be counted as a successful current update merely to shorten the reported gap. The poster abbreviates R-01. This companion defines the additional conditions and evidence needed to interpret it.

Original results exercise

One fictional run has consecutive valid received updates at 12:00:00.000 and 12:00:00.124. The interval is 124 ms. It exceeds the 100 ms limit by 24 ms. Another run has an 82 ms maximum gap, no endpoint restart and no communication-fault indication. Those results are favorable for that run’s stated conditions. They do not establish that all four link-failure cases, restoration cases or background-load conditions have been completed. A summary that reports only “ring recovered” cannot demonstrate the application-gap requirement.

Covered and separate failure cases

R-01 covers one ring-link failure at a time while the stated equipment remains powered. A failed endpoint, common power-source loss, two simultaneous cable cuts or a shared enclosure event may produce different outcomes. Record those cases in the requirement register rather than letting them disappear behind the word redundant. The responsible owner must decide which additional cases the project must tolerate and define their acceptance criteria. Excluding a failure from R-01 is a scope statement, not a claim that it is harmless or acceptable for the plant.

Shared-dependency exercise

Two proposed routes use different fibers but enter the same enclosure and depend on one power supply. Write both shared dependencies into the record. A drawing with two lines does not prove independent service. The reviewer must determine whether the specified failure scope includes enclosure damage or supply loss and whether additional design measures are needed. Do not invent a site-approved solution from the drawing alone.

Restoration requirement

Document what happens when a failed link returns. For the classroom packet, create a separate requirement R-02: restoration of each tested link must satisfy the same application-gap and no-restart conditions under TP-01. R-02 requires its own evidence and disposition. A successful failure test does not automatically demonstrate restoration behavior. The actual test sequence, authorization and rollback arrangements must be established before any work on a real system.

Worked through

For each requirement, enter:

  • Unique identifier and revision.
  • Application/service and owner.
  • Endpoints and configuration baseline.
  • Covered fault and explicit assumptions.
  • Operating modes and traffic profile.
  • Measurement metric, threshold and evidence method.
  • Shared dependencies and separately tracked failure cases.
  • Restoration behavior.
  • Test-plan reference, result and approving owner. Mark absent attachments or undefined limits as unresolved. Do not replace them with a guessed number.

Practice questions

  1. What is missing from “install a redundant fiber ring”?
  2. What does R-01’s 100 ms limit measure?
  3. Calculate the failure margin for a 124 ms gap.
  4. Does an 82 ms result prove all failure scenarios are acceptable?
  5. Why record the shared enclosure and supply?
  6. Does a requirement document authorize a live outage test?
  7. Why does restoration need a separate result?

Answers

  1. The service, covered failures, limits, dependencies and acceptance evidence.
  2. The maximum interval between consecutive valid received application updates under the defined test conditions.
  3. It exceeds the limit by 24 ms.
  4. No; it supports only the documented run and conditions.
  5. They may defeat multiple apparent paths through one common event.
  6. No; the site’s approved change and test process remains necessary.
  7. Reintroducing a link can affect forwarding and service separately from the failure event.

Where beginners go wrong

Mistake: Accepting 'ring recovered' as evidence for R-01's valid-update gap. Correction: Require timestamps for consecutive valid application updates at the named receiving endpoint under TP-01.

Mistake: Extending the 82 ms result to every link and operating condition. Correction: Record exactly which failure and traffic condition were tested; keep the other required cases open.

Mistake: Counting restoration as passed because the failure test passed. Correction: Create and retain the separate R-02 evidence for returning the link and checking the same application conditions.

Sources

[1] Cisco, Deploying Parallel Redundancy Protocol within a Converged Plantwide Ethernet Architecture, Overview: https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/CPwE/5-1/PRP/DIG/CPwE-5-1-PRP-DIG/CPwE-5-1-PRP-DIG1.html Primary indexed text inspected 2026-10-01 for application-based resiliency considerations. This lesson does not recommend PRP for the fictional case or import platform-specific performance claims. Requirements, identifiers, timing values, records and exercises are original classroom material.

Also working toward the electrician journeyman licence? Take the free 15-question readiness check

Texas journeyman, 15 questions, scored by topic against the 70% mark. No card, and no account needed to start.

Free study material for low-voltage apprentices. This is a national foundation course: requirements differ by state and by local jurisdiction, and a practice that is common in one place is not a rule everywhere. Nothing here is a licence, a certification, or authority to work unsupervised, and completing it does not count as apprenticeship hours or continuing-education credit. Check the codes adopted where you are working, the licensing authority for that work, and your employer's safety programme. VoltMark is not affiliated with, endorsed by, or sponsored by NFPA, OSHA, NICET, BICSI, FOA, or any state or local licensing authority.

—