ATML Test Description
Orlando, FL, Jan 15, 2008
Meeting Minutes
Attendees
Mike Seavey
Chris Gorringe
Bob McGarvey
Mark Skiba
Teresa Lopes
Scott Misha
Steve O’Donnell
Anand Jain
David Sharone
Tim Davis
Jim Orlet
Rick Freeman
Ion Neag
Agenda
- Status
- Review changes
- Feedback from Candidate evaluation
- Schedule for review and ballot
Status
Ion Neag presents the status of development. Ion created and uploaded in Groove Candidate5 of schema (addresses issues discussed at last meeting). Anand created Candidate 6.
Changes
Discussed change to allow the specification of postconditions for individual Outcomes of Test and Test Group. This was driven by a used case originally proposed by Mark Skiba, where a Test is used to identify the version of the firmware loaded in the UUT. Ion is concerned that attaching different Postconditions to different Outcomes goes against the semantics of Test Outcome. The group identifies an alternative solution to support the Firmware Version use case with reasoners, w/o attaching Postcondtions to Outcomes.
- SessionAction checks the firmware version and sets State Variable to either V1 or V2
- Tests for version V1 have a precondition requiring the value of the State Variable to be V1. Tests for version V2 have a precondition requiring the value of the State Variable to be V2
Mark agrees with the solution. The group decided to leave Postconditions at the Test level.
AI: Ion to revert change
AI: Ion to describe in an example the use of state variables and preconditions to select tests based on firmware version.
Discussion on checkingUUT state (ex. Firmware version). The group agrees that SessionAction should be used for this purpose, rather than Test.
AI: Ion to describe in Examples what is proper used for Test (i.e., verify UUT characteristic).
Discussion on allowing operators to overriding TPS operation. This should be possible for some Actions (ex. Pass/Fail) and not for others (ex. Check firmware version). It is not clear if this belongs in the Test Description document, or should be left as an implementation issue. Ion points out that different tools support this differently; there are mechanisms in ATML (e.g., Custom Type attribute of Test, extension) that allow users to do this in an organization-specific or tool-specific manner. The group decides that specialized support for this type of functionality is not needed; it would be useful to describe to users how they can support it with the available features
AI: Ion to describe as use case for the Custom Type attribute of Test.
Discussion on abstract base type created for abstract base type created for Test and SessionAction. It is not clear if there should be a single collection of elements of the bae type, or two collections (one for Tests and one for SessionActions). The group decides to implement the first alternative.
AI: Anand to reference abstract base types, where collections of Test and SessionActions appear.
Old Action Items
Discussion on Representing shorts in IEEE 1641 signal descriptions. This was discussed at SCC20 Meeting in Baltimore. In summarizes the solutions that were proposed:
- Use “Constant” BSC to apply zero Ohm impedance
- Use “Constant” BSC to apply zero Volt voltage
- Connect Load with zero Ohm impedance to UUT pins
Chris points out that there is an additional solution exists: listing multiple pins under a channel of a Two Wire connector; this requires the pins to be interconnected through switching. Ion suggests that a connector with a single channel would me more appropriate. Chris suggests the Series connector.
AI: Ion to update the Example using SHORT.
Issues from Candidate Evaluation
Matt Cornish could not attend. He will email Ion the issues he discovered during prototyping.
Anand presents a set of issues discovered by National Instruments while evaluating the draft schema.
1. TestGroupParallel needs to define number of threads
Discussion on the semantics of TestGroupParallel. NI’s interpretation is different from the semantics described in the annotation. A schema change is not necessary.
Through further discussion the group identifies two different scenarios for parallel execution:
- Multiple tests that must be executed simultaneously, due to functional interdependencies. Jim provides an example - testing individual computers in a redundant flight control system.
- Multiple tests that can be executed simultaneously if resources are available; these tests are completely independent. For example, testing the ports of a multi-port Ethernet switch.
The group decided that describing the first scenario requires additional information such as loop cycles and acceptable time delays. This is outside the scope of the current effort. Users can create such a model if necessary using the extension mechanism. Consequently, TestGroupParallel should describe the second scenario.
Ion observes that the description of TestGroupUnspecifiedOrder should indicate that Test execution is serial.
AI - Ion: (1) Add to annotation of TestGroupUnspecifiedOrder: execution must be serial. (2) Change annotation of TestGroupParallel: execution can be parallel (depending on resource availability)
2. Terminology – The work “Requirements” is too generic
Ion points out that the parent elements (in this case, TesrResult and Parameter) provide the necessary context. Anand agrees. No change is necessary.
3. Users should be able to reference individual requirements from external document/database (which is referenced by element Documentation/Requirements/Document). This is for requirements traceability purposes.
AI - Ion to add attribute documentRequirementID of type nonBlankString to ActionType and TestGroupType. Annotation shouldindicate that the format of the ID will be specific to the requirements document / database that is referenced by element Documentation/Requirements/Document.
4. Problems referencing STD (1641) namespaces: (1) namespaces don’t have version; (s) some of the schemas have problems.
Instrument Description does not reference these workspaces explicitly(the element is actually in Common). The extension mechanism is used instead; this is described through Examples. Test Description should take the same approach.
AI: Ion to remove explicit references to 1641 namespaced. Change Examples to use the extension mechanism. See if we can reuse the type from Common that is used by the Instrument Description schema.
Anand points out that schema STDTSFLib.xsd has some problems that should be resolved.
AI - Anand to email the problems to Ion
AI - Ion to implement corrections
Discussion on status of 1641 schemas. The STDBSC schema is included now in the standard and thus is copyrighted; it is not published on IEEE web site. TAD could make schema publicly available as an interpretation. Mike will ask the IEEE if this is possible.
AI - Ion to make sure this schema STDTSFLib.xsd is published too.
Discussion on remaining work.
AI: Anand to finalize Candidate 6.
AI: Ion to regenerate and post standard draft.