Design Con 2015

Scripts automate communications test

-June 01, 2001

Protocol analyzers, data generators, voice-over-IP (VoIP) testers, and other test equipment come with graphical user interfaces (GUIs). Generally, a GUI is all you need to run many test applications, but sometimes you need more flexibility. Scripting languages can help. They take over where manufacturer-supplied GUIs leave off, so you can write your own automated test procedures.

Scripts let you use a tester’s features in any order you want, and they let the tester make decisions based on test results. For example, if you need to test a router or switch, you would use a data generator to create packets or frames for your UUT’s inputs (ingress) and use a protocol analyzer to capture and decode the UUT’s outputs (egress). With scripts, you could instruct the test system to abort the test sequence if a parameter, such as throughput, falls below a preset limit.

Scripts also let you control the interaction between two or more testers. If the data generator and protocol analyzer reside in the same box, then you can use the manufacturer’s GUI to control them, but you can’t use the GUI to synchronize their operations. With a scripting language, you can control the timing of the tests and command the protocol analyzer to look for data at the right time.

Get into scripts

Scripting languages let you write application code at a higher level than languages such as C and C++. Scripts remove you from the details of controlling your test equipment’s underlying functions, yet they provide loops, branches, and If. . . Then statements for program flow and control.

Listing 1
# Load Ixia Tcl Libraries
package req IxTclHal
# Connect to Ixia Chassis
ixInitialize 192.168.5.179

# Define which port to use
set portList {{1 2 1}}

# Get the current configuration of the capture buffer from port
capture get 1 2 1

# Get the group of captured frames from the port
captureBuffer get 1 2 1 1

# Get the first frame from the captured frames from the port
captureBuffer getframe 1

# Set the variable capframe to the first frame in the capture buffer
set capframe [captureBuffer cget -frame]

# Decode frame to determine if it's a RIP packet
rip decode $capframe

Courtesy of Ixia Communications
Listing 2
&loop = 1
while (1 = &loop)
  wait %frame for 0 up
  switch %frame
    case keyboard:
       parse %frame
     endcase

     {2} case type t_data_indication:
        locate i in %frame
      %h225csframe = substr(%frame;&LOC_INDEX;&LOC_LENGTH)

       switch %h225csframe
          {2} case type callproc:
             sprint 'received CALL PROCEEDING'
           endcase
          {2} case type alert:
             sprint 'received ALERT'
           endcase
          {2} case type conn:
             sprint 'received CONNECT'
             &loop = 0
           endcase
           other:
              sprint 'case other'
         endswitch
      endcase
   endswitch
endwhile

Courtesy of Catapult Communications

You don’t need experience in C or C++ to write scripts. If you’ve written test code in Basic, you know enough to learn most scripting languages, particularly if your test equipment uses a public-domain, general-purpose language such as tool command language (Tcl). Tcl is gaining in popularity among test-equipment manufacturers, although proprietary scripting languages still find widespread use. See “Proprietary or open source?” for the advantages and disadvantages of both options.

Because Tcl is a general-purpose language, test-equipment manufacturers extend it with compiled C routines that control a tester’s functions. You can call those functions from a script in much the same way that a Visual Basic program calls functions in a dynamic-link library (DLL). The language extensions let you control a tester using function calls with names that resemble the instrument’s GUI buttons. Like DLLs, language extensions hide the low-level programming details from you, which eases programming tasks.

Listing 1

shows a sample Tcl script. Note that the script appears more “English-like” than code written in C or even in Basic. The script captures a frame, decodes it, examines it, and decides if the frame conforms to the routing information protocol (RIP) structure. The “rip” function in the last line—a Tcl extension—reads a frame’s header and, based on the frame’s structure, returns a true value or a false value to the script. You can then use Tcl’s loops and If. . . Then statements to decide how your script should proceed. (See “Tcl resources,” below, for sources of Tcl information.)

Proprietary scripts may use an “English-like” syntax similar to Tcl, but they may also resemble C code. Listing 2 shows an example of a proprietary language called “data communications programming language” (DCPL) developed by Catapult Communications (Mt. View, CA).

Whether you write scripts in a public-domain language (Listing 1) or in a proprietary language (Listing 2), you need a programming tool. While experienced script writers may feel comfortable writing code from a command-line interface and use only a text editor, many test engineers prefer a graphical programming language. Programming tools that come with test equipment use a variety of methods that help you build scripts. A graphical script builder may, for example, use a Windows-Explorer-like tree structure from which you select test functions to build text-based scripts.

TMW01_06F4fig1.gif (8686 bytes)
Figure 1. A graphical script controls the program flow of text-based scripts through arrows and icons. Courtesy of Schlumberger.

Another graphical method lets you build scripts that combine graphical code with text-based code. Figure 1 shows a graphical script that controls a tester’s program flow. Each icon represents a call to a text-based routine that performs the test functions. The diamond-shaped icons, for example, represent decision points in the

program. If you use this scripting language and click on an icon, you’ll open a window that displays the icon’s underlying code. The “pt at” icon, for example, holds the code for an impulse-noise test on a telephone line.

Script builders also may work like macro recorders that record your test-setup steps. You can then paste the recorded code into a larger test script.

Although programming tools let you develop your own scripts, you need not write every test script yourself. Test equipment manufacturers offer test suites for popular or for standards-based tests. For example, you can get a test suite for a data generator that lets you test cable modems for interoperability with cable modem termination systems.

Another test suite that controls a data generator and protocol analyzer lets you test network components such as switches and routers for frame throughput, latency, loss rate, and arrival time variation (frame jitter). T&MW

Martin Rowe

has a BSEE from Worcester Polytechnic Institute and an MBA from Bentley College. Before joining T&MW in 1992, he worked for 12 years as a design engineer for manufacturers of semiconductor process equipment and as an applications engineer for manufacturers of measurement and control equipment. E-mail: martin.rowe@ubm.com.


Proprietary or open source?
Some telecom and datacom testers use Tcl, an interpreted language, while others use proprietary languages—both interpreted and compiled. Each option has advantages and disadvantages:
Tcl—Advantages
• You can transfer your programming knowledge from one manufacturer’s equipment to another’s.
• An abundance of Tcl resources is available, including books, Web sites, and Internet discussion groups. Thus, the language will remain “supported” for a long time—unlike a proprietary language for which support disappears if the manufacturer goes out of business.
• Tcl is a public-domain language. If you change companies, departments, or assignments, you can apply your Tcl knowledge to applications beyond telecom and datacom.
• Tcl is an interpreted language, so you can run scripts line by line, which simplifies debug.
• Tcl has an extension toolkit, Tk, that lets you build custom GUIs.
• Tcl code will run on a variety of operating systems, such as Microsoft Windows, Apple MacOS, Unix, and Linux.

Tcl—Disadvantages
• Because it’s a public-domain language, Tcl’s underlying core is under committee control. Upgrades and bug fixes often come more slowly than with proprietary code.
• Interpreted code runs slower than compiled code.

Proprietary languages—Advantages
• Test equipment manufacturers can add features to a proprietary language that a standard language may lack.
• The underlying core of the language is under strict control of the equipment manufacturer, who has telecom applications in mind when making any changes to the language.
• Some test equipment manufacturers use compiled scripting languages, which run faster than interpreted Tcl.

Proprietary languages—Disadvantages
• Programming knowledge isn’t portable to test equipment from other
manufacturers.
• Information on how to use the language is available from the equipment manufacturer only. If the company goes out of business, you have nowhere to turn with your programming questions. —Martin Rowe

Tcl resources
Tcl is a public-domain language that lets you automate procedures through high-level scripts. Developed in the late 1980s, Tcl has evolved into a general-purpose language used to control microprocessors and automate Web pages. Tcl has a companion language toolkit, Tk, that lets you build graphical user interfaces with text commands. An Internet search will reveal hundreds of Tcl resources, such as books, tutorials, conferences, and discussion groups. I’ve listed below several books, Web sites, and a newsgroup to get you started in your search for information about Tcl/Tk.
  I recommend that you start at www.scriptics.com, from where you can download the Tcl/Tk engine and development tools. The site also has extensive listings of tutorials, books, white papers, and histories of Tcl/Tk as well as links to other useful sites.—Martin Rowe
Books
Flynt, Clif, Tcl/Tk for Real Programmers, Morgan Kaufmann Publishers, San Francisco, CA, 1998.
Raines, Paul, Tcl/Tk Pocket Reference, O’Reilly & Associates, Sebastopol, CA, 1998.
Welch, Brent B., Practical Programming in Tcl and Tk, Prentice Hall, Upper Saddle River, NJ, 2000.
Web sites
“Brad Appleton’s Tcl/Tk Links” contains extensive links to Tcl/Tk resources. www.enteract.com/~bradapp/links/tcltk-links.html. Editor's Note 10/24/03: This page has moved:http://www.bradapp.net/links/tcltk-links.html.
“Tcl/Tk Information” gives tutorials and even includes entire texts of several books in postscript format. hegel.ittc.ukans.edu/topics/tcltk.
“Tcl WWW Info” lists frequently asked questions, Tcl extensions, development tools, and download sites. www.sco.com/Technology/tcl/Tcl.html. Editor's Note 10/24/03: This page has moved:http://www.cc.jyu.fi/~levanen/tcl/Tcl.html.

Loading comments...

Write a Comment

To comment please Log In