Embedded Controllers Need Flexible Test Systems

At Coin Acceptors, we design embedded controllers and peripherals for vending machines, and we must design our products to each customer’s specifications. These controllers operate with a wide range of machine peripherals that differ depending on what the machine vends. Furthermore, vending-machine manufacturers frequently ask us to add features. Sometimes, our customers will change the controller’s specifications after we’ve already started developing the controller.

To test a line of embedded controllers that work in a wide range of products, we had to design a test system that’s flexible enough to handle numerous variations in hardware and software. After all, the basic vending-machine functions are the same—count incoming money, vend the product, and give change. How a machine performs those functions depends on the machine’s components.

Controllers Vary
Product delivery, detection, displays, key pads, and refrigeration control are machine dependent. So, the hardware and software of the controller may differ significantly from machine to machine. To properly vend a product, a machine’s controller must communicate with vending-machine components such as coin mechanisms, bill validators, and card readers. Input devices range from discrete switches to matrix keypads. Output displays can be simple seven-segment LEDs or LCDs.

These peripherals communicate with the controller through one of several industry-standard protocols. The protocols allow online reporting of peripheral configurations so machine manufacturers can use the controllers all over the world.

To properly test a controller, the test system must simulate and monitor all inputs and outputs through the controller’s standard port interfaces and protocols. Therefore, we needed to design a test system with an adaptable hardware platform that can test controllers with many different types of signals. We chose a VXIbus-based system because it significantly reduces the total system size, provides for expansion capabilities, and gives us high-performance data-acquisition and digital-control functions.

We needed a consistent method to test each controller in the product line. So, we developed a test application that conducts the same basic functional tests—such as count change and vend product—on all our controllers. When we change machine types, we change the controller-specific test software and interface hardware. A layered approach to the test software lets us keep a consistent programming interface for test operators regardless of the unit under test (UUT).

The layered design shown in Figure 1 also lets us build the software around high-level function calls that describe basic controller operation. The application layer uses function calls such as establish_credit() and vend_selection(), which perform the same basic functions in every controller. Only the details of how that controller performs its functions will vary from controller design to controller design. Because of the layered design, the software in the application layer needn’t change when we change to a different UUT.

Figure 1. The application program imports the declarations library and calls the library’s functions, which import the software-layer and hardware-layer libraries depending on the unit under test.

With a consistent application layer, we know the test system performs tests the same way for all controllers. A layer we call the software layer interprets the calls from the application layer and makes the calls to the hardware layer. Functions in the hardware layer control the test instruments and communicate with the UUT.

We chose HP VEE as our development environment because it allows dynamic importing of function libraries—user functions from other VEE programs—at runtime. It also lets us use compiled functions (dynamic linked libraries) from existing C code. The software and hardware layer libraries are HP VEE programs that contain user functions specific to the UUT. We write new software-layer and hardware-layer libraries for every UUT; the functions in the application layer never change.

How does the test system know which software-layer and hardware-layer function libraries to use? With so many UUT designs, we needed a way to dynamically configure the test system for each controller. We store the configuration data in Excel spreadsheets and load the data into VEE using ActiveX communications.

The test system needs a way to identify the UUT and select the proper Excel configuration files. For each controller design, we built a custom hardware interface between the controller and the test system. The interface routes the proper signals from the controller to the tester.

Each interface contains a unique bit pattern that the tester can read. During initialization, the test system retrieves this pattern and “builds” an integer. The application layer then imports functions based on the interface’s bit pattern. Our application uses the VEE function installDir() to build a path to the software-layer and hardware-layer function libraries unique to each UUT.

In addition to loading function libraries, the test software must load information about the embedded controller’s software revisions. Excel spreadsheets also help us adapt the test system to account for revisions in a controller’s embedded code.

Get the Display
One example of revisions in a controller’s embedded code is the messages it displays. Display messages such as “Sold Out” differ from one type of controller to another. The tester must read and decode the messages the controller displays.

To decode the message a controller would send to an LED display, the application software reads the controller’s output ports. The software then consults a look-up table and searches for an integer that corresponds to the bit pattern from the port. The system loads the look-up table during initialization by opening display.xls ( Fig. 2) and flipping to the sheet name of the code revision being tested.

Figure 2. A VEE function dynamically loads the current revision of software’s display messages into memory.

Figure 2 shows how the application dynamically loads the current UUT embedded code-revision display messages into memory. The Load_Display_Components window contains VEE code that calls the InstallDir() function. From the contents of the variable code_revision, the application knows which Excel sheet in the file display.xls to open.

When a test begins, the system asks the test operator if he or she wants to create a new configuration or test an existing one. If the test operator chooses a new configuration, the test software opens an Excel template (Fig. 3) that contains the fields the test requires. The fields in an Excel sheet called User_Input come filled with default values that the operator can change to match test specifications if needed. If the operator chooses an existing configuration, the software opens a workbook that contains the configuration to be tested. After reading the data from the User_Input sheet, the software adds new time-stamped results sheets to the workbook for each time we’ve run that test configuration. Using the same workbook for a configuration assures us that the system runs tests consistently. We also have a history of each time the test was run for a particular configuration.

Figure 3. An Excel template lets test operators enter specific controller parameters before running a test.

Vending machines let the vendors who sell the machine’s contents configure machines in the field. A service person needs a way to change prices and even customize the machine for its specific location. For example, a service person might program a machine in a school cafeteria to vend juice all day but not vend soda during the morning.

A vending machine has a service menu that lets vendors configure the machine. A change in the service menu, as a result of a new software revision, changes the programming key sequence. We adapt to controller design changes in the service mode in the same way we adapt to the display messages. We create a hierarchy of the service mode menu in an Excel sheet, which comes from the customer’s specifications. Each menu item is in a column according to its location in the service menu.

The spreadsheet in Figure 4 shows part of the hierarchy of the service menu. We store the key sequence required to get through a menu selection in the column to the right of that menu selection. From this data, the test system builds a sequence of keys to get to the menu choice it needs to change and test.

Figure 4. Using Excel’s Find method, the VEE function “Get Values From Excel” returns a key sequence, depending on the code revision, that simulates a service person programming the vending machine to change its prices. The X’s in Column D represent the keystrokes. Excel sends the keystrokes to VEE through ActiveX communications.

By using spreadsheets, we can update the test system in about 15 minutes so it can interpret display messages from a new embedded software revision. We just add a sheet to the display.xls file. Then, we copy and paste the new display messages from a table in the controller’s new specification.

From our experience, we believe you can build a flexible test system with basic instruments and standard interface technologies. Off-the-shelf programming and spreadsheet packages can provide software flexibility through technologies such as ActiveX. A flexible ATE system software architecture lets you easily adapt and expand the system for new UUTs and UUT configurations. T&MW

David Paslay and Greg Lawson are design engineers within Automated Test Systems at Coin Acceptors in St. Louis, MO. Paslay has a B.S.E.E. from Southern Illinois University at Edwardsville. Lawson has a B.S.E.E. from the University of Missouri—Rolla.