IEEE Std P1671 (ATML Overview and Architecture) Status and Review Mike Seavey October 2009

1. IEEE Std P1671 (ATML Overview and Architecture) Status and Review Mike Seavey October 2009

2. P1671 Schedule

3. Items to discuss • P1671 Draft 9 Review • Mike to go over the draft as it stands “today” • The Group to discuss and make recommendations on: • Test Results Comments • Cable Assembly Comments • Attributes in Capabilities • Extending WireLists • HardwareCommon • ATML Extension Mechanism clarification • Phase 1 Demo Instance Files (Mike) • Schemas (Mike)

4. Test Results Comments

5. Not all elements and attributes within the schema are annotated. I propose that all elements and attributes are annotated. • I propose that in order to be consistent with the latest revision of the IEEE P1636.2 MAI specification, the DMC should modify the test results schema to utilize the SIMICA common schema. This change would also have a benefit of not making IEEE P1636.1 dependent on the 1671 standard that is controlled by another working group. • <EnvironmentalData> • Currently the schema supports Environmental data under the TestResults/EnvironmentalData element, however, this data is typically collected while a test (or test group) is executing. Furthermore, there is often additional information available beyond the current five items (Altitude, Humidity, Shock, Temperature, and vibration) currently supported in the schema. I propose that <EnvironmentalData> be renamed to <Observables>, <Environmental> be renamed to <Observable>, <Observables> be moved under the <Test> complex type, and <Observable> be changed to support the following 4 attributes: name, value, type, and units. Moving the XML elements would allow Observable data to be correlated to either a <ResultSet>, a <TestGroup>, or a <Test>. I’m not against continuing to define the original five environmental items, however, there is a need to support additional items via at least an extension element.

6. The <Indictments> element below the root node provides no value since <Indictments> can only be generated as part of a <ResultSet>, <TestGroup>, or <Test>. I recommend removing the <TestResults><Indictments> element while leaving the <Indictments> element under the <TestResults> element. In addition, the current <Indictment> element does not support the following elements: <ReTestEntryPoint>, <RepairType> (i.e. “R”), and <RepairDescription> (i.e. “Remove and Replace”) which I recommend adding to the <Indictment> element. • The <WorkOrder> element below the root node should be replaced with the <Document> element that is in the latest IEEE 1636.1 MAI schema. This change would allow the schema to support a <DocumentControlNumber> (aka JCN), a <MaintenanceControlNumber> (aka MCN), a <MaintenanceLevel>, and a <Description>. • Similar to the IEEE 1636.2 MAI schema, the Test Results schema should define a root node container element for storing <TestResults> for multiple levels of maintenance that are correlated together. This would drive the creation of a <TestResults><TestResultsDocument> element in which the current <TestResults> element becomes the <TestResultsDocument> element.

7. <Extension> items • a. There is currently no location to store data related to the platform from which the test results were obtained. For example, Test Results might be generated form an E-2C aircraft. I recommend adding optional elements to store the platform name, platform model, and platform serial number. • The schema currently does not have a mechanism to use to store the site at which the Test Results were generated. I recommend creating a <Facility> element under the <TestResults> element which could be used to store the site/facility name along with other additional information. The new <Facility> element would be equivalent to the current MAI <MaintenanceFacility> element. • The schema currently does not have a mechanism to store the type of UUT (e.g. WRA, SRA, Aircraft, etc). I recommend adding a “qualifier” attribute to the <UUT> element to hold this information. • The schema currently does not have a mechanism to store Configuration Data for a UUT that is being tested. I recommend adding a <ConfigurationData> element beneath the <ResultSet> element. The <ConfigurationData> element would have an <Item> element like the one shown below. • <Item name="BoxOfpVersion" description="UUT OFP Version" value="113X234"/>

8. Cable Assembly Comments

9. In regards to putting ConnectorPins under Connectors, I really had to good reason for that other to stir up controversy.  I don't really think that it should be under there as opposed to ports, but since I couldn't use the Ports element anyway in my cable assembly schema, I thought I'd just go crazy and throw it under Connectors.  I'm going to read the explanation that was sent out the other day on the use of ports and connectors in the different types because that was a confusing issue for me. • I like the idea of like you did with DetailedIConnectorLocation.  I'm not sure what a good name for a new type that extends ConnectorLocation with an ItemDescription is.  ComponentConnectorLocation?  My first reaction is to have it in HC, but I'm not sure I can think of any reason you'd use it except in TestAdapter. • I also really like hc:Network to have an optional element of WireCharacteristics.  I think it fits. • Regarding components, I think that is a tricky area.  We only list items in components that we couldn't give an item description to elsewhere in the document?  In the example of defining a test adapter, that could lead to variance where some list connector pins in the components area while others use the proposed ComponentConnectorLocation type and give the itemDescription inline within the Port.  I'm not ready to make a suggestion on a solution.  :)