TII/HI/TAD

Meeting Minutes

9/16/2010 – 9/18/2010

  1. Attendees

Name / Affiliation / email
Malcolm / Brown / UK MOD (DE&S) /
Keith / Ellis / AKE Consultants /
Steve / Fairbanks / GEMS /
Bob / Fox / NAVAIR /
Chris / Gorringe / EADS TES /
Hans / Hopf / SEKAS /
Ashley / Hulme / EADS TES /
Geoff / Ingram / Diamond Glenn Software /
Teresa / Lopes / Teradyne /
Scott / Misha / US Army /
Ion / Neag / PIDESO /
Mike / Seavey / Northrop Grumman /
Kent / Shoemaker / USAF (Robins AFB) /
Dianne / Shook / Diamond Glenn Software /
Ron / Taylor / Summit Test Solutions /
  1. Joint Meeting to Discuss New PAR

PAR submitted as part of SBIR (Formalizing Accommodating of Transitory Path Intrinsic Characteristic).

Goal is to capture characteristics of the total path through the system (all wires and switches).

The group concluded that a new PAR was not really necessary. Rather, a TII task group was formed consisting of TII and HI members to identify what information needs to be captured and what extensions/modifications to the existing schemas are necessary to capture this information.

The group is to provide draft report by the end of December 2010report final finding at the January Working Group Meeting.

  1. Next Steps

Focus on issues from use cases and AUTOTESTCON demonstration.

Get the 6 “dot” standards out.

Update website to provide more user-centric information. Identify what information users are looking for and figure out how to get it on the website. One way to get good user information on the website is to talk to a user who is just getting started and figure out what information they need.

  1. Demonstration Feedback

Demonstration created 3 types of instance documents

  • UUT Description
  • Test Adapter Description
  • Test Description

The test description documents were translated into several different kinds of test programs. Each generated Test Results.

Need to ask the demonstration group and users for feedback on standards (need this in short notice so that it can be addressed before “dot” standards go to ballot)

Also need to determine if there were any issues identified as part of the standards survey and if there are any open issues from the first demonstration.

Specific comments from demonstration:

  • Interface is “different” at the different levels.
  • UUT is signal oriented
  • Test Station is signal oriented
  • Test Adapter is pin oriented
  • Test Adapter wants to describe pin-to-pin wires
  • In the instance documents paths are described as port-to-port connections
  • When crossing instance documents paths are pin-to-pin wires
  • Don’t need a port for each pin
  • XPath clearly identifies the pin on the connector
  • Could also use XPath to describe a connector-to-connector path
  • When creating instance documents in parallel still had to create a paper document in order to define the wirelist
  • For most UUT components identifying the part number was not an issue. Things got tricky when trying to identify a resistor.
  • Need a way to identify basic UUT components (resistors, diodes, etc.)
  • For some components may also need to identify placement
  • In the Test Adapter wanted to identify the resistance. Need to duplicate information in NetList and Path – not an issue if you have tools, annoying if you have to do it by hand.
  • Duplication is not an issue – it’s being able to capture the information that’s important
  • Need a place to capture wire length, coax, etc.
  • Test Description
  • Currently only store one outcome for a sequence
  • What do you do if you want to know what test in a sequence failed
  • Need to deal with ambiguity groups
  • Test Results
  • Results from what appears to be the same test program are very different
  • Don’t actually record the results of the tests – record the results that the tests gave us
  • IDs in test description have to be unique – used as references in Test Results
  • Qualifiers on outcomes are a god send
  • Given a set of test results you would like to be able to play back what the test description would have done
  • Traceability from the test results to the test program
  • Helps prove that the test program is doing what is should do
  1. Website

Provide a user forum – need to figure out how to get around some IEEE issues

Revamp the user guide

  1. Schedule

1671.1 Test DescriptionAnand?/Teresa

1671.2 Instrument DescriptionChris Gorringe

1671.3 UUT DescriptionIon Neag

1671.4 Test ConfigurationRon Taylor

1671.5,6 Test Adapter & Test StationMike Seavey

TODO:

  • Put all “dot” standards back into the template
  • Still working with Altova (XMLSpy) about using their documentation format directly

Schedule

.2, .3, .4 / .1, .5, .6
Collect Comments from ATML Demo 3weeeks / 10/14/2010 / 10/14/2010
Create issues list from comments for each ‘dot’ standard / 12/2010 / 12/2010
Get Master documents for IEEE into new IEEE Template / 1/14/2011 / 1/14/2011
All input received user inputs / 1/14/2011 / 1/14/2011
Review confirm all issues – plus suggested solution / 1/14/2011 / 1/14/2011
Final task group input (confirm time scales with task group) / 1/16/2011 / 1/16/2011
Initial Update schemas to include comments / 4/2011 / 9/2011
Update support files to match schemas / 7/2011 / 4/2012
Draft Documents need to be updated to current Schema (depends on Altova) / 9/2011 / 9/2012

Where/How do we share development documents

  • Google Docs
  • Office.Live