<p> Minutes</p><p>ATML Group</p><p>24th –26th July</p><p>Present</p><p>Tim Davis (NavAir) Ace Rossi (ATTi) Bob Fox (NavAir) Rob Spinner (ATTi) Chris Gorringe (Racal Instruments) Steve O’Donnell (Lockheed Martin) Jeff Hulett (Ventrex) Ion Neag (Tyx) Ronald C Salley (SSAI) John Ralph (Aeroflex) Teresa Lopes (Teradyne) Steve Wegener (Boeing) Patrick Miskivec (NavAir) Matt Cornish (Racal Instruments) Ron Taylor (Bae)</p><p>Meeting Contributions</p><p>Prior to the meeting the following contributions were submitted:</p><p>ATTi UUT Data (Test results) Stat Data (Configuration management/Logistic control) Boeing Test Program Architecture Instrument Specifications Configuration UUT/TP/TS Teradyne Test Station Configuration UUT Pin Map Instrument Model Test Results Tyx Signal Interface Test Requirement DML Racal Signal Schema Signal Capabilities</p><p>Tuesday 25th July</p><p>The meeting contributions were attributed to the following <ATML/> sections </p><p><ATML> Architecture (Boeing) <ISML> Instrument Specifications (Boeing) Instrument Model (Teradyne) Signal Capabilities (Racal) <TRML> Test Requirement (Tyx) Signal Schema (Racal) <TML> Test Program(Boeing) <TDML> UUT Data (Test results) When executed printed recorded UUT test descriptions (ATTi) Stat Data (Configuration management/Logistic control) Static data (ATTi) Test Results (Teradyne) <TSML> Test Station Configuration(Teradyne) Signal Interface(Tyx) <IAML> UUT Pin Map(Teradyne) <TCML> Is this a reference for other areas? Configuration UUT/TP/TS(Boeing) <DML> DML(Tyx)</p><p>Each submitter provided an over view of their submission highlighting what XML was being used for. For these descriptions several Design Goals and Use Cases were extracted, for submission into the ATML overall requirements document.</p><p>Shaded Use Cases are still under consideration and considered action items to be resolved by the next meeting</p><p>Design Goals</p><p>ATML formalises test information in XML. Not standardising the use of information. The use cases are examples to ensure we contain enough test information to meet todays requirements.</p><p>ATML describes lots of little pieces if you ship this information; do it like this.</p><p>Want to be able to create XML documents that make use of XML parts either by reference or inline, without need to duplicate schema definitions.</p><p>ATML will have the minimal number of required/mandatory XML tags that will ensure consistency. </p><p>DTML Only contains dynamic data that changes with each test run and enough static data to link to other ATML descriptions with the option to inline the static data.</p><p>Want one way to model wiring regardless of the connection model used from ATML</p><p>Use Cases</p><p>1. Use Case – Tim, A test diagram is a graphical representation of every wire path used during a test. It typically shows things such as UUT pins, cables, adapters, switches, and instrument parts. A test diagram becomes part of the documentation for the end-user.</p><p>2. Use Case – Teresa, need to be able to build description of all the paths, from ATML</p><p>3. Use Case – SteveW, Able to generate TRD for ATML. 4. Use Case – SteveW, Able to generate test program from ATML.</p><p>5. Use Case – Tim, Able to support legacy (Atlas, LabWindows/CVI etc.) test programs. The information in an ATML system should be able to support legacy systems</p><p>6. Use Case – SteveW, Support for LabView</p><p>7. Use Case – Tim, An OEM delivers test information in ATML(XML) then create a test program from that.</p><p>8. Use Case – Tim, A MTPSI file (Master Test Program Set Index) contains data which describes all of the hardware, software, and documentation necessary for testing a particular UUT. It becomes documentation for the end-user.</p><p>9. Use Case – Rob Spinner ATTi – To be able to store results data in a database. Such as to use ATML to capture all (ATTi) UUT Test Data, test information for UUTData, and STADData, as provided.</p><p>10. Use Case - Ion, Diagnostic Data</p><p>11. Use Case – Ion, Test Results (TDML) Uses TPS UUT and set of events. </p><p>12. Use Case – Ion, ITA Information <IAML></p><p>13. Use Case – Ion, Resource & switch information <ISML><TSML></p><p>14. Use Case – Ion, ATF Config Data <TSML></p><p>15. Use Case – Ion, Test Results summary information, separate or created.</p><p>16. Use Case – Ion, Another Test Results summary information</p><p>17. Use Case – Ion, describe instruments addresses in results</p><p>18. Use Case – Ion, Diagnostic Components of UUT, Ports of UUT, Failure modes. Input and output parameters and test Maintenance data, what do you want to replace. Maintenance data points to failure modes. Diagnostic Tree data, test sequence data </p><p>19. Use Case – Ion, support functional, and parallel (lots of signals applied at the same time)</p><p>20. Use Case – Ion, Discussion of Fault tress and Fault Tables ATML must support both.</p><p>21. Use Case – Ion,SteveW,Rob, want to record user inputted data.</p><p>22. Use Case – Ion, History of what was report to operator</p><p>23. Use Case – Ion, Database whole execution context of the test</p><p>24. Use Case – Ion, Results should have stimulus and response data</p><p>25. Use Case – Bob F, An XML Document should support multiple runs in a single document. 26. 27. Use Case – Teresa, Looping a test program a multiple times is recorded as a single test results</p><p>28. Use Case – Chris, to be able to define consistent user defined signals from signal building blocks so that signals are not limited to fixed set 29. Use Case – Chris, to be able to describe Instrument / device capabilities with generic signal capability that matches the signal building blocks so that user defined signals can be mapped to instrument/device capabilities.</p><p>30. Use Case – Ion, don’t define signal parameters using waveform characteristics, Levels of abstraction</p><p>31. Use Case – Ion, Non characteristic parameters i.e. impedance</p><p>32. Use Case – Teresa, the ‘switch’ is just another instruments. A switch is just an instrument that has no resources. Model the “From and To’s” for each instrument. </p><p>33. Use Case – Steve, Need to represent multi-wire connections and property on wires e.g. 10 gauge 12 gauge.</p><p>34. Use Case – Teresa, need to represent triggering signals and events and their connections, same as resource allocation.</p><p>35. Use Case – Teresa, able to add user specific data (attributes) as well as system data. There are going to be places were system specific data need s to be added such as keyword value pairs that don’t belong to schema. </p><p>36. Use Case – Teresa, don’t need to add own XML description of instruments, want to use the ones from … If ISML existed phone ion and for a small crate of beer he’ll do it all for us. Use same schema across all </p><p>37. Want to use ISML within the IVISignal groups. </p><p>Friday 26 th July</p><p>ATML Objective</p><p>The ATML initial development phase is to create a requirement specification and take existing test information standards from other bodies and industry and map their test information content into a common XML.</p><p>ATML Coverage</p><p>The following table outline a brief description of each submission made and the data or test information in contains.</p><p><ATML> Architecture (Boeing) <ISML> Instrument Specification Markup Language: Describes capability of instruments. May include manufacture name, model number, revision, signal capability by port (signal type, range, resolution, accuracy, etc) Instrument Specifications (Boeing) Boeing would use ISML as a way to standardize specifications for the acquisition of synthetic instrumentation. Boeing would use ISML to map Test Program stimulus and measurement information to capabilities offered by the Test Station. Instrument Model (Teradyne) A description of an instrument that includes Instrument I/O Test resources and their capabilities Switching Signal Capabilities (Racal) Specify instrument functionality in terms of the most basic signal functions the instrument provides (e.g. AM, sum) Signal Interface(Tyx) Instrument information Stimulus/measurement/monitoring capabilities in signal terms Controllable/measure able Range, resolution, precision Usage of instrument in systems Signal connectivity to instrument port Possibly internal connectivity and switching User interest (NavAir) Save the odd buck or two (1-800 ATML FOX) <TDML> Test Data Markup Language: Description of test results data. UUT Data (Test results) Static data to provide information to logistic management of the UUT system. Test Results (Teradyne) Test Results (Tyx) Diagnostic information Test results Execution events errors & warnings, operator actions. Fault information: diagnosed & actual faults Operators information UUT information TPS information ATE information We look forward to receiving input from AeroFlex on … (AeroFlex) <TRML> Test Requirements Markup Language: Description of tests required to verify health of a UUT. May include text description of each test, stimulus/response signals, pins, components, and callouts. Test Requirement (Tyx) Support legacy TRD formats. Signal Schema (Racal) Specify complex signals in terms of their most basic signal functions (e.g. sine, DC offset). DTI and Flow Chart(ATTi) Two way process for generating and documentation of test program. <TML> Test Markup Language: Description of UUT tests. May include test description, test group, test identification, stimulus/response signals, connections, evaluation limits, and operator instructions/actions. Test Program(Boeing) Boeing will use TML to assist with the re-host of legacy ATLAS programs to new or existing platforms. Boeing will use TML to data mine information from existing Test Program Sets to populate a database containing information about Stimulus and Measurement. Boeing would use TML as potential replacement to current Intermediate Pseudo Language (IPL) code used to execute a test program on station. We look forward to receiving input from Vektrex on … (Vektrex) Instrument Centric test program descriptions in XML We look forward to receiving input from AeroFlex on … (AeroFlex) <TSML>&<IAML> Test System Markup Language: Description of system paths between instrument ports and test system ports. Interface Adapter Markup Language: Description of paths between test system ports and UUT pins. Test Station Configuration(Teradyne) Test system description that identifies the instruments in the system and how they are physically interconnected. Stat Data (Configuration management/Logistic control) (ATTi) Static data to provide information to data management of the test station. UUT Pin Map(Teradyne) Connectivity and Signal Transmission Capabilities (CSTC) (Tyx) Connectivity and possibly signal transmission capabilities. <TCML> Test Configuration Markup Language: Describes all hardware and software required to test a UUT. Is this a reference for other areas? Configuration UUT/TP/TS(Boeing) Boeing will use TCML to construct information commonly found on a MTPSI card, that includes UUT information and requirement equipment to test the UUT. User interest (NavAir) <DML> Diagnostics. DML(Tyx) Fault tree test strategies: sequence & parametric data Links to UUT data, maintenance data & TPS data</p><p>Common Naming Convention</p><p>How do we get a common set of names that describe specific data information items, and place those items under the ownership of the <ATML/> sub-sections and show the inter relationships between them, with using a particular architecture to describe them?</p><p>Suggestion to achieve this through a glossary, which can be, supported through one or more reference architectures. ‘Reference architectures’ are examples or how it’s done, and are sophisticated use cases.</p><p>Normalisation activity to take place after we know all the common names in “reference architecture”</p><p>What we are doing is defining and naming data.</p><p>Date of Next Meeting</p><p>The next meeting is scheduled for Tuesday 10th – 12th Sept, St. Louis. Meeting Hotel to be advised. Actions List</p><p>Jeff to provide an overview of LabView and TestStand on how to produce test programs, so identify how these may effect the ATML requirements. Jeff to show how these programmes deal with these (ATML) issues. How might one map code within a VI to test information. I.e. COM or DLL support. Action Jeff H Ventrex</p><p>Ion to supply two alternative “Reference Architectures” Action Ion Neag (Tyx)</p><p>Each submitter to provide ”Reference Architectures” to support their ATML submission to identify what data are really being used. Glossary of terms with description, under each of the <ATML/> tag Name Description Picture (diagram) like SteveW’s picture showing where it fits in and what it references. <ATML/> Element Action All</p><p>Tim to add Design Goals and collate Use Cases into current draft requirement document and publish to list server. Action Tim</p><p>Steve to ensure that we get coffee, fruit, and breakfast at the next meeting, and take care of the social side during the evening. Action Steve O’Donnell</p>