Automate DWDM card tests
Use layered programming to simplify the test of DWDM network components and eliminate manual bench tests.
Anthony Lukindo, Ciena, Linthicum, MD -- Test & Measurement World, 1/1/2002
|
Many optical telecommunications networks use dense wavelength division multiplexing (DWDM) technology to move bits over multiple channels in the same fiber. In these networks, DWDM transmit cards convert electrical signals to optical signals, then amplifiers boost the signals along the network. A complete DWDM network may use as many as 200 component cards. (See An end-to-end DWDM network for details on how components form a DWDM optical network.)
During production, network components such as transmitter cards and amplifiers must pass numerous tests. First, a component must pass bench tests under simulated laser signal input and output conditions. Bench tests verify that a component meets specifications for parameters such as output power, power variance, extinction ratio, and signal-to-noise ratio (SNR).
Unfortunately, bench tests don't prove that a component will perform acceptably in a DWDM network. You need network-level tests to verify that a component functions properly when installed in a network. For these tests, you place a UUT into a known network and measure its optical performance.
Finding a way to automate DWDM tests can be challenging because of the large number of tests that you must perform. Yet, if you plan your tests carefully, you can automate them. I'll use the example of signal-to-noise ratio (SNR) tests to show a method of automation. Table 1 lists some of the measurements required for an SNR test.
In a test such as SNR, you start with a known DWDM network and replace a known good component with a UUT. You then measure the effect that the UUT has on the network's overall performance. For example, a transmitter card's SNR will affect power and wavelength modulation across the network.
Equipment you needTo perform an SNR test, you need an optical spectrum analyzer (OSA). Look for an OSA with sufficient dynamic range, optical sensitivity, and bandwidth resolution. (See Ref. 1 for a description of these specs.) Other tests require equipment such as a power meter, a wavelength meter, a digital communications analyzer (DCA), an optical spectrum analyzer (OSA), and a SONET bit-error rate tester.
You need a programmable optical matrix switch to route signals to the proper instruments. Automated optical signal switching improves performance over manual switching by cutting test time and reducing contamination in optical cables and connectors (Ref. 2).
![]() |
| Figure 1. A composite DWDM signal contains as many as 100 discrete wavelengths, each represented by a single peak. From those wavelengths, an optical spectrum analyzer can measure parameters such as power variance, minimum and maximum power, and SNR. |
![]() |
| Figure 2. An optical spectrum analyzer calculates SNR from PPeak, PASE right, and PASE left. |
In Figure 1, an OSA displays DWDM composite signals as a set of peaks. Each peak represents a discrete wavelength, or data channel. The instrument calculates SNR from the peaks and slopes of each signal (Figure 2). An OSA measures the signal's amplified spontaneous emission (ASE) noise power based on the locations of PASE left and PASE right, the left and right noise power levels at wavelength spacings equal to one-half the channel width from the signal's peak. PPeak represents a signal's peak power. From those three points, the OSA calculates SNR:

After calculating SNR, an OSA can send the test results to a host computer over an IEEE 488 link. That saves you from performing (and programming) calculations in the host computer. Still, you need to automate system-level tests so you can properly configure your test equipment. You also must program the system to connect test equipment to the proper nodes (test points) at the proper times.
To perform these tasks, you should use a layered approach to test programming. Then, you can use a test executive to pass configuration data to lower-level program code. Your test executive also should determine the appropriate DWDM System configuration so that you can perform the tests.
Figure 3 shows a data flow block diagram written in National Instruments' LabView 6i. The diagram highlights the steps you can follow to develop your own SNR test code. I've annotated the diagram to correspond to the following steps:
![]() |
|
Figure 3. SNR test code should take data from a test executive, initialize instruments, take measurements, and report the results. |
- Step 1: The test executive sends DWDM system configuration and instrument data to the SNR test code, which is the entire LabView code shown in the figure.
- Step 2: The code contained in the "Signal Test Plan" box uses the configuration data from the test executive to prepare a test plan, or sequence. The "Test Plan" data flow line passes iterations of the measurement steps that cover measurements at appropriate DWDM network nodes to the loops that run the test code that controls the test equipment.
The "Signal Test Plan" code also generates a template with data place holders that store measurements for transmitter, amplifier, pump, and combiner circuit cards. The "results template" standardizes the measurements collected for each card. Templates provide place holders that you can use to monitor and flag any missed measurements. If several people write test programs for the same test stand, then a results template ensures they use a consistent format for all test results. - Step 3: The "INI Devices" box gets initialization data from the test executive and initializes the instruments in the test system. It formats the information into test strings that control the test instruments.
- Step 4: The 'IF CASE'construct "System Configuration&Instrument OK" (shown as "True") lets the tests proceed only after the program properly configures the instruments.
- Step 5: The "Iterate by Direction" sets the direction of the data flow in the optical network and sets the optical switches accordingly. We call the directions "east" and "west."
- Step 6: The "Iterate by Node" loop contains a sequence of test procedures, one for each node in the DWDM system. The specific code runs in code blocks in steps 7 through 10.
- Step 7: The test program operates an optical switch to connect the correct node to the OSA.
- Step 8: In the "SNR Lambda Test," the OSA captures signal peaks from the composite signal and sends the data to the host computer, which assigns the wavelength readings to the closest known resident transmitter wavelength in the DWDM network. The code then fills the "Results template" with data.
- Step 9: In the "SNR Power Test," the OSA measures optical power in each channel and calculates SNR.
- Step 10: The SNR test program checks the test status and then decides if it can proceed to another node or if it should abort the test. The program also will abort the tests on command from a test operator.
- Step 11: The test program saves test results so you can generate test reports and archive data in a database.
- Step 12: The SNR test code reports any errors to the host computer.
- Step 13: The SNR test code reports test results to the host.
When developing your test program, you will need to include an operator interface that test technicians can use to initiate a test and see the results.
![]() |
| Figure 4. Test operators need a way to start and stop a test. They also need to know which test is running, to get test results on the UUT, and to test parameters on the entire DWDM network. |
The TXMT (transmit) Channels panel provides test results on the UUT. Here, the test operator can see the channel wavelength (l) and SNR for that channel. If a signal peak doesn't match a known transmitter modulation wavelength, the card fails the test. When the tests pass, the DWDM channels have enough optical power and the correct wavelength and the network will show minimal crosstalk between adjacent channels, which allows for successful decoding. Indicator "LEDs" to the right of each measurement window indicate a passed or failed test.
The Common Equipment panel shows the summary of composite signal optical characteristics assigned to what we call "common equipment" cards—amplifiers (AMP), pumps (PU), and combiner cards (not shown in Figure 4). Any failures in measurements on the TXMT Channels panel will change the results in the Common Equipment panel's measurements. For example, if one transmitter transmits a signal with power that's too low, then all common equipment cards will show a high power variance—the difference between the wavelength with the highest power and the wavelength with the lowest power—and a lower-than-expected minimum power for the composite signal.
Functional tests such as SNR let you demonstrate that a DWDM transmitter will function properly in an actual optical network. By designing your software with layers so system configuration data will pass from a test executive to test programs, you'll design a flexible test system capable of testing numerous DWDM network components.
| DWDM CARD | VALUE NAME | DESCRIPTION |
| AMP/PU/CO | Power variance W-E | Max peak power minus min peak power |
| AMP/PU/CO | Min power W-E | Min peak power |
| AMP/PU/CO | Min SNR W-E | Min signal-to-noise ratio |
| TX | Output | Peak power for this wavelength |
| TX | SNR | The signal-to-noise ratio for this wavelength |
| AMP= amplifier, PU = pump, CO = channel combiner, TX = transmitter, W-E = West-to-East | ||
| References |
|
| For more information |
|
"Dense Wavelength Division Multiplexing (DWDM) Testing Tutorial," International Engineering Consortium, Chicago, IL. www.iec.org/online/tutorials/dwdm_test. Derickson, Dennis, ed., Fiber-Optic Test and Measurement, Prentice Hall, Upper Saddle River, NJ, 1998. Johnson, Gary, and Richard Jennings, LabVIEW Graphical Programming: Practical Applications in Instrumentation and Control, 3rd ed. McGraw Hill, New York, NY, 2001. Strassberg, Dan, "200 THz: testing's tough new frontier." EDN, July 6, 2000. www.e-insite.net/ednmag. Titus, Jon, "DWDM Communications Rely on Basic Test Techniques." Test & Measurement World, March 2000. p. 42. |
| Author Information |
| Anthony Lukindo is a senior test engineer with Ciena's test development division for systems integration and manufacturing testing. He develops automation software for volume production testing of DWDM network components. He has an MS degree from the University of Newcastle upon Tyne and a PhD from the University of Minnesota. |
|























