IEEE Std P1671-20XX
ATML Overview and Architecture Status and Review
22nd 23rd October 2009
Present
Chris Gorringe (co-chair)
Teresa Lopes (co-chair)
Tony Alwardt
Anand Jain
Dan Pleasant
David Sharone
Mike Seavey
Ron Taylor
Schedule
Action
Date
Mike to upload Draft 9 to IEEE
MEC, and Initiate a IEEE
Ballot constituency
Final review of P1671
Oct. 9, 2009
Started
(30 calendar days
to complete each)
Oct. 22-23
Started
(in Colorado)
Nov. 9, 2009
Mike to update Draft 9 with
any MEC comments and the
Colorado meeting input to
create Draft 10
Mike to start the IEEE Ballot
(using Draft 10)
IEEE Ballot Closes
Status
Nov. 16, 2009
Dec. 16, 2009
Mike to organize/run P1671
Jan. XX-YY, 2010
Ballot Resolution Group (BRG) (in Orlando)
starting in January 2010.
Agenda
l
l
l
l
The Group to discuss and make recommendations on:
l Test Results Comments
l Cable Assembly Comments
l Extending WireLists
l HardwareCommon
l ATML Extension Mechanism clarification
l Attributes in Capabilities
l Sharing Maintenance Information
l Open Floor Issues
P1671 Draft 9 Review
l Mike to go over the draft as it stands “today”
Phase 1 Demo Instance Files (Mike)
Schemas (Mike)
Rational
The revised 1671 standard has several additional common schemas added since the
release of the trial use standard. All the 1671 common schemas are required to
support colon elements and types across the various 1671 ‘dot’ standards. The
highlighted ‘bold’ table entries identify the common schemas defined by the 1671
standard.
Table 1 —IEEE-1671 family XML schema names and folder locations
Component
Defined
In:
XML Schema or XML
Instance Document Name
IEEE Download Site Folder (See Figure 5)
ATML Overview
and Architecture
This
document
None
None
Capabilities
Annex
B.5
Capabilities.xsd
1671-20XX1
InstrumentDescription.xsd
1671.2-2008
InstrumentInstance.xsd
1671.2-2008
Digitizer.xml
1671.2-2008
Instrument
Description
Maintenance
Information
Ports, Pins,
Connectors, and
Wire Lists
IEEE Std
1671.2
DownConverter.xml
1671.2-2008
SyntheticWaveformGenerator.xml
1671.2-2008
UpConverter.xml
1671.2-2008
Annex
B.67
MaintenanceInformation.xsd
1671-20XX
Annex
B.6
WireLists.xsd
1671-20XX
TestAdapterDescription.xsd
1671.5-2008
TestAdapterInstance.xsd
1671.5-2008
TestConfiguration.xsd
1671.4-2007
TestDescription.xsd
1671.1-2008
TestResults.xsd
TestResultsCollection.xsd
1671-20XX
1671-20XX
IEEE Std
1671.6
TestStationDescription.xsd
1671.6-2008
TestAdapterInstance.xsd
1671.6-2008
IEEE Std
1671.3
UUTDescription.xsd
1671.3-2007
UUTInstance.xsd
1671.3-2007
TestAdapter
IEEE Std
1671.5
Test Configuration
IEEE Std
1671.4
Test Description
Test Results
Test Station
UUT Description
IEEE Std
1671.1
Annex
B.4
locations and where each of the XML schema’s shall be located, is as defined in Table 5.
Table 2 —ATML Common element XML schema names and locations
Component
Defined XML Schema or XML Instance
in:
Document Name
IEEE Download Site Folder (See Figure 5)
Common
Annex B.1
Common.xsd
1671-20XX
Hardware
Common
Annex B.2
HardwareCommon.xsd
1671-20XX
TestEquipment.xsd
1671-20XX
Test Equipment Annex B.3
The “-20XX” will be replaced with the year this 1671 standard is approved by the IEEE-SA SASB. This note will then be
removed
1
These common schemas have come about through the continued development of
ATML through its the trial use ‘dot’ standards and are required to support common
features across the ATML family of standards.
The addition of TestResults, as an updated copy of the 1636.1-2007 standard, it so
a) Ensure we have a reference to allow continued use of the ATML Test
Results format after it expires in February 2010 and which allows the new
revised 2014 standard (as outlined by its PAR) to progress with alignment
with SIMICA Express Information Models without hindrance or reference
to the ATML family of standards. This supports the existing user and
produce tool base.
b) To incorporate updates to the Test Results schema, recommended from
various experienced use case and demonstrations in a timely and imminent
fashion
The addition of MaintenaceInformation allows existing information already
referenced in UUTinstance and Test Results to be defined from a common point. to
help support the repair descriptions in these described within these ‘dot’ standards.
The overlap between MAI and MaintenanceInformation, because of their common
histories, may in places be similar, and the XSD schema definition is very closely
related at this time. The significant difference is that the MaintenanceInformation
types can be used within the other ATML ‘dot’ standards as they all refer to the
ATML common schemas, Additionally the ATML standards will not be publishing
Express Information Models as that is the domain of the SIMICA family of standard.
Issues
Test Results Comments
We need to have the Test Results schema updates done by November 10, 2009.
All changes were made on top of the latest Test Results schema v2.10 (post
AutotestCon2009) and common schema used at AutoTestCon 2009.
1. The new version will be called Version 2.11, 2009-04.
2. TestResult/UUT/@UutType was deleted since you can specify the type in
the UUT Instance. Recommended by Anand, Teresa, Chris, and David.
3. UUT was made optional. We considering a collection of results, which
UUT they came from may not be off interest. Recommended by Chris
Gorringe.
4. The TestResults/ResultSet sequence of Test, TestGroup, or SessionAction
was changed from a multiplicity of 1 to infinity to 0 to infinity. Requested
by Anand because sometimes you start recording a sequence but
determined that there was nothing to run. This happens when a test
executive is following TestDescription. Sometimes you want to record the
fact that you want to run something and then their was nothing to do.
5. Add an optional testReferenceID attribute to the Action element., for
tracking to TestDescription. Requested by Anand.
6. Changed TestResult/WorkOrder to align with a common WorkOrder
enhancements put to be suggested in the new MAI XML schema.
Requested by Tony.
7. Moved the optional element EnvironmentalData under Action which
allows it to be specified on a ResultSet, TestGroup, and Test. The
Environmental element type was changed from c:Limit (which was
incorrect) to instead be c:NamedValue.
8. Deleted TestResults/Indictments. Updated the TestResult/Indictments
element to no longer inherit form c:ItemInstance since it does not have to
have a serial number. During this change the Indictment element
received a list of attributes that it requires. Requested by Tony and Dave.
9. Added a Data element under TestResults/TestProgram for storing test
program data items (e.g. configuration data). Requested by Anand.
10. We made the ID attribute of the Action element be an xs:ID instead of a
c:NonBlankString. Does everyone realize that this will require users to no
longer use a number for an ID? Everyone realizes this and agrees to the
change. This could be solved as simply as TR1, TG1, T1. Because of this I
temporally changed the ID back to a c:NonBlankString and recommend
that we should have the specification state that all ID’s must be unique
within an instance document.
11. What does the style guide say about using a sequence vs. all to specify the
order of child elements.
12. Updated TestResults/PreTestRepairs to be consistent to the type of
information that that will be collected when capturing this data during
testing.
13. Do we really still want to remove UUT/@UutType? Basically we always
expect people to test hardware and never software? You can specify this
on the underlying UUT description.
Test Results Notes
1. ID is what you link with and name is what you display.
Repairs in Test Results, UUT Instance and Maintenance Information
1. Test Results will store repairs that are made when running a test
program. This includes all repairs that are made which could include
repairs that did not actually repair the end unit. MAI will store the list of
repairs that contributed to fixing a UUT. In CASS terms, the test results
schema will hold repairs entered in pop-up repair forms and the repairs
entered on the end repair screen will be stored in an MAI instance
document. UUTInstance records the historic changes/repairs made to the
UUT
Cable Assembly Comments
The Cable assembly would be expected to be a TestAdaptor instance. The
comments received therefore are with reference to the testAtaptor and
associated common schemas TestEquipment, HardwareCommon and Common.
In addition has an impact in our description of pins ports and connectors.
Ron to reply back with amended example incorporating proposed changes
In general we agreed with many of the proposal made. However the specific use
case of having enough information to actually build a ITA was considered beyond
the scope of ATML. As such not all the information will be present in the
standard schemas, what this implies is that such a description would need to
utilise extensions to add tool specific information around a common frmat.
1) Putting ConnectorPins under Connectors (rather than Ports). There have
been several examples of misuse of ports whens try to describe physical
hardware of connectors and ports. The example of allows itemInstance
Connector pins to be placed under Ports both allows manufacturing part
number date tobe attributed to a single physical pin, but also helps
distinquish between pins and their use in ports.
a. Update common to allow ConnectorPins under connectors,
b. update pins ports connectors to describe such use
2) Update instance characteristics to indicate that depth and length are
regarded as equivalent when referring between hardware and cables
3) With TestAdaptor the te:Path is the place that hold path (and wire)
characteristics. Rather than use the hc:Network, the te:Path should have
been extended. At present the structure oes not lend its self to extensions
in the same way as hc:NetWork.
a. Update te:Path to allow xsi_type extensions for mapping extra
information to Paths /wires such as Wire Characteristics gauge
etc,.
4) MatingConnectType is confusing and has wrong description, it is suppose
to be the type of the other mating connector
a. tidy words on meaning of Mating connector
Extended WireLists
1) Page 417, Wire Lists section, Should not use TOWL term in this document, it is a specific
CASS test diagram use case. Consider using the term test diagram data or data to support test
diagrams. Also delete TOWL from definitions page.
“The ATML WireList XML schema supports the description of the interconnections between ATML
components utilized within an particular ATS implementation. These interconnections are commonly
referred to as test oriented wire lists (TOWLs)”.
2) Page 417, Delete MilStd1553, or add MilStd1553 Cable
3)
Page 425 In Utilized Standards delete “are being balloted, or are in the IEEE balloting
process.” or change to “This example is based around ATML family standards that have
been published, were being balloted, or were in the IEEE balloting process at the time of this
demonstration.”
4) Pages 432, 33, Change to adapter, “ATML test adaptor description XML instance
documents.”
5) Page 36 Identifys three common schemas, should WireLists schema be added ?
6) Page 37 add the word “to”, “a means to”, “An ATML framework may require a means
describe how instruments,”
7)
Page 39 I don’t think we specifically support Interlocks and Temperature Sensing in Test
Station Description and Instance. “This description includes the physical and electrical
characteristics, the paths between test system ports and the instrument’s, tolerances and
accuracy of the test station, test station identification information such as part number, serial
number, nomenclature, location; status information such as calibration data, dates, and self
test status; operational history, such as system up-time, external interfaces, safety information
such as interlocks, temperature sensing; power requirements controller definitions, etc”
8) Page 39 Also consider changing “system up time” to “power on time” to reflect the element
and attribute names.
9)
Page 38 UUT Description does not have capabilities so there are no signal descriptions. “Any
signal descriptions within a UUT description shall be represented utilizing IEEE Std 1641TM
(STD).”
10) Consider using Cable instead of Cable Set in Test Adapter text. Since a Test Adapter
description typically would describe only one cable.
Common & Hardware Common
Comments on the latest Common schema
1. The following items are not annotated in the schema: PortDirection,
PortType, Connector, ConnectorLocation, Document, DocumentList,
EnvironmentalElements, EnvironmentalRequirements,
HardwareInstance, IdentificationNumber, MailingAddress,
ManufacturerData, NamedValue, PhysicalInterface, Port. There are also
many other sub attributes/elements that are not annotated.
Annotate everything in the schema.
2. The ATML team have developed a tool for aligning xsd comments with the
standard or standard annotations with the schemas; we’ll align all
schemas with the words in the standard prior to submitting schemas.
Common Schema Notes
1. You only have to use the common Value or NameValue when you have
values that could be of many types. If you always have the same value
type (all strings, all doubles, etc) you can create your own simplified name
value type.
a. Add some words to Limit to prefer datum types to be the same
value
2. Is there a reason why a xsi:type=”c:string” forces a Datatum type have a
c:Value element whereas all other items have the value specified as an
attribute. The answer is yes. String items need to be an element to
handle new line characters and other string formatting items.
Note CCG could we want to both forms as mutually exclusive?
3. We should make the Data element of type c:NamedValue instead of
c:Value. When would you have a value and not have a name for it? No
you can specify this in the c:Value/Collection element.
4. There is a need to provide a case insensitive comparison for stings
a. define CIEQ, CINE to our comparison table for performing Case
Insensitive comparison for strings
Common Schema Ions Comments
1. Allow multiple Connector pins for items such as
PowerSpecifications/AC/Connector
2. Clarify ID between between test results and test descriptions (see
testDescriptionID)
a. DescriptionDocument Reference when to use uuid and id – Add
words to describe difference.
UUID is an sequence of changes that represent a non breaking
change
b. ID is an instance ID within the referencing document. e.g. two DI’s
for to DMM that refer to the same description.
3. In test description needed to extend connector can we add this to
hardware common – Add to common
Common Schema Observations
1. #Inf is only supported by reals and not other xsi:datatypes e.g. Int
2. ATML does not allow Negative array indexs (this is by design)
3. Comparison on Limits. ATML does allow mutually exclusive or repeated
limits to be defined e.g. >3& >=6
ATML Extensions mechanism clarified
How to extend schemas
1. All extensions shall be defined within their own unique namespace
2. Extensions can use the common Extension element or define amended
types for use with xsi:type
3. The recommendation written into the ATML 1671 specification states you
should pass instance documents around that adhere to the approval
ATML standard. You will then define your own schema that only
contains elements that exist inside the extension elements. To external
publishers you would give them the ATML schema and one or more
additional schema’s that define what goes in the extension in order to
interoperate with your system. This greatly simplifies how we are doing
extensions. You can also specify multiple schema files within an XML
instance document that it adheres to. Teresa sent me a sample of this on
10/22/09 in my e-mail.
Attributes In Capabilities
At present use of Capabilities has resulted in TSF descriptions being created for
the sole purpose of describing the interface properties to the resource. These
TSFs have not been shared by used only to define such attributes. The issue is
that would it be better to describe such interface attributes with Capabilities.
The first point is that where as interface attributes may be relevant for a specific
Capability/resource pairing, they are not definitive to the specific Capability.
Since Capabilities are shared (potentially) across resources, there is no
guarantee that their interface properties would be similar. As such binding such
attributes with the Capability is not the right place.
As an alternative the Capability map provides the resource to Capability binding,
as such using an extension call here to add additional (proprietary) information)
where the Capability is bound to the Resource would be more generic and allow
an application to use the same place for the information..
There was no interest to have ATML define such an extension although all
examples are welcome.
Shared Maintenance Information
1. There should only be one root element.
2. Simply referring to test results. Use a document reference and an ID
attribute and no longer use xpath.
3. I need to send Teresa a list of elements I would like added to common that
are shared between test results and mai. WorkOrder, etc. Then the 1671
test results and mai schemas will depend on them.
When we work on UUT Instance we will work to put on putting the maintenance
history in it. UUT description could depend on complex types in MAI. UUT
Instance will have a collection of MAI documents (reference or inline).
Create a new schema called TestResultsCollection.xsd that adds the collection
element of TestResult items. We will also have the ability to extend the
collection.
Instead of creating a platform we can use the UUT instance to store the platform
data. Teresa is going to send me an example of how you can extend a schema
element based on an inherited type (xsi:type)Create a Site for storing the
location. A generic value.
Action Responsibilities
1. Updates to Common, HardwareCommon and TestEquipment. including
adding WorkOrder (supplied from TonyA) and adding pin connector into
common schema- Teresa
2. Example of ‘proper use of’ extensibility for 1671 standard - Anand
3. Updated Pins Ports & Connectors with update words on pin under connectors,
matingConnector Type - DanP
4. wirelist comments - RonT
5. Fold changes into 1671 TestResults - MikeS
6. ATML update Examples with new schemas -ChrisG
7. Snippets Examples updated to new schemas - Teresa
8. Provide Cable Assembly example back to Gabe Goffman with updated
schemas – RonT/ChrisG
9. Test Results Update – TonyA
10. Maintenance Information - TonyA
11. More than one pin in connector as discussed with MSkeiber, this may be
already addressed by other changes - MikeS
12. Other Actions - MikeS