Page1 Framework Working Group 2007 ATML Use cases Use of ATML by external agencies is gathering momentum.

Slides:



Advertisements
Similar presentations
ATML Completion Status – What Happens Next
Advertisements

ATML Readiness For Use Phase II. Phase II Readiness For Use The ATML: Phase II will build on the Core phases, adding additional ATML components and features.
Traditional Experience Rating at Suva - description and experiences since 2003 OSHA-Workshop, 26 and 27 May 2010, Rome Dr. Remo Molinaro, Suva, Switzerland.
PAGE1 S CHOOL M ANAGEMENT S YSTEM BACK NEXT EXIT Deltasoft STUDENT INFORMATION SYSTEM Student Information System School.
1 UK MOD Policy and ATML Malcolm Brown UK MoD Support Policy Team Automatic Test Systems AutoTestCon Orlando Florida Sept 2010.
PAGE1 S CHOOL M ANAGEMENT S YSTEM BACK NEXT EXIT Deltasoft  STUDENT EXAMINATION SYSTEM Student Examination System School.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 12 Slide 1 Distributed Systems Design 2.
Inc. User Requirements Presentation DoD Automatic Test Systems Michael Malesich DoD ATS R&D IPT Chair.
© 2004 Visible Systems Corporation. All rights reserved. 1 (800) 6VISIBLE Holistic View of the Enterprise Business Development Operations.
Network Management Overview IACT 918 July 2004 Gene Awyzio SITACS University of Wollongong.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
Software Reuse Building software from reusable components Objectives
Supervised by Prof. LYU, Rung Tsong Michael Department of Computer Science & Engineering The Chinese University of Hong Kong Prepared by: Chan Pik Wah,
1 Reusability and Portability Xiaojun Qi. 2 Reuse Concepts Reuse is the use of components of one product to facilitate the development of a different.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Course Instructor: Aisha Azeem
Community Manager A Dynamic Collaboration Solution on Heterogeneous Environment Hyeonsook Kim  2006 CUS. All rights reserved.
Web Application Architecture: multi-tier (2-tier, 3-tier) & mvc
ATS Framework Working Group Overview and Status Mike Malesich 13 March 2006.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 18 Slide 1 Software Reuse.
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Design with Reuse l Building software from reusable components.
LXI Standard – Current and Future David Owen – Pickering Interfaces TC Chair LXI Consortium LXI – “It’s About Your Time”
Distributed Software Engineering To explain the advantages and disadvantages of different distributed systems architectures To discuss client-server and.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
What is Enterprise Architecture?
“Enhancing Reuse with Information Hiding” ITT Proceedings of the Workshop on Reusability in Programming, 1983 Reprinted in Software Reusability, Volume.
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
Mobile Topic Maps for e-Learning John McDonald & Darina Dicheva Intelligent Information Systems Group Computer Science Department Winston-Salem State University,
Software Requirements Engineering CSE 305 Lecture-2.
111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
TitleIEEE Standard for Mostly RESTful Orchestration Interface Protocol (mREST) for Orchestrating Software-Controlled Assets via Web Services ScopeThe mREST.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
R R R 1 Frameworks III Practical Issues. R R R 2 How to use Application Frameworks Application developed with Framework has 3 parts: –framework –concrete.
Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems Slide 1 SCC20 Liaison Report Dr. John W. Sheppard CS SAB Meeting November.
ATML Status Oct 2005 An overview of the ATML activity in the ATML focus group and as part of the IEEE SCC20 sub-committee.
Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems Slide 1 SCC20 Liaison Report Dr. John W. Sheppard CS SAB Meeting November.
Interoperable marine monitoring systems Toma Daniel Mihai Technical University of Catalonia Mentor: Tom O’Reilly MBARI 2010.
Software Acquisition and Project Management Lesson I: Introduction.
RAI Information Brief Prospective from the RAI Working Group.
IEEE1641 Signal & Test Definition A Quick Tutorial Chris Gorringe.
Phase II Demonstration Overviews ATML. Demo Goals Readiness For Use In last year’s demo we showed the feasibility of an end-to-end ATML-based software.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
© 2013, published by Flat World Knowledge Chapter 10 Understanding Software: A Primer for Managers 10-1.
Foundations of Information Systems in Business. System ® System  A system is an interrelated set of business procedures used within one business unit.
Object Oriented Analysis and Design 1 Chapter 9 From Design to Implementation  Implementation Model  Forward, Reverse, and Round-Trip Engineering  Mapping.
Enterprise Engineering Directorate (EE)
Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems Slide 1 SCC20 Liaison Report Dr. John W. Sheppard May
Software Engineering Introduction.
GRID ANATOMY Advanced Computing Concepts – Dr. Emmanuel Pilli.
1 TestDescription Schema Implementation in SAMe ATE ATML Meeting – Boston, MA October 2006.
OL ILDLOEM BIT/Integrated Diagnostics Test / Maintenance Feedback ARGCS ACTD CONOPS Weapon System ECP Data flow Coalition Team Concept Wide.
ATML Status Jan 2006 Issue 6 An overview of the ATML activity in the ATML focus group and as part of the IEEE SCC20 sub-committee.
Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems Slide 1 SCC20 Liaison Report Dr. John W. Sheppard CS SAB Meeting June.
1 ATML Status January 2008 Issue 14 An overview of the ATML activity in the ATML focus group and as part of the IEEE SCC20 sub-committees.
Distributed Systems Architectures. Topics covered l Client-server architectures l Distributed object architectures l Inter-organisational computing.
ATML Status January 2007 Issue 9
IEEE SCC20 Standards Status
September 14, 2010 Mukund Modi NAVAIR Kevin Masur Joe Stanco
ATML Status April 2006 Issue 7
IEEE SCC20 Standards Status
ATML Status July 2007 Issue 11 An overview of the ATML activity in the ATML focus group and as part of the IEEE SCC20 sub-committees.
ATML ATML’s mission is to define a collection of XML-based schemas and services that allows ATE and test information to be exchanged in a common format.
Use of ATML in Navy ATS.
Chapter 7 –Implementation Issues
Presentation transcript:

Page1 Framework Working Group 2007 ATML Use cases Use of ATML by external agencies is gathering momentum

Page2 Framework Working Group 2007 Agilent Instrument Database Performing an independent evaluation into using the ATML instrument description and ATML capability to distribute their instrument information. This is important because, if successful, there will be a lot of information in the ATML format – that will generate a lot of user based feed back on our trial use standard(s) Dan Pleasants presentation Instrument Description Working Group Meeting Tuesday Morning 9:00

Page3 Framework Working Group 2007 Synthetic Instrument defined using ATML Synthetic Instrument Working Group has defined a general architecture for synthetic instruments. Each component that makes up the synthetic instrument needs both software and hardware interchangability. ATML Instrument Description has been chosen as the format to represent the description of the hardware specifications for the following components: Arbitrary Waveform Generator Digitizer Down Converter Up Converter IVI Drivers have been selected for the software driver interchange format.

Page4 Framework Working Group 2007 LXI Consortium Investigating using ATML Capabilities as part of LXI Discovery

Page5 Framework Working Group 2007 MoD Open System Architecture Approach The MoD currently have a policy for ATS to use the IEEE 1641 signal modelling standard. Looking to standardise a common Open System Architecture approach This process is expected to make heavy use of the ATML standards

Page6 Framework Working Group 2007 Proposed Common OSA Standards High degree of obsolescence coupled with a lack of commonality has resulted in: High in-service support costs Relatively low utilisation of test platforms A common open standard is therefore vital to overcome these concerns. This must be encompassed within the common GPATE with the technology to achieve this capability.

Page7 Framework Working Group 2007 Common Core ATS Architecture Computer Instrumentation Unit Under Test Hardware Software Operating System Test Program Test Head Common Core Test Results

Page8 Framework Working Group 2007 Common Core ATS Architecture Goal TPS Reuse & ATS Interoperability TPS Platform 1 Platform 2 Platform 3

Page9 Framework Working Group 2007 Signal Interface MoD - Signal Policy with ATML components DRV Test Results Common Use Standard Signal Library Signal Program ATML Capability Test Description

DoD Framework Working Group Page10 Framework Working Group 2007 IEEE Std and the DoD Automatic Test System Framework Elements Framework Members: Michael Malesich; Jennifer Fetherman; Chris Gorringe; Bob Fox; Tom Gaudette; Ron Taylors; Hugh Pritchett; John Sheppard; Joe Stanco; Ken Fox; Mukund Modi; Pat Kalgren

Page11 Framework Working Group 2007 Instrument Interface Layer Future TPS development - ATML Test Information Using Signal Models Enhancing Reusability Test Description Test Program Generation Common Use Signal Library ATE Capabilities Instrument Description Test Station Description Test Adaptor Test Program Instrument Signal Mappings RI3152Ag38152aElgar Elements ATML Elements Implementation UUT Description ATS Software Test Results

Page12 Framework Working Group 2007 REQUIRED Common Use Standard Signal Library TSF Development We need to develop standard Signal libraries to capture the test domain knowledge of what signals are required. CASS ATLAS Signal Library Already modelled certain signals and measurements in 1641 (but never completed as TSFs) SIWG measurement science & signals methods ARGCS ATLAS Signal Libraries Train users in using the common signal libraries in their field of operation rather than the user needing to know how specific signal are implemented. TPS projects and field test engineers would then use these TSF signal definitions as reusable components, rather than continually build there own up from scratch Provide a solid foundation for a standard common use signal library Ability to use additional interchangeable Signal Libraries though TSFs New TSFs can be added into the standard at subsequent revisions

Page13 Framework Working Group 2007 Instrument Interface Layer Future TPS development - ATML Test Information Using Signal Models Enhancing Reusability Test Description Test Program Generation Common Use Signal Library ATE Capabilities Instrument Description Test Station Description Test Adaptor Test Program Instrument Signal Mappings RI3152Ag38152aElgar Elements ATML Elements Implementation UUT Description ATS Software Test Results

Page14 Framework Working Group 2007 Instrument Interface Layer Future TPS development - ATML Test Information Using Signal Models Enhancing Reusability TPD UTR Test Program Generation UTR, UDI ATE Capabilities IFP TSFP AFP Test Program Instrument Signal Mappings DRV Instrument Drivers 1641 Elements ATML Elements Implementation UDI ATS Software MTD

Page15 Framework Working Group 2007 DoD ATS Technical Framework Relationships LEGEND Resource or generic Level Signal or independent Level UUT Test Level Instrument Functional & Parametric Data IFP Adapter Functional & Parametric Data AFP Instrument Communication Manager ICM Instrument Driver DRV System Framework FRM Resource Management Services RMS Diagnostic Services DIAS Digital Test Format DTF Test Program Documentation TPD Multimedia Formats MMF Test Station Functional & Parametric Data TSFP Maintenance Data & Services MTD Built In Test Data BTD Product Design Data PDD UUT Test Requirements UTR ATE Software Switching & Wiring Instruments Resource Adapter Interface RAI Test Program Diagnostics Diagnostic Data DIAD Test Adapter Interface or hardware Level UUT Device Interfaces UDI (Hardware) UUT Device Interfaces UDI (Software) Instrument or device Level Information Services or API Data Networking NET (TCP/IP) Computer to External Env. CXE (TCP/IP) Data/ Distributed Network DNE Run Time Services RTS Common Test Interface CTI Master Conformance Index MCI

Page16 Framework Working Group 2007 DoD ATS Technical Framework ATML Relationships Instrument Functional & Parametric Data IFP Adapter Functional & Parametric Data AFP Test Program Documentation TPD Test Station Functional & Parametric Data TSFP Maintenance Data & Services MTD UUT Test Requirements UTR ATE Software Switching & Wiring Instruments Test Program Diagnostics Test Adapter UUT Device Interfaces UDI (Software) Run Time Services RTS Master Conformance Index MCI Resource Adapter Interface RAI Product Design Data PDD Resource Management Services RMS

Page17 Framework Working Group 2007 DoD ATS Technical Framework SCC20 Relationships Instrument Functional & Parametric Data IFP Adapter Functional & Parametric Data AFP Test Program Documentation TPD Test Station Functional & Parametric Data TSFP Maintenance Data & Services MTD UUT Test Requirements UTR ATE Software Switching & Wiring Instruments Test Program Diagnostics Test Adapter UUT Device Interfaces UDI (Software) Run Time Services RTS Master Conformance Index MCI Resource Adapter Interface RAI Product Design Data PDD Resource Management Services RMS Diagnostic Services DIAS Digital Test Format DTF Diagnostic Data DIAD Common Test Interface CTI

Page18 Framework Working Group 2007 Fin The Community wants our ATML standards They are a significant part of both the Mod and DoD future solutions There is a commercial advantage in using ATML We need to get them out and balloted Getting ATML!

Page19 Framework Working Group 2007 No - I really have finished

Page20 Framework Working Group 2007 RoadMap DoD - ATML Support Interfaces ATS Software ATML Capability Test Description UUT Description Instrument Description Test Station Test Adapter Test Results Common Use Standard Signal Library Signal Test Program DRV

Page21 Framework Working Group 2007 Signal Interface RoadMap MoD - Signal Policy DRV Test Results Common Use Standard Signal Library Signal Program ATML Capability Test Description

Page22 Framework Working Group 2007 Station Software Signal Interface RoadMap Coalition Open Architecture DRV ATML Capability Test Description UUT Description Instrument Description Test Station Test Adapter Test Results Common Use Standard Signal Library Signal Program

Page23 Framework Working Group 2007 Signal Modelling and the Framework The term signal modeling is simply defining signals through models. A signal model includes signal sources, signal conditioning, signal based measurement, digital, communications & busses, events, timing and even locations or combination of them. The model is an executable specification that provide a means to define both behavior and interface parameters, and utilize both composition and hierarchy to allow building increasingly complex signal definitions, as reusable components Regardless of the complexity of the signal, because they define behavior, signal models represent an ideal component of test requirement interchange. Signal modeling can have a positive impact on several DoD (and MoD) objectives Improve instrument Interchange Make ATE more adaptable with no penalty to requirements Faster technology insertion Improve TPS rehost Improve TPS interoperability Use model based programming techniques Modernize test programming environment Capture design to test data

Page24 Framework Working Group 2007 Framework Elements & ATML UTR (UUT Test Requirements) IEEE 1641 Signal Libraries TPD (Test Program Documentation) Test Description (ATML) IFP, AFP, TSFP (Instrument Functional & parametric Information) Signal Capability ATML and IEEE 1641 UDI (UUT Device Interfaces) Signal Libraries (1641 TSFs) MTD (Maintenance Test Data) IEEE ATML Test Results RMS (Resource Management Services) IEEE Std – Annex C Signal Resource Manager RTS (Runtime Services) IEEE Std Annex C RAI (Resource Adaptor Interface) IEEE Std New Annex to Firm up UUT requirements and extract Connection & Timing to top level MCI (Master Conformance Index) IEEE Std – Annex C Signal Resource Manager PDD (Product Design Data) UUT Description (ATML)