Profiles vs DUTs

[jason.hicks]

I’ve asked this question before to the OpenTAP guys, but I thought I’d share this in the forum as I’m
curious how others may do this.

Overview:
An 8-port radio test system for testing one DUT at a time. The DUT is a complicated configuration with many parameters, command automation options and with many power setting tables.
The problem is not with testing the DUT, but with maintaining the system after it has tested 10s of different types of DUT.

Method 1 - Using DUT items:
The Editor soon becomes crowded with DUTs and becomes unworkable (Fifg2.). This is solved by creating a new profile to archive the old DUTs.
It was simple for test steps to select the new DUT, but the issue was that every time a new DUT was added, the connection node ‘Port 1’ had to point to the new DUT. If a previous DUT had to be tested again the connections would need change again. Changes have to made in the Bench Settings and in the Test Plan. It’s easy to see how this would lead to human errors.

Method 2 - Many Profiles:
A profile created for each DUT. This means the system is configured with a single DUT and the Test Plan will select the same DUT. The Connections will also be always connected to the same DUT. This is the way I have chosen to this and it works very well.
There are two minor but significant problems with this, but neither is a deal-breaker.
a) After the switch path losses have had their annual calibration the Connections cable loss tables need updating for all profiles.
b) New profiles have to be created by importing a pre-configured profile with all the correct instruments and connections.

Question 1:
How are others approaching this?
Question 2:
Could Method 1 be viable if there was a way to create a resource with 8-ports that the Connections would use and the DUT item could access to get the connections data? Every DUT item would then access the same ‘dummy’ ports connections data.
The Editor GUI could restrict the number of DUT items shown at the bottom of the screen to stop overcrowding.
Question 3:
Method 2 is very workable, but is there a way I can point the option in the profile dropdown so It opens a profile of my choice?
Also, would there be a way to decouple the Connections cable loss data from the Profile? This way the Connections cable loss could point at another built-in component where cable loss tables can be entered, basically mapping a connections entry with a separate cable loss entry.
Update: I see the DUT as a separate entity from the Connections and Instruments. Say I have 20 profiles, but unfortunately, I now have to swap out the PSU due to equipment failure. I suppose I could simply change all the Instruments.xml file in each profile, but is there a formal prescribed way the Editor could address this?

Fig 1.

Fig 2.

Fig 3.

[brennen_direnzo]

@jason.hicks I don’t think there is a perfect answer here, but definitely would like to open up the discussion.

What do you think would be an ideal solution here? We actually have some on going work around updates to the Connections (related to this topic: Common Switch Interface), so any feedback here we would try to incorporate.

I’m interested if @david-wsd has any thoughts/recommendations based on his experience.

[jason.hicks]

@brennen_direnzo I imagine the need for the common switch interface is somewhat the same for a common DUT interface wrt Connections.

Basically DUTs and Instruments implement Ports, but DUT’s are slightly different.
For instance, you could have a production line test systems that tests hundred of DUTs per day, but these are the same kind of DUT, just a different serial number. The Bench configuration wouldn’t change between DUTs.

Alternatively, as we do, you could have a regulatory compliance test system, that test one hundred units a year, but each DUT is very different. It could be a Bluetooth DUT with a single antenna port or a Wi-Fi router with eight antenna ports. We have designed an 8-Port test system consisting of an 8-Port DUT, an 8-SwitchPosition switch, , an 8-Port power sensor, a single port analyser and a combiner box.

The main Bench configuration does not change often as the switch, power supply, signal analyser, power sensors, signal conditioning box and connection cable losses only get updated with annual calibrations. However the DUT configuration changes for each DUT.
The as you can see from Fig 1. The power sensors and PXA expose a single port which makes up the Port 2 node and the DUT exposes eight ports used for the Port 1 node. These are connected via the switch positions.

The only downside I currently have is that I have to update Connections.xml in all the saved and exported profiles after the annual calibration, or for cable replacements (new cal data).
Recalling an old DUT profile could result in using stale calibration values.

[david-wsd]

Hi @jason.hicks, sounds like a sophisticated system. I’m not sure I understand all the nuances of your situation, but I can share some of my general approaches, for whatever it’s worth.

1. I don’t use Connections
   Instead, I created my own settings page, called “RF Paths”, which is very similar to Connections. Instead of typing in the calibration factors into a UI table, it points to a csv file which contains the calibration factors.

Slap this attribute on a custom ComponentSettingsList class to get the grid style of the Connections page: [ComponentSettingsLayout(ComponentSettingsLayoutAttribute.DisplayMode.DataGrid)]

2. I don’t use DUTs very much
   When I began developing in OpenTAP, I decided that if I were to design a test system that depended on DUT objects, there would be 2 consequences:

• The test system’s capabilities would be mainly limited to those specific DUTs
• I (the developer) would have to get involved every time a DUT change is needed. As such, the system would not adapt quickly to new DUTs.

So basically, my solution is more test-hardware-configuration centric, and not very DUT centric. And I’ve opted for custom settings pages instead of the built-in DUTs and Connections.

[jason.hicks]

Hi @david-wsd.
Thanks for suggestions. It sounds like you have a neat way round some of the potential pitfalls I have witnessed and it’s really good to hear how other developers using the system.

When I picked up OpenTAP I was determined to implement everything in a purists way and to use the framework as prescribed. It worked very well but this issue has always played on my mind.
It’d be awesome if the dev guys can come up with a solution to this, but I can understand if this wasn’t a test scenario that was ever considered.

[jason.hicks]

I’m resurrecting this old topic as I’ve decided that the only way I can do this is by modifying OpenTAP.

Backstory: I have many different types of DUTs to test. I can do this by having a complex DUT resource that can be configured with many parameters and settings. The DUT resource can have up to 8 ports that connect to various instruments, and so implementing Connections is ideal and works beautifully.
Instruments define the test system set-up and Connections connect the DUT to instruments via connection paths that contain the ‘calibration’ values for the system.

Implementation: I use profiles to save different DUT configurations so they can be recalled at any time.

Problem: Bench contains all Connection, Instruments and DUTs. As such it’s not possible to ‘decouple’ the DUT from Connections and Instruments, and so, the whole system is saved in a profile. This is a big problem when recalling a DUT when a) the profile is used on another system, or b) it recalled after an annual calibration has been done.

Hopefully, you’re still with me…
The solution is ridiculously simple BUT a pain:
The code below is from OpenTAP DutSettings.cs.

    /// <summary>
    /// Settings related to the DUTs currently available. 
    /// </summary>
    [Display("DUTs", "DUT Settings.", null, -10000, false, null)]
    [SettingsGroup("Bench", true)]
    public class DutSettings : ComponentSettingsList<DutSettings, IDut>
    {
        public DutSettings()
        {
        }
    }

By changing the following…

    [SettingsGroup("DUTs", true)]

… and recompiling Tap.Engine, I get a decoupled DUT profile as below. Both Bench and DUTs now have separate profiles.
Does anyone else see the need for this or am I just missing something or doing it wrong?

[brennen_direnzo]

If others find a similar need, I am open to this.
Not sure if you tried this, but a possible solution, although likely not ideal, would be just creating more Profiles, even if only the DUTs.xml file changes and the others remain the same.

@rolf_madsen (for when you are back) what do you think?

[jason.hicks]

@brennen_direnzo Profiles doesn’t solve the problem though. I wouldn’t be able to use a profile on more than one test station as the instruments would be configured with the wrong address for example.

I did mention this to Rolf and the guys, but I don’t understand how this test scenario can be realised using the current Bench implementation. Are you hiding a secret feature? Does this mean that the likes of me and @david-wsd will always need to implement workarounds?

Has any consideration been given to this test scenario? Do other developers have similar systems planned and how do they plan to implement them?