Nxtest EO Presentation 22Nd July 2002
Total Page：16
File Type：pdf, Size：1020Kb
Minutes
ATML Group
24th –26th July
Present
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)
Meeting Contributions
Prior to the meeting the following contributions were submitted:
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
Tuesday 25th July
The meeting contributions were attributed to the following
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.
Shaded Use Cases are still under consideration and considered action items to be resolved by the next meeting
Design Goals
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.
ATML describes lots of little pieces if you ship this information; do it like this.
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.
ATML will have the minimal number of required/mandatory XML tags that will ensure consistency.
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.
Want one way to model wiring regardless of the connection model used from ATML
Use Cases
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.
2. Use Case – Teresa, need to be able to build description of all the paths, from ATML
3. Use Case – SteveW, Able to generate TRD for ATML. 4. Use Case – SteveW, Able to generate test program from ATML.
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
6. Use Case – SteveW, Support for LabView
7. Use Case – Tim, An OEM delivers test information in ATML(XML) then create a test program from that.
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.
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.
10. Use Case - Ion, Diagnostic Data
11. Use Case – Ion, Test Results (TDML) Uses TPS UUT and set of events.
12. Use Case – Ion, ITA Information
13. Use Case – Ion, Resource & switch information
14. Use Case – Ion, ATF Config Data
15. Use Case – Ion, Test Results summary information, separate or created.
16. Use Case – Ion, Another Test Results summary information
17. Use Case – Ion, describe instruments addresses in results
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
19. Use Case – Ion, support functional, and parallel (lots of signals applied at the same time)
20. Use Case – Ion, Discussion of Fault tress and Fault Tables ATML must support both.
21. Use Case – Ion,SteveW,Rob, want to record user inputted data.
22. Use Case – Ion, History of what was report to operator
23. Use Case – Ion, Database whole execution context of the test
24. Use Case – Ion, Results should have stimulus and response data
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
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.
30. Use Case – Ion, don’t define signal parameters using waveform characteristics, Levels of abstraction
31. Use Case – Ion, Non characteristic parameters i.e. impedance
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.
33. Use Case – Steve, Need to represent multi-wire connections and property on wires e.g. 10 gauge 12 gauge.
34. Use Case – Teresa, need to represent triggering signals and events and their connections, same as resource allocation.
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.
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
37. Want to use ISML within the IVISignal groups.
Friday 26 th July
ATML Objective
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.
ATML Coverage
The following table outline a brief description of each submission made and the data or test information in contains.
Common Naming Convention
How do we get a common set of names that describe specific data information items, and place those items under the ownership of the
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.
Normalisation activity to take place after we know all the common names in “reference architecture”
What we are doing is defining and naming data.
Date of Next Meeting
The next meeting is scheduled for Tuesday 10th – 12th Sept, St. Louis. Meeting Hotel to be advised. Actions List
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
Ion to supply two alternative “Reference Architectures” Action Ion Neag (Tyx)
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
Tim to add Design Goals and collate Use Cases into current draft requirement document and publish to list server. Action Tim
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