DoDDoD
Automatic Test SystemsAutomatic Test Systems
Past, Present, FuturePast, Present, Future
Bill RossBill RossAssistant Director, DoD ATS Executive Agent Office
2
PastPast
• 5+ years ago, the Automatic Test Systems commodity was flagged for DoD-wide management– A DoD Executive Agent for Automatic Test Systems was
established (April ‘94)
• Why??– Many weapon system programs were independently developing
and fielding ATS• Redundant ATE development efforts• Many different ATE requiring In-Service Engineering
– High cost driver- $51B spent on ATS during the ‘80s
3
Two Primary DoD ATS GoalsTwo Primary DoD ATS Goals(April ‘94)(April ‘94)
1. Reduce total cost of ownership of DoD ATS
2. Provide greater flexibility to the warfighter through Joint Services interoperable ATS
4
DoD ATS PolicyDoD ATS Policy(March ‘96)(March ‘96)
• DoD Acquisition Regulation 5000.2, ATS-specific acquisition policy
– Minimize unique types of DoD ATS
– Use DoD ATS Families or COTS with defined critical elements
– ATS selections shall be the most cost-beneficial to the DoD over the system life cycle
• DoD Joint Technical Architecture (JTA), ATS-specific technical architecture design policy
– ATS Technical Architecture Subdomain Annex
– “Mandates” critical architecture elements
5
DoD ATS OrganizationDoD ATS Organization
DoD Executive Agentfor
Automatic Test Systems
Assistant Secretary of the Navy (RDA) Dr. Buchanan
NAVAIRSYSCOM PMA260 Capt Fletcher Bill Ross
Joint Service ATS Leaders Capt Fletcher, USN Col Nodine - USAF Col Hamilton - Army Col Gebhard - SOCOM LCol Juliano - USMC
DoD Automatic Test SystemsExecutive Agent Office
DoD Automatic Test Systems
Management Board
6
ATS Management Board OrganizationATS Management Board Organization
ATS EA OfficeNavy (PMA-260)
Capt Fletcher
USAF RepCol Nodine
Army RepCol Hamilton
USMC RepLCol Juliano
SOCOM RepCol Gebhard
EA Office Asst Dir(PMA-260ATS)
Bill Ross
USAF CoordAlton Jenkins
Army CoordDawn Gratz
USMC CoordMike Heilman
SOCOM CoordLCOL Ragland
IPTs/Working Groups
7
Active IPTs and Working GroupsActive IPTs and Working Groups
Leader
• Investment Planning IPT Will Broadus
• Program Analysis IPT Jim Deffler
• TPS Standardization IPT Ed Holland
• ATS Research and Development IPT (ARI) Mike Malesich
• ATS Modernization IPT Dawn GratzJohn Rosenwald
• NxTest Working Group Bill Birurakis
8
ProductsProductshttp://dodats.osd.milhttp://dodats.osd.mil
• DoD ATS Master Plan– Policies, procedures and DOD/Service ATS plans
• DoD ATS Handbook– ATS acquisition in “just plain English”
• DoD ATS Selection Process Guide– CBA models– Technical, cost data– Procedures
• DoD TPS Performance Specification– Replaces Mil-Std-2077
• DoD ATS Architecture Guide– How to implement the DoD ATS architecture
9
Steering a CourseSteering a Course
Past
Present
Near Future
• Each program did their own thing
• Selecting standard DoD ATS Families • Defining a commercial-based standard open system architecture
• Evolve the open system architecture• Services cooperatively define and implement the common next generation DoD ATS
10
Steering a CourseSteering a Course
Past
Present
Near Future
• Each program did their own thing
• Selecting standard DoD ATS Families • Defining a commercial-based standard open system architecture
• Evolve the open system architecture• Services cooperatively define and implement the common next generation DoD ATS
DoD NxTest
11
NxTest VisionNxTest Vision
• Services cooperatively Define a single DoD test environment aimed at: – reducing total ownership cost of DoD ATS, and – effecting interoperability of the Services’ ATS functions
• And, Services cooperatively Implement this single test environment in a new class of commercial-based ATS characterized by three main critical factors:– Fully embraces the “mandated” DoD JTA requirements and other
ARI “emerging” requirements– Gracefully applies legacy test programs – Inserts technology that significantly reduces the amount of
hardware requiring support
12
DoD NxTestDoD NxTest
• What DoD Expects
– Open system based on the DoD JTA “mandated” and ARI “emerging” requirements
– Interoperable ATS• More easily share TPSs and ATE• Share diagnostics infrastructure• Multiple run-time systems/languages
– Embrace existing ATS environments - graceful TPS rehosting
– 2/3 reduction in the amount of ATE hardware to acquire and support
– Ease future ATE modernization
– Parallel test processing and multi-threading to allow true “functional” testing
– Better integrated with diagnostics systems and information (network centric)• Design data• Platform diagnostics data• Historical maintenance data
– Improved TPS development environments
13
DoD NxTest InitiatedDoD NxTest Initiated
• NxTest approach briefed to the ATS Management Board - Oct ‘98– Highlighted that each of the Services has aging ATS– Recommended cooperatively define the future DoD ATS solution– AMB principals concurred
• Joint Service DoD NxTest Working Group established
• Industry briefing held March ‘99
• NxTest Working Group:– Defining future test & operational requirements– Assessing available technology
14
DoD NxTest PlanDoD NxTest Plan
• Technology Demonstrations 1996 - 2003
• Prototype 2001 - 2004
• TPS Regression Testing 2002 - 2006
• Pre-Production 2004 - 2006
• Production 2006 -
15
DoD NxTest BenefitsDoD NxTest Benefits
1. “Reduce total cost of ownership of DoD ATS”
– Technology that significantly reduces hardware, thereby reducing operating and support costs
– Open system architecture that allows economical technology insertion for meeting future requirements and resolving obsolescence issues
2. “Provide greater flexibility to the warfighter through Joint Services interoperable ATS”
– Services single test environment means inherent ATS interoperable hardware and software elements
. . . . while improving the quality of test and diagnostics
16
DoD Joint Technical ArchitectureDoD Joint Technical Architecturehttp://www-jta.itsi.disa.mil/http://www-jta.itsi.disa.mil/
JTA v 3.0
Information Processing StandardsInformation Transfer StandardsInformation Modeling StandardsHuman-Computer Interface StandardsInformation Systems Security Standards
• Airborne Reconnaissance• Command & Control• Communication• Intelligence• Information Warfare• Surveillance/Recon • Automatic Test Systems
• Acquisition• Finance/Accounting• HR Management• Legal• Logistics/Material• Medical
• Aviation• Ground Vehicle• Missile Defense• Munition Systems• Soldier Systems• Missile• Ship Systems• Space Vehicles
Modeling & SimulationDomain
C4ISRDomain
Combat SupportDomain
Weapon SystemsDomain
17
Joint Technical ArchitectureJoint Technical Architecture
• Objective– Provide DoD systems with the basis for seamless interoperability– Define the service areas, interfaces and standards applicable to all
DoD systems
• Policy– JTA is mandated for the acquisition of new or improved systems
throughout DoD
18
JTA ATS Subdomain AnnexJTA ATS Subdomain Annex
• ATS Architecture - 22 critical elements
• Current JTA - “mandated” requirements:– Interfaces
• Instrument Driver API Standards VPP-3.2• Digital Test Data Formats IEEE-1445• Data Networking Standards TCP/IP• Instrument Communication Manager Standards VPP-4.3• Computer to External Environments TCP/IP• System Framework Standards VPP-2
– Reference Models• Hardware Interface Model• Software Models (Runtime View and TPS Development View)
– Rules• Test Program to Operating System Calls
19
ARI, JTA, NxTest ArchitectureARI, JTA, NxTest Architecture
NxTestNxTest
Commercial StandardATS Open SystemArchitecture
“Mandated” & “Emerging”Critical ATSElements
• Commercial standard • ARI (Ind/Gov’t)• Continuously evolving
• DoD JTA• Updated annually
Based on demonstrated commercial standards
• Joint Services NxTest Working Group• Implementation may take many forms
Based on: - Test requirements - Technical innovation - Open system architecture requirements
System AcquisitionSystem AcquisitionDoD ATS Generic Technical ArchitectureDoD ATS Generic Technical Architecturedemonstrated success
20
Test & Diagnostics ConsortiumTest & Diagnostics Consortium www.test-diagnostics.orgwww.test-diagnostics.org
• AUTOTESTCON ‘98 Plenary topic - positive response
• Drafted essential documents – Business Plan, By-Laws, Operating Procedures
• Identified potential initiatives
• Established access points– Web site, e-mail, telephone line, mailing address
• Major benefits – Partnering/leveraging investments– Rapid development and implementations
• Membership Call issued recently
21
Integrated DiagnosticsIntegrated Diagnostics
• ATS EAO involved in several OSD Integrated Diagnostics studies and demonstrations
– Factory to Field Study - Defined an ATS open architecture that facilitates leveraging investments in test software across multiple test platforms
– ID Open System Approach Study - Recommended an open system architecture for Integrated Diagnostics
– Diagnostics for Acquisition Study - Can existing support infrastructure be used for performance testing commercial electronics replacements?
22
Integrated Diagnostics (con’t)Integrated Diagnostics (con’t)
• NDIA Systems Engineering Committee has established an Integrated Diagnostics subcommittee
– Howard Savage, IDA, & Steve Hutti, Boeing, Co-chair
– Provides a communications path between the ID community and weapon systems designers
– Provides an opportunity to interact with the Weapons Systems engineers from DoD and industry at a high level
23
AgendaAgenda
DoD ATS Past, Present and Future– Bill Ross, Assistant Director, ATS EAO
DoD ATS Acquisition Processes and Tools– Jim Deffler, Chair, Program Analysis IPT
DoD ATS TPS Standardization– Ed Holland, Chair, TPS Standardization IPT
DoD ATS R&D (Open System Architecture)– Mike Malesich, Chair, ATS R&D IPT
DoD Next Generation ATS– Bill Birurakis -- Navy, DoD NxTest WG
– Ron Weinland -- Army, DoD NxTest WG
– John Rosenwald -- Air Force, DoD NxTest WG
– Tom Newton -- Marine Corps, DoD NxTest WG
24
DoDDoD
Automatic Test SystemsAutomatic Test Systems
Acquisition Processes and ToolsAcquisition Processes and Tools
Jim DefflerJim DefflerChair, Program Analysis IPT
26
PastPast
• ATS selection typically driven by support requirements of a single weapons platform or system type:– Higher acquisition costs due to limited production runs and
redundant system development.– Little vertical and horizontal ATE commonality at the service level.
• Little or no thought given to long term life cycle costs:– Each ATE drove its own logistics tail (spares, technical manuals,
training, manpower).– Full burden of ATE in-service engineering (parts obsolescence
ECPs, performance improvements) absorbed by individual platforms.
High Cost of Ownership with no Interoperability!
27
PresentPresent
• DoD policy is to minimize unique types of ATS with emphasis on reduced Total Ownership Costs and joint service Interoperability.
– Joint Service Program Analysis IPT established to facilitate implementation of DoD ATS Policy across services.
– ATS Selection Process established to provide a structured process to make ATS support decisions.
– Several tools available through DoD ATS EAO to assist in the DoD ATS Selection Process.
28
Program Analysis IPT CharterProgram Analysis IPT Charter
• Develop and update the DoD ATS Selection Process Guide.
• Review Policy Deviation Requests and Commercial Tester Acquisition Validation Requests.
• Provide Weapons System IPTs with assistance and advice in implementing DoD ATS policy.
– Preparation of PDRs and CTAVRs– Use of DoD ATS Selection Process Tools
29
DoD ATS SelectionDoD ATS Selection
• The choice of an effective ATS solution must be made using a rational ATS selection process whenever the following occur:
– A weapon system is being developed
– The modernization of an ATS is required
30
DoD ATS Selection ProcessDoD ATS Selection Process
SelectAlternative
Define WeaponSystem Support /
Test Requirements
• Test Requirements• Maintenance Requirements• Operational Requirements
IdentifyATS Alternatives
• DoD ATS Family• Commercial Tester• Existing Service ATS• Other DoD Inventory ATS• Combination of above• New Development ATS
Analyze SelectedAlternatives
• Parametric Analysis (ATE Capabilities vs. UUT Test Requirements)• Cost and Benefit Analysis
• Operational Assessment
31
DoD ATS Selection Process GuideDoD ATS Selection Process Guide
• Provides the DoD Program Manager with the procedures and tools required to implement the requirements of DoD 5000.2R
– Process for preparing requests for deviation when the selection process yields a non-family ATS solution
– Validation process for selection of a commercial tester.– Criteria for introducing a new ATS family member into the DoD
inventory,
• Updated annually by the joint service Program Analysis IPT (last update was 26 October 1998).
• Available over the WWW at http://dodats.osd.mil.
32
DoD ATS Selection Process ToolsDoD ATS Selection Process Tools
• Several tools have been made available through the ATS EAO to facilitate the DoD ATS Selection Process.
– System Synthesis Models (SSM+)– NADEP Jacksonville ROM TPS Cost Model– Standard TPS Cost Management System (STCM)– Cost & Benefit Analysis (CBA) Tool
33
System Synthesis ModelsSystem Synthesis Models
• To assist in the DoD ATS Selection Process, SSM+ provides the following:
– An automated tool for mapping a weapon system’s Unit-Under-Test (UUT) test requirements to ATS within the DoD Family of Testers or any other target ATS Platform.
– SSM+ exception reports which provide an assessment of the limitations of the target ATS to fully support the UUT without Interface Device / Interface Test Adapter (ID / ITA) intervention.
34
System Synthesis ModelsSystem Synthesis Models
• SSM+ contains 28 distinct test categories.
• Each test category defined by a set of parametric fields
• UUT parametric test requirements are mapped to ATS test capabilities.
ATS TESTCAPABILITIES
> Low Voltage (volts)and
< High Voltage (volts)
UUT TEST REQUIREMENTS
UUT Pin Type (code) Voltage (volts)Voltage Tolerance (volts)Current (amps)Ripple (volts p-p)
TEST CATEGORY(28 Total)
DC Power SupplyPulse GenerationDigital Stimulus RF Measurement…...Electro-Optics
35
TPS Cost ModelsTPS Cost Models
• Two (2) TPS cost modeling tools are available to the DoD ATS community through the EAO.
– NADEP JAX ROM TPS Cost Model provides quick, Rough-Order-of-Magnitude TPS cost estimates in a matter of minutes with limited input data for initial budget forecasting.
– Standard TPS Cost Management System (STCM) provides a more detailed cost estimate based on an in-depth assessment of the planned TPS development effort.
36
NADEP JAX ROM TPS Cost ModelNADEP JAX ROM TPS Cost Model
• The NADEP JAX ROM TPS Cost Model, Version 6.0 operates in a Windows based environment an provides the following:
– ROM TPS cost estimates based on minimum user inputs (# of WRAs/SRAs, # of OTPSs, # of Sites, Labor Rates, & Schedule Dates).
– Provides a bottoms-up, WBS tasked-based range-estimate of TPS development & production costs.
– Provides a statistical cost forecast based on cost data collected from various CASS TPS contracts.
– Provides a “Statistical Confidence” range of minimum and maximum values for the TPS cost estimate.
37
Standard TPS Cost Management SystemStandard TPS Cost Management System
• STCM is a fully integrated suite of models which can be consistently applied across all DoD Services and ATS Platforms to provide the following:
– A valid and defensible system to provide improved TPS cost estimating and budget forecasting.
– An accurate, repeatable, and traceable system for proposal assessment (cost realism) and change assessment.
– A system for tracking TPS development contracts and identifying improvement areas for the TPS development process.
• Baseline I is currently available over the World Wide Web with enhancements scheduled for FY-00.
38
Standard TPS Cost Management SystemStandard TPS Cost Management System
Updated Cost &Schedule
UUT Mechanical I/F Rqmnts
USERINPUTS
USEROUTPUTS
WRA Complexities
SRA Complexities
CDRL Item & Review Requirements
Task Update Editor (TPS Development Tool Impact, Late GFE, etc)
Government/Contractor Labor Rates
UUT& ATE Availability for TPS Development
Project Data
SSM+
SCHEDULE & COSTMODELS
Cost of Production OTPSs
CASPERCOMPLEXITY
MODULE
JAX AUTO-ID MERGE
OTPS Groupings
ID Mech Complexity
ID Elec Complexity
UUT ANALYSISMODELS
CASPERSCHEDULE
MODULE
UUT Test Requirements
WRA Design Data
SRA Component andInput/Output Data
CASPERCOST
MODULE
JAXSHOULD-
COST
Government PM Costs broken out by WBS
ATE Station Loading for TPS Development Efforts
TPS Development Schedule
TPS Development Costs broken out by WBS
TPS Production Schedule
39
Sample STCM OutputsSample STCM Outputs (1) Cost Summary Analysis (1) Cost Summary Analysis
40
Sample STCM Outputs Sample STCM Outputs (2) Detailed Cost Analysis (2) Detailed Cost Analysis
41
Sample STCM Outputs Sample STCM Outputs (3) OTPS Schedules (3) OTPS Schedules
42
Sample STCM Outputs Sample STCM Outputs (4) ATS Station Loading (4) ATS Station Loading
43
Planned STCM EnhancementsPlanned STCM Enhancements
• In FY-00, the STCM team plans to incorporate an Earned Value Module.
– The new module will provide a Spend Plan, or Budgeted Cost of Work Scheduled (BCWS), as an optional output of the CASPER Cost Module.
– This module will provide full earned value reporting at contract and OTPS level based on milestone completions and inter-milestone interpolations.
– The Earned Value module will also provide value and trend analysis for cost and schedule variances at contract at OTPS levels.
44
Cost Benefit Analysis ToolCost Benefit Analysis Tool
• The CBA is the component of the ATS Selection Process to ensure that the ATS chosen is the most cost beneficial to the DoD over the life cycle.
• The CBA Tool, developed by ATS EAO in MS Excel format to assist in this process, has the following two major components:
– Quantitative (Cost) Factors– Qualitative Factors, Weights, & Analysis
45
CBA Quantitative FactorsCBA Quantitative Factors
Investment Costs• ATE Non-recurring• ATE Recurring• TPS Non-recurring• TPS Recurring• Initial Training• Interim Support• ATE Support Initial
Acquisition
Sustaining Costs• Manpower• Sustaining Training• ATE Support/
Maintenance• ATE/TPS In-Service
Engineering
Reduced Total Ownership Costs!
46
CBA Qualitative FactorsCBA Qualitative Factors
• Ease of Use
• Operational Suitability
• TPS Transportability
• Upgradeability
• Age of ATS
• Vertical Commonality
• Horizontal Commonality
• Life Cycle Supportability
• Ease of TPS Development
• Adaptability
Improved ATS Interoperability!
47
What We’ve DoneWhat We’ve Done
• Supported numerous WIPTs in implementing DoD ATS Policy in their programs.
• Reviewed 23 individual deviation requests and CTAVRs and made acquisition recommendations to appropriate Milestone Decision Authorities resulting in a total cost avoidance of $212M.
• Recommended the addition of TETS, JSECST, and GWTS to the DoD Family of Testers to supplement operational and specific testing limitations of CASS and IFTE.
48
What We’ve DoneWhat We’ve Done
• Made annual updates to the DoD ATS Selection Process Guide to reflect lessons learned.
• Captured operational and parametric test requirements from a variety of WIPTs that will be invaluable in defining NxTest as the DoD’s next generation standard family tester.
49
FutureFuture
• Open Systems approach will provide for a common DoD ATS platform capable of supporting all weapons system support requirements across a wide spectrum of operational scenarios.
• Designed and developed with use at multiple maintenance levels in mind, providing an opportunity to re-engineer traditional DoD O, I, and D level maintenance concepts to reduce cost and improve efficiency and mission readiness.
Today weapon system support requirements drive ATS test capabilities.Tomorrow ATS test capabilities will drive how we support weapon systems!
50
SummarySummary
• The DoD ATS Selection Process Guide provides direction to make technically sound, cost beneficial ATS support decisions.
• The use of ATS Selection Process Tools facilitates consistent and comprehensive ATS selection analyses.
• The joint service Program Analysis IPT is available to facilitate implementation of DoD ATS Policy across the services.
For more information contact Jim Deffler [email protected] or (732)323-1202.
51
AgendaAgenda
DoD ATS Past, Present and Future– Bill Ross, Assistant Director, ATS EAO
DoD ATS Acquisition Processes and Tools– Jim Deffler, Chair, Program Analysis IPT
DoD ATS TPS Standardization– Ed Holland, Chair, TPS Standardization IPT
DoD ATS R&D (Open System Architecture)– Mike Malesich, Chair, ATS R&D IPT
DoD Next Generation ATS– Bill Birurakis -- Navy, DoD NxTest WG
52
53
TPS STANDARDIZATIONTPS STANDARDIZATION
Past, Present, FuturePast, Present, Future
Ed HollandEd HollandTPSS IPT TEAM LEADER
54
• Past– Mil-Std-2077– Acquisition Reform
• Present – Charter– IPT– Tasks– Mil-Std-961D
• Future– Mil-Prf-XXXX– Verification
• How Can You Help?
TPS StandardizationTPS Standardization
55
• Contained the requirements to achieve cost effective acquisition and life cycle maintenance of OTPS.
• Established a standard for design, development, documentation, configuration management, validation, verification, quality assurance and preparation for delivery of OTPS.
• Provided guidance and direction to Engineers, Analysts and Program Managers in the TPS design and development process.
MIL-STD-2077MIL-STD-2077
56
• One initiative of Acquisition Reform was to eliminate burdensome and lower tier requirements
• Innovation was needed to specify requirements that could be stated by citing exiting specifications
• Resulted in locally prepared specifications
Acquisition ReformAcquisition Reform
57
?
Locally Prepared SpecsLocally Prepared Specs
58
• Identify aspects of TPS procurement process that can be standardized in the acquisition process and in the technical requirements of the TPS themselves.
• Identify and analyze existing methods and processes which afford opportunities or remove obstacles in implementing TPS technical and acquisition process standardization.
TPSS IPT CharterTPSS IPT Charter
59
TPSS IPTTPSS IPT
DoD ATS Executive Agent
Office
A. AhlbumUSAF
Kelly AFB
IPT Team LeaderG. E. Holland
Navy
R. Thor-KmushArmy
Picatinny Arsenal
R. GermanUSMC
MCAS Albany
J. HollidayNavy
NADEP Jax
60
1. Preparation of a DoD performance specification that can be used in lieu of MIL-STD-2077. (85%)
2. Preparation of TPS acquisition package. (80%)
3. Preparation of a Handbook. (65%)
4. Review and comment on ARINC 625. (100%)
IPT TasksIPT Tasks
61
• This standard establishes the formats, contents, and procedures for the preparation of:
– Performance Specifications
– Detail Specifications
– Program-unique Specifications
– Associated documents
MIL-STD-961DMIL-STD-961D
62
• The language and concepts (re: SD-15) apply to performance specs, guides, and program-unique specifications.
• The difference is that the level of detail increases.
• A performance specification is intended to facilitate
standardization and interchangeability of common equipment in DoD.
Performance SpecificationPerformance Specification
63
• A specification that states requirements in terms of results with criteria for verifying compliance, but without stating the methods for achieving the required results.
• The contractor has flexibility in developing and applying solutions to meet the performance requirements.
Performance SpecificationPerformance SpecificationCon’t
64
• Specifications shall not contain requirements for the development or preparation of plans, reports, drawings, manuals or other data products.
• Section 4 shall include all inspections to be performed to determine that the item to be offered conforms to the requirements of section 3.
Performance SpecificationPerformance SpecificationCon’t
65
Section 1 Scope
Section 2 Applicable Documents
Section 3 Requirements
Section 4 Verification
Section 5 Packaging
Section 6 Notes
Mil-Prf-XXXXMil-Prf-XXXX
66
• 100% fault detection
• Small ambiguity groups
• Transportable
• Short run times
• Non-complex
• Reliable
• Maintainable
• Utilize style requirements
Mil-Prf-XXXX: RequirementsMil-Prf-XXXX: Requirements
67
Mil-Prf-XXXX: VerificationMil-Prf-XXXX: Verification
• Section 4 shall include all inspections to be performed to determine that the item to be offered conforms to the requirements of section 3.
• Shall not include quality requirements that belong in the contract.
• Classifications of verification:– First Article Inspection– Conformance (Production) Inspection
• Methods of verification:– Analysis, demonstration, examination, test
68
• Mil-Prf-XXXX will be posted on the TPSS IPT web site (http://dodats.osd.mil/tpss) in September
• Use the electronic form to provide comments for incorporation into the specification.
How Can You Help?How Can You Help?
69
AgendaAgenda
DoD ATS Past, Present and Future– Bill Ross, Assistant Director, ATS EAO
DoD ATS Acquisition Processes and Tools– Jim Deffler, Chair, Program Analysis IPT
DoD ATS TPS Standardization– Ed Holland, Chair, TPS Standardization IPT
DoD ATS R&D (Open System Architecture)– Mike Malesich, Chair, ATS R&D IPT
DoD Next Generation ATS– Bill Birurakis -- Navy, DoD NxTest WG
70
ATSATS
Research and DevelopmentResearch and Development
Integrated Product TeamIntegrated Product Team
(ARI)(ARI)
Mike MalesichMike Malesich ARI Team Leader
72
• DoD, in cooperation with industry, is developing an open system approach for ATS to– support new test needs– permit flexible insertion of updates and new technology– minimum impact on existing ATE and components
ATS R&D IPT (ARI) MissionATS R&D IPT (ARI) Mission
73
Define a generic open system approach for ATS from which specific hardware, software, and systems can be derived
Hardware
SoftwareNetwork
Tools
Processes
ARI GoalsARI Goals
74
ARI OrganizationARI Organization
Mike MalesichARI Chair
Peter ChenUSA
John RosenwaldUSAF
Jim DefflerUSN
John PowellUSMC
Jennifer FethermanAdministrative Support
Chris SchuhmacherSystems Engineer
75
Why Open Systems?Why Open Systems?
• Problems with weapons systems– High cost to develop, support, modify
– New technology insertion– Interoperability lacking
• Changes in acquisition environment– Need to deploy systems faster
– Longer lifetimes– Decreased budgets– Increased dominance of commercial products
76
Definition of Open SystemsDefinition of Open Systems
A business and engineering strategy to choose standards– adopted by industry standards bodies; or– de-facto standards (set by marketplace)
for selected systems interfaces, products, practices and tools.
(source DoD 5000.2-R)
77
Benefits of Open SystemsBenefits of Open Systems
• State of the art systems
• Improved performance
• Systems fielded faster
• Easier technology insertion
• Increased competition
• Reduced life cycle costs
78
RisksRisks
• Government has less control over outcomes
• Building Open Systems takes time– prototyping– standards selection
• Standards selection
• Legacy systems pose additional challenges
79
ATS ArchitectureATS Architecture
UUT ID
Target ATE
TPSDevelopment
RemoteSystems
Data
DataData
RunTime
System
GPI
UserInterface
IBM PS/2
Local MIS
Instruments
Other ATE
TestProgram
80
ATE ElementsATE Elements
UUT ID
Target ATE
TPSDevelopment
RemoteSystems
Data
DataData
RunTime
System
GPI
UserInterface
IBM PS/2
Local MIS
Instruments
Other ATE
TestProgram
DRV IFPICM SFPRAIFRM RFX SWMRMSDIASRTS
81
UUT ElementsUUT Elements
UUT ID
Target ATE
TPSDevelopment
RemoteSystems
Data
DataData
RunTime
System
GPI
UserInterface
IBM PS/2
Local MIS
Instruments
Other ATE
TestProgram
AFP BTDPDD DIAD. MTD
82
TPS ElementsTPS Elements
UUT ID
Target ATE
TPSDevelopment
RemoteSystems
Data
DataData
RunTime
System
GPI
UserInterface
IBM PS/2
Local MIS
Instruments
Other ATE
UTR DTFTPD TOS
TestProgram
83
Network ElementsNetwork Elements
UUT ID
Target ATE
TPSDevelopment
RemoteSystems
Data
DataData
RunTime
System
GPI
UserInterface
IBM PS/2
Local MIS
Instruments
Other ATE
CXENETDTE
TestProgram
84
Benefits to DoDBenefits to DoD
• Reduced total cost of ownership of ATS– TPS re-host– ATE instrument interchangeability– Increased use of commercial products– Scalability
• Greater flexibility through Joint Services interoperable ATS– TPS transportability– ATS convergence
85
Benefits to IndustryBenefits to Industry
• New markets for products
• Increased software re-use
• Improved software reliability
• Potential merging of DoD and commercial product lines
• Enhanced product maintainability
86
ARI AccomplishmentsARI Accomplishments
• Key elements for Open Systems in ATS
• Mandates for several elements
• ATS Annex in JTA
• Development of the Test & Diagnostics Consortium (TDC)
• NxTest requirements
87
On-going TasksOn-going Tasks
• Key element definition– identify/define standards– demonstrate
• Documentation– ATS annex of JTA– ATS Architecture Guide
• Participation with other activities– TDC – NxTest – standards bodies
• Obtain funding
88
Further InformationFurther Information
• Open Systems Joint Task Force– www.acq.osd.mil/osjtf
• ATS R&D IPT– dodats.osd.mil/ari.htm
• Test & Diagnostics Consortium
– www.test-diagnostics.org
89
AgendaAgenda
DoD ATS Past, Present and Future– Bill Ross, Assistant Director, ATS EAO
DoD ATS Acquisition Processes and Tools– Jim Deffler, Chair, Program Analysis IPT
DoD ATS TPS Standardization– Ed Holland, Chair, TPS Standardization IPT
DoD ATS R&D (Open System Architecture)– Mike Malesich, Chair, ATS R&D IPT
DoD Next Generation ATS– Bill Birurakis -- Navy, DoD NxTest WG
90
91
DoD ATS SummaryDoD ATS Summary
• Past– Everyone doing their own thing
• Present– Assisting PMs with analysis for best LCC ATS solution
– Defining an ATS open system architecture
– Defining standard DoD TPS acquisition requirements
– Steering ATS acquisitions toward standard families and Commercial solutions that meet JTA technical architecture requirements
• Future– Services cooperatively from the start define a common DoD ATS concept
– Embrace the architecture standards presently being defined
– New start or modernization implementations
– Effect ATS interoperability
– Reduce ownership costs
– Integrate better with other diagnostics functions
Top Related