DoD Automatic Test Systems Past, Present, Future

Slides:



Advertisements
Similar presentations
ASYCUDA Overview … a summary of the objectives of ASYCUDA implementation projects and features of the software for the Customs computer system.
Advertisements

Roadmap for Sourcing Decision Review Board (DRB)
Global Congress Global Leadership Vision for Project Management.
Leverage MarkITS for agile solutions delivery that balances strategic thinking with tactical execution for “Business & Technology Convergence” MarkITS.
Optimize tomorrow today. TM Cost and Affordability approach at Development Planning stage 1.
Course: e-Governance Project Lifecycle Day 1
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
BENEFITS OF SUCCESSFUL IT MODERNIZATION
Parts Management Reengineering TLCSM Executive Council Update Gregory Saunders, Director Defense Standardization Program Office 05 Oct 06.
Alternate Software Development Methodologies
© 2005 by Prentice Hall Appendix 2 Automated Tools for Systems Development Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F.
Office of the Secretary of Defense Defense Microelectronics Activity (DMEA) Defense Microelectronics Activity (DMEA) Doug Casanova Defense Microelectronics.
Inc. User Requirements Presentation DoD Automatic Test Systems Michael Malesich DoD ATS R&D IPT Chair.
Systems Engineering in a System of Systems Context
1 Achieving Total Systems Management (ATSM) Acquisition Strategies to Increase Reliability and Reduce Logistics Footprint PEO/SYSCOM Workshop November.
© 2004 Visible Systems Corporation. All rights reserved. 1 (800) 6VISIBLE Holistic View of the Enterprise Business Development Operations.
Secure System Administration & Certification DITSCAP Manual (Chapter 6) Phase 4 Post Accreditation Stephen I. Khan Ted Chapman University of Tulsa Department.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
New Employee Training Market Research
SYSTEM ANALYSIS AND DESIGN
Configuration Management, Logistics, and Universal CM Issues Larry Bauer Boeing Commercial Airplanes NDIA Conference Miami March 4-5, 2005
Integrated Capability Maturity Model (CMMI)
Appendix 2 Automated Tools for Systems Development © 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 2 Slide 1.
Server Virtualization: Navy Network Operations Centers
Test Organization and Management
DoD Acquisition Domain (Sourcing) (DADS) Analysis of Alternatives (AoA) E-Business/SPS Joint Users’ Conference November 15-19, 2004 Houston, TX.
DoD Parts Management Reengineering Defense Standardization Program Office Industry Day, 8 May 2007 PMRWG Final Report.
Parts Standardization & Management Committee (PSMC) Meeting Oct 22, 2007 San Diego, CA Parts Management Reengineering Implementation Process Team (PMRIPT)
Future Airborne Capability Environment (FACE)
SCSC 311 Information Systems: hardware and software.
Product Development Chapter 6. Definitions needed: Verification: The process of evaluating compliance to regulations, standards, or specifications.
Creating a Shared Vision Model. What is a Shared Vision Model? A “Shared Vision” model is a collective view of a water resources system developed by managers.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
MD Digital Government Summit, June 26, Maryland Project Management Oversight & System Development Life Cycle (SDLC) Robert Krauss MD Digital Government.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e Headquarters U.S. Air Force 1 Fred Meyer, AF PM&AE 04 February 2010 Air Force Program Management.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
PLANNING ENGINEERING AND PROJECT MANAGEMENT By Lec. Junaid Arshad 1 Lecture#03 DEPARTMENT OF ENGINEERING MANAGEMENT.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e Headquarters U.S. Air Force 1 Improving Air Force Scheduling Processes and Tools – A Demonstration.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
CAPT Joe Spruill Office of Deputy Assistant Secretary of the Navy (Logistics) September 29, 2005 Managing Obsolescence within a Performance Based Logistics.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
SOFTWARE PROJECT MANAGEMENT
EGovOS Panel Discussion CIO Council Architecture & Infrastructure Committee Subcommittee Co-Chairs March 15, 2004.
PRJ566 Project Planning & Management Software Architecture.
Improving the Tradecraft in Services Acquisition Services Acquisition Training Lyle Eesley Defense Acquisition University Director Center for Services.
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Sustainment Solutions Envelope (SSE) Sustainment Solutions Envelope (SSE) Presented at the Defense Standardization Program Conference, 16 March 2004.
New Product Development Page 1 Teddy Concurrent Engineering by Teddy Sjafrizal.
State of Georgia Release Management Training
LOG235/236 Performance Based Logistics Bruce Hatlem Logistics Functional IPT September 2007.
March 2004 At A Glance The AutoFDS provides a web- based interface to acquire, generate, and distribute products, using the GMSEC Reference Architecture.
Week 2 – Risk Planning & Identification. Risk & Risk Management.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 2 Diploma of Project Management.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
Environment, Safety, and Occupational Health Opportunities in DoD Business Transformation May 4, 2006.
PRIIA 305 Technical Subcommittee Systems Engineering Processes for Passenger Equipment Acquisition and Life Cycle Support Presented at: NGEC Executive.
DoD Template for Application of TLCSM and PBL
Sample Fit-Gap Kick-off
Parts Management Plan Builder 26 July 07
LOGISTICS ACQUISITION, AN EMPHASIS ON PLANNING FOR PERFORMANCE
DAU Hot Topics Forum February 15, 2017
Chapter 18 Maintaining Information Systems
DAU Hot Topics Forum February 15, 2017
Improving Mission Effectiveness By Exploiting the Command’s Implementation Of the DoD Enterprise Services Management Framework - DESMF in the [name the.
DoD Automatic Test Systems (ATS) Strategies
Financial Management Modernization Program
Managed Content Services
Presentation transcript:

DoD Automatic Test Systems Past, Present, Future Bill Ross Assistant Director, DoD ATS Executive Agent Office

Past 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

Two Primary DoD ATS Goals (April ‘94) 1. Reduce total cost of ownership of DoD ATS 2. Provide greater flexibility to the warfighter through Joint Services interoperable ATS

DoD ATS Policy (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

DoD ATS Organization DoD Executive Agent for Automatic Test Systems Assistant Secretary of the Navy (RDA) Dr. Buchanan DoD Automatic Test Systems Executive Agent Office NAVAIRSYSCOM PMA260 Capt Fletcher Bill Ross DoD Automatic Test Systems Management Board Joint Service ATS Leaders Capt Fletcher, USN Col Nodine - USAF Col Hamilton - Army Col Gebhard - SOCOM LCol Juliano - USMC

ATS Management Board Organization ATS EA Office Navy (PMA-260) Capt Fletcher USAF Rep Col Nodine Army Rep Col Hamilton USMC Rep LCol Juliano SOCOM Rep Col Gebhard EA Office Asst Dir (PMA-260ATS) Bill Ross USAF Coord Alton Jenkins Army Coord Dawn Gratz USMC Coord Mike Heilman SOCOM Coord LCOL Ragland IPTs/Working Groups

Active 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 Gratz John Rosenwald NxTest Working Group Bill Birurakis

Products http://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

Steering a Course Past Present Near Future Each program did their own thing Present Selecting standard DoD ATS Families Defining a commercial-based standard open system architecture Near Future Evolve the open system architecture Services cooperatively define and implement the common next generation DoD ATS

Steering a Course Past Present Near Future Each program did their own thing Present Selecting standard DoD ATS Families Defining a commercial-based standard open system architecture Near Future Evolve the open system architecture Services cooperatively define and implement the common next generation DoD ATS DoD NxTest

NxTest 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

DoD 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

DoD 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

DoD NxTest Plan Technology Demonstrations 1996 - 2003 Prototype 2001 - 2004 TPS Regression Testing 2002 - 2006 Pre-Production 2004 - 2006 Production 2006 -

DoD 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

DoD Joint Technical Architecture http://www-jta.itsi.disa.mil/ JTA v 3.0 Information Processing Standards Information Transfer Standards Information Modeling Standards Human-Computer Interface Standards Information Systems Security Standards C4ISR Domain Modeling & Simulation Domain Airborne Reconnaissance Command & Control Communication Intelligence Information Warfare Surveillance/Recon Combat Support Domain Weapon Systems Domain 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

Joint 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

JTA 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

ARI, JTA, NxTest Architecture DoD ATS Generic Technical Architecture System Acquisition demonstrated success Commercial Standard ATS Open System Architecture NxTest Commercial standard ARI (Ind/Gov’t) Continuously evolving “Mandated” & “Emerging” Critical ATS Elements Joint Services NxTest Working Group Implementation may take many forms DoD JTA Updated annually  Based on: - Test requirements - Technical innovation - Open system architecture requirements  Based on demonstrated commercial standards

Test & Diagnostics Consortium www.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

Integrated 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?

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

Agenda 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

DoD Automatic Test Systems Acquisition Processes and Tools Jim Deffler Chair, Program Analysis IPT

High Cost of Ownership with no Interoperability! Past 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!

Present 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.

Program 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

DoD 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

DoD ATS Selection Process Identify ATS Alternatives DoD ATS Family Commercial Tester Existing Service ATS Other DoD Inventory ATS Combination of above New Development ATS Define Weapon System Support / Test Requirements Maintenance Requirements Operational Requirements Analyze Selected Alternatives Parametric Analysis (ATE Capabilities vs. UUT Test Requirements) Cost and Benefit Analysis Operational Assessment Select Alternative

DoD 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.

DoD 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

System 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.

System Synthesis Models SSM+ contains 28 distinct test categories. TEST CATEGORY (28 Total) DC Power Supply Pulse Generation Digital Stimulus RF Measurement …... Electro-Optics Each test category defined by a set of parametric fields UUT TEST REQUIREMENTS UUT Pin Type (code) Voltage (volts) Voltage Tolerance (volts) Current (amps) Ripple (volts p-p) UUT parametric test requirements are mapped to ATS test capabilities. ATS TEST CAPABILITIES > Low Voltage (volts) and < High Voltage (volts)

TPS 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.

NADEP 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.

Standard 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.

Standard TPS Cost Management System USER INPUTS UUT ANALYSIS MODELS USER OUTPUTS JAX AUTO- ID MERGE UUT Mechanical I/F Rqmnts ID Elec Complexity Updated Cost & Schedule SCHEDULE & COST MODELS ID Mech Complexity UUT Test Requirements SSM+ OTPS Groupings CASPER COST MODULE TPS Development Costs broken out by WBS WRA Design Data WRA Complexities CASPER COMPLEXITY MODULE SRA Component and Input/Output Data TPS Development Schedule SRA Complexities CASPER SCHEDULE MODULE ATE Station Loading for TPS Development Efforts CDRL Item & Review Requirements Project Data Government PM Costs broken out by WBS Government/Contractor Labor Rates JAX SHOULD- COST UUT& ATE Availability for TPS Development TPS Production Schedule Cost of Production OTPSs Task Update Editor (TPS Development Tool Impact, Late GFE, etc)

Sample STCM Outputs (1) Cost Summary Analysis

Sample STCM Outputs (2) Detailed Cost Analysis

Sample STCM Outputs (3) OTPS Schedules

Sample STCM Outputs (4) ATS Station Loading

Planned 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.

Cost 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

CBA 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!

CBA 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!

What 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.

What 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.

Today weapon system support requirements drive ATS test capabilities. Future 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!

Summary 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 at DefflerJP@navair.navy.mil or (732)323-1202.

Agenda 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

TPS STANDARDIZATION Past, Present, Future Ed Holland TPSS IPT TEAM LEADER

TPS Standardization Past Present Future How Can You Help? Mil-Std-2077 Acquisition Reform Present Charter IPT Tasks Mil-Std-961D Future Mil-Prf-XXXX Verification How Can You Help?

MIL-STD-2077 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.

Acquisition Reform 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

Locally Prepared Specs ?

TPSS IPT Charter 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 DoD ATS Executive Agent Office IPT Team Leader G. E. Holland Navy A. Ahlbum USAF Kelly AFB R. Thor-Kmush Army Picatinny Arsenal R. German USMC MCAS Albany J. Holliday Navy NADEP Jax

IPT Tasks 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%)

MIL-STD-961D This standard establishes the formats, contents, and procedures for the preparation of: Performance Specifications Detail Specifications Program-unique Specifications Associated documents

Performance Specification 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 Specification Con’t 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 Specification Con’t 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.

Mil-Prf-XXXX Section 1 Scope Section 2 Applicable Documents Section 3 Requirements Section 4 Verification Section 5 Packaging Section 6 Notes

Mil-Prf-XXXX: Requirements 100% fault detection Small ambiguity groups Transportable Short run times Non-complex Reliable Maintainable Utilize style requirements

Mil-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

How Can You Help? 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.

Agenda 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

ATS Research and Development Integrated Product Team (ARI) Mike Malesich ARI Team Leader

ATS R&D IPT (ARI) Mission 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

ARI Goals Define a generic open system approach for ATS from which specific hardware, software, and systems can be derived Hardware Tools Processes Software Network

Administrative Support ARI Organization Peter Chen USA John Rosenwald USAF Mike Malesich ARI Chair John Powell USMC Jim Deffler USN Jennifer Fetherman Administrative Support Chris Schuhmacher Systems Engineer

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

Definition 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)

Benefits of Open Systems State of the art systems Improved performance Systems fielded faster Easier technology insertion Increased competition Reduced life cycle costs

Risks Government has less control over outcomes Building Open Systems takes time prototyping standards selection Standards selection Legacy systems pose additional challenges

ATS Architecture

ATE Elements

UUT Elements

TPS Elements

Network Elements

Benefits 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

Benefits to Industry New markets for products Increased software re-use Improved software reliability Potential merging of DoD and commercial product lines Enhanced product maintainability

ARI 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

On-going Tasks Key element definition Documentation identify/define standards demonstrate Documentation ATS annex of JTA ATS Architecture Guide Participation with other activities TDC NxTest standards bodies Obtain funding

Further Information Open Systems Joint Task Force ATS R&D IPT www.acq.osd.mil/osjtf ATS R&D IPT dodats.osd.mil/ari.htm Test & Diagnostics Consortium www.test-diagnostics.org

Agenda 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

DoD ATS Summary Past Present Future Everyone doing their own thing 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