OOP Design Challenge #2: Applying Calibration Data

[Daklu]

The purpose of the OOP Design Challenge is to learn about different design approaches to solving a particular problem. By sharing our ideas and discussing the pros and cons of different solutions, hopefully we all become better informed of the consequences (both good and bad) of different approaches and more confident that the decision we make is correct for our situation. It's important to remember there is no single "right" answer. If the code meets the minimum requirements it is "right" by definition. Different solutions will provide flexibility in different areas of the software. The value is in discussing the tradeoffs associated with each design.

This is not intended to be for advanced programmers only. Programmers of all skill levels are encouraged to contribute ideas and ask questions. You don't need to have a complete solution worked out. If you have the beginning of an idea but you're not sure it will work, post it! That's what this is for. Although I have titled this "OOP Design Challenge," it is open to any kind of solution you think makes sense. It can be based on OOP, libraries, action engines, xcontrols, .Net/ActiveX components, or any other scheme you dream up.

------------------------

So... challenge #1 generated about as much interest as a McDonald's at a PETA convention. My fault. The problem was too big, too complex, and not described well enough for any meaningful discussion. Let's try a different problem I recently encountered. This one should be much less complicated; hopefully it will generate some ideas.

Scenario:

We have written a test sequencer for an automated RF test station. All tests the sequencer can run derive from an abstract parent test case with Init, Execute, and Abort methods. The station can be configured to test up to 4 devices sequentially by using a switchbox to route the RF signals from each DUT to the appropriate test instruments. The (simplified) sequencer program flow is:

FOR EACH deviceUnderTest  IF deviceUnderTest.isEnabled = True THEN    FOR EACH testCase      IF testCase.IsEnabled = True, THEN testCase.Execute(commonParameters)  // commonParameters can be modified to include additional data as needed    NEXT testCase  END IFNEXT deviceUnderTest

One source of measurement error is that the RF signal losses vary according to test position. We have an external calibration process calculate the signal loss along each applicable endpoint-to-endpoint path and record it in a calibration file. The table for each unique endpoint combination is in the form of a frequency-signal loss key-value pair. In other words, the DUT1-Instrument1 path will have a table of frequency-signal loss pairs, the DUT2-Instrument1 path will have a different table of frequency-signal loss pairs, etc.

Problem:

The test cases need to pull values from the appropriate table in the calibration file to apply corrections to the instruments and measurements. What's your strategy for adding this functionality into the sequencer?

The current DUT number is passed to the test cases as an enum in the commonParameters cluster. DUT number does not change during a test case. The test cases "know" what instruments they need to connect to, however, a test case may use more than one instrument and need information from more than one table. We can influence the data format and type of file the calibration process creates as long as it remains human readable, so feel free to extend your design into that space as well.

---------------------------

I'll post my implementation in a couple days.

[Mark Smith]

Well, one approach would be to make specific implementations that inherit from an interface class for everything that gets indexed in the for each loops. So, you have a parent DUT class that all of the unique types of DUTs (four?) inherit from. Then the next for each loop invokes the correct test methods on the DUT. It appears here that the TestCase would need to know what kind of device is being tested - I would propose that it might be better that each DUT (and here I mean the DUT object, not the actual physical device) knows which tests need to be performed on it and contains those tests in a collection. So the sequencer program flow would be almost the same, except it might look something like

foreach deviceUnderTest in devicesUnderTestCollection foreach testCase in deviceUnderTest.TestsCollection testCase.Execute()  next testCasenext deviceUnderTest

The if-thens aren't really needed - if the deviceUnderTest isn't part of the collection, it doesn't get tested and if the testCase isn't part of the deviceUnderTest tests collection it doesn't get executed. Now, the test case knows that it is a member of a specific device's test collection and it can get private member data about the DUT without passing any parameters as function arguments. This could include data from the calibrations file(s).

As far as data format, unless there's strenuous objections to XML (it's sometimes debatable whether or not it's "human readable"), use the LabVIEW flatten and unflatten from XML functions - these can serialize the data structures or the objects depending on what you need.

Mark