RE: ATML Data Flow.ppt - somewhat private reply to Mike
Thanks, Mike, for the timely clarification. I wasn't sure of the status
of 1671 and so could only find the preliminary data flow diagram that we
developed previously. I did look on the TII web site but when I clicked
on the link to the Framework Doc I received this error:
************************************************************************
*************
Sorry, but the page you have requested
http://grouper.ieee.org/groups/scc20/tii/ATML/Working
Groups/Management/TII/IEEE 1671 ATML(2).doc
does not exist on this site.
You may want to type in a description of what you were looking for at
our search engine.
This software is maintained by IEEE Standards Systems/Network Staff.
************************************************************************
**************
Since no one else was jumping in I went ahead and sent data flow diagram
which was the next best description I could find on Groove.
_________________________________
Timothy J. Wilmering
'314.234.6781
*<mailto:timothy.j.wilmering@boeing.com>
> -----Original Message-----
> From: Seavey, Michael I. [mailto:michael.seavey@NGC.COM]
> Sent: Friday, August 26, 2005 10:24 AM
> To: stds-ai-estate@IEEE.ORG
> Subject: RE: ATML Data Flow.ppt
>
> All,
>
> Having read all of the traffic, I feel the need to clarify
> some things.
>
> 1) ATML is not defining, nor is a Architecture, ATML is not
> defining Services (as ABBET tried to do) ATML at the top
> level is a Framework.
> This Framework definition is a present being worked by
> the TII subcommittee under IEEE P1671. The latest Draft of
> the Framework document (IEEE P1671) is on the TII web-site.
> Chris Gorringe and Myself are the co-chairs of TII presently.
>
> 2)The ATML framework consists of the elements within the ATS,
> that have been defined to date, where a standardized
> description would allow interoperability of the information
> between elements. An Example would be an instruments
> capability, the XYY companies DMM capabilities description,
> if described in a consistent non proprietary mannor, allowing
> the development of tools/utilities permitting things like
> resource allocation (where the resource allocator is an
> implimentation)and if two different vendors provided ATML
> complient resource allocators, they could be interchanged
>
> ATML is defining what information needs to be included
> in the component, NOT what to do with the information. What
> to do with the information is an implimentation (by either
> the ATS integrator and/or tool developers)
>
> 3) ATML dot standards (Components) have associated XML
> Schemas. The standard and the schema together will define the
> requirements as they pertain to that component of ATML.
>
> 4)The P1671 draft standard has definitions of terms contained
> within it, as will each of the dot standards that are
> referenced by P1671. (The Test Results P1636.1 Draft
> presently has definitions that I have not heard anybody
> reference) The definition contained in the dot standard will
> define the term in the context of that component.
>
> 5) The Test Description component of ATML IS NOT a Test
> Program. Test Descriptions can be used, in an implimentation,
> to develop a test program in the language of choice. Test
> Descriptions will know nothing about the ATE the TPS
> hardware, etc. they are simply a description of what the UUT
> test is from the view of the UUT. Much discussion in the last
> 2 years have drawn the reccomendation that these are what
> will be used in the future to move between ATS's instead of
> moving the implimentation (Test Program)
>
>
> I'm Sure I have more, but would be glad to field any TII or
> ATML specific questions that anybody has
>
> Mike
>
>
> -----Original Message-----
> From: stds-ai-estate@ieee.org
> [mailto:stds-ai-estate@ieee.org] On Behalf Of Wilmering, Timothy J
> Sent: Thursday, August 25, 2005 4:22 PM
> To: stds-ai-estate@IEEE.ORG
> Subject: ATML Data Flow.ppt
>
> <<ATML Data Flow.ppt>>
> Brit et al -
>
> The standards work coming into TII (and some into DMC and
> TAD) is being
> driven by the ATML consortium, as I'm sure you know. While ATML has
> never fully defined a formal architecture (and I am not
> convinced that a formal architecture is what is needed),
> there have been numerous efforts to elucidate an overall
> vision that binds the work and provides a focus to the
> efforts. This has been successful to some degree. I have
> attached a diagram that represents one view of how ATML data
> flows. You may recognize the base diagram for this graphic.
>
> I would go so far as to say that ATML also strives to follow
> the KISS principle whenever possible, so partitioning schemes
> are kept fairly straightforward by design and sophistication
> of data representation approaches is for the most part kept
> simple where possible, in large part to improve accessibility
> and hopefully acceptance by its ultimate users.
>
> Perhaps someone else from ATML has a better vision
> representation, or something that show a more concrete
> architecture, but I think that this informal document should
> provide a pretty good idea of the overall ATML plan. I hope
> this helps...
>
> Tim
>