200409014 DSC Common Processes Program Review

67 %
33 %
Information about 200409014 DSC Common Processes Program Review
News-Reports

Published on August 22, 2007

Author: Shariyar

Source: authorstream.com

Defense Sustainment ConsortiumProject 6: Common ProcessesPhase 1 – Test Bed DemonstrationsProgram Review :  Defense Sustainment Consortium Project 6: Common Processes Phase 1 – Test Bed Demonstrations Program Review September 14, 2004 Alexandria, VA Common Processes Agenda:  Time Description Presenter 10:15 Introduction – Objectives Holcomb 10:20 Metrics/Common Tasks VanderBok 10:30 ADP Test Bed Demonstration Major 11:10 AFDRAS Test Bed Demonstration Miller 11:50 Project Management Holcomb Common Processes Agenda Problem - Solution:  Problem - Solution Future Logistics Enterprise (FLE) is DoD’s vision to enhance support to the warfighter FLE includes CBM+ Enhanced prognostics / diagnostics Failure trend analysis Point of maintenance aids Serial item tracking Data-driven interactive maintenance training Distance support Integrated maintenance with other logistics functions Slide4:  A practical system that can be integrated into any weapons platform. A system that uses Commercial-Off-The-Shelf (COTS) applications. The minimum of modifications to existing hardware. Army andamp; Navy Targeted Solution WBS 2.5.2 Common Processes – Phase 1 WBS 2.5.2.1 Common Task Activities WBS 2.5.2.2 ADP Test Bed Demonstration WBS 2.5.2.3 AFDRAS Test Bed Demonstration WBS 2.5.2.4 Project Management Common Processes Team:  Common Processes Team CVN Demonstration NGC: John Major, john.major@ngc.com NSWC: Walt Kostyk, kostykwj@nswccd.navy.mil M88 Demonstration UDLP: Tom Berka, thomas.berka@udlp.com Andy Miller, andrew.miller@udlp.com PM M88: Dave Boster, bosterd@tacom.army.mil Integration andamp; Project Management ATI: Curtis Holcomb, holcomb@aticorp.org Altarum: Ray VanderBok, ray.vanderbok@altarum.org Common Processes Agenda:  Time Description Presenter 10:15 Introduction – Objectives Holcomb 10:20 Metrics/Common Tasks VanderBok 10:30 ADP Test Bed Demonstration Major 11:10 AFDRAS Test Bed Demonstration Miller 11:50 Project Management Holcomb Common Processes Agenda WBS 2.5.2.1: Common Task Activities:  WBS 2.5.2.1: Common Task Activities WBS 2.5.2.1.1 Update common decision process Common decision process documented in Phase-0 Evaluate appropriate applications Will work with OEM’s and PM’s for refining process WBS 2.5.2.1.2 Promote common evaluation metrics Primary role to support continued development Build metrics from Phase-0 starting point Share metrics and rationale across demonstrations WBS 2.5.2.1: Common Task Activities:  WBS 2.5.2.1: Common Task Activities WBS 2.5.2.1.3 Share metrics and lessons learned Proactively share information across programs Recruit DSC members to engage in program reviews WBS 2.5.2.1.4 Plan for broad deployment Work with OEM’s and PM offices to identify deployment path Support deployment justification WBS 2.5.2.1.5 Final report System descriptions Application description System performance Business impact (business andamp; government) Deployment plans WBS 2.5.2.1: Common Task Activities:  WBS 2.5.2.1: Common Task Activities Accomplishments Assisted in capturing the core business cases for deployment Developing metrics to support business cases Next Quarter Validate business cases and metrics with program offices Status: 20% complete Deliverables: Updated Phase 0 Report – Dec 05 Consolidated Final Report – Dec 05 Phase 1 Objectives:  Phase 1 Objectives Automated Diagnostic / Prognostic (ADP) System Objectives Construct ADP prototype Lab work Integrate ADP with machinery control and monitoring system (MCMS) Integrate ADP with MCMS/ICAS Test Deploy on ship Integrate with shipboard MCMS network Integrate with shipboard ICAS Shipboard test Simulation test Phase 1 Objectives :  Phase 1 Objectives Automated Fault Data Reporting andamp; Assessment System (AFDRAS) Objectives Collect, format, and transmit data generated during weapon system (HERCULES) maintenance Records hydraulic system information by transmitting corrective maintenance data to a system assessment database Integrate data collection with Interactive Electronic Technical Manuals (IETM) used by maintenance technicians Common Metrics:  Common Metrics Pilot Limited scope System Business Case System Characteristics Benefit Metrics Feasibility demo Benefit Benefit Metrics that support the business case for deployment ADP Business Case Map:  ADP Business Case Map Pilot Limited scope System Business Case System Characteristics Increased availability Reduced inventory Metrics Feasibility demo Align the pilot evaluation and metrics to support Program Office decision to further develop this technology The business case is driven by benefits and cost elements Reduced manning ADP System Availability Metrics:  ADP System Availability Metrics Increased System Availability Early detection / correction of a failing component Fewer systems fail during missions Fewer systems are not available for new missions Fewer catastrophic failures due to fixing the failing component before a catastrophic failure occurs Cost Impact Reduced expediting costs Metric How early and accurate is the detection ADP Manning reduction metrics:  ADP Manning reduction metrics Reduced manning Extend the PM interval perhaps to infinity Periodic inspection Routine maintenance Reduce the time to repair through ID failure mode Reduced diagnostic time Right staff prepared with the right tools and parts Repair is contained to the failing part because it was repaired before a catastrophic failure occurred Metrics: Number of and hours spent on planned repairs Number of and hours spent on unplanned repairs Number of scheduled PM actions Number of 'no fault found' occurrences Amount of advance notice available versus the advance notice needed for planned repair ADP Inventory reduction metrics:  ADP Inventory reduction metrics Reduced onboard inventory Extend or eliminate periodic replacements Given a long enough failure notice, parts could be ordered thus eliminating inventory Better failure data to spare at optimal level of assembly Metric How early and accurate is the detection AFDRAS Business Case Objective:  AFDRAS Business Case Objective Pilot Limited scope System Business Case System Characteristics Increased availability Metrics Feasibility demo Reduced Operating Cost AFDRAS Business Case: Benefits:  AFDRAS Business Case: Benefits Improved system availability via early detection / correction of reliability issues Reduced operating costs by reducing the number of 'No Fault Found' repairs AFDRAS Reliability Response Time Driven System Availability Metrics:  AFDRAS Reliability Response Time Driven System Availability Metrics System Availability Early detection / correction of reliability issues Fewer vehicles fail during missions Fewer vehicles are not available for new missions Cost Impact Reduced expediting costs and additional inventory costs Metrics Reliability resolution lead time from occurrence to solution design AFDRAS No Fault Found Cost Metrics:  AFDRAS No Fault Found Cost Metrics Operating Costs Reducing 'No Fault Found' or 'Cannot Duplicate' errors Track cost avoidance by resolving field defects with 'no problem' depot test When the item is actually failed When the item is actually fine Cost avoided: Cost of expediting spare parts Cost of additional inventory Cost of depot repair process Cost of field repair process Metric: Number of repaired parts that test with No Fault Found at depot GM saw a 50% to 10% reduction in NFF items with a similar system deployment AFDRAS Other Related Benefits:  AFDRAS Other Related Benefits Repair Time More reliable weapon system, optimized diagnostic tool Track mean time to repair and percentage up time AFDRAS Other Long Term Benefits:  AFDRAS Other Long Term Benefits Tool Requirements Optimizing the scheduling and use of tools Labor Spent on Routine Maintenance Adjust or optimize the diagnostics tool Adjust routine maintenance schedule based on environmental or theater conditions using the repair data Labor spent on unplanned / unscheduled maintenance Reduced unplanned / unscheduled maintenance AFDRAS Business Case: Deployment Costs:  AFDRAS Business Case: Deployment Costs Very low incremental system cost: Space Claim Increased functionality in the same package Only new software is required Weight Increased functionality in the same package Only new software is required Reliability No new equipment to fail, only software Track software reliability Non-recurring engineering development cost Communications Infrastructure Data Mining Analysis Common Processes Agenda:  Time Description Presenter 10:15 Introduction – Objectives Holcomb 10:20 Metrics/Common Tasks VanderBok 10:30 ADP Test Bed Demonstration Major 11:10 AFDRAS Test Bed Demonstration Miller 11:50 Project Management Holcomb Common Processes Agenda WBS 2.5.2.2: ADP Test Bed Demonstration:  Goals: Install, test, and demonstrate a commercial ADP system connected to ICAS through the existing ship network. The ADP will communicate to ICAS through an Open System Architecture – Condition Based Maintenance (OSA-CBM) commercial standard The integrated ADP/ICAS/Network will align with CBM+ The integrated ADP/ICAS/Network will align with OPNAV Instruction 4700.7k (11 JUL 2003) WBS 2.5.2.2: ADP Test Bed Demonstration Slide26:  OSA Data Acquisition OSA Sensor Layer OSA Signal Processing Layer OSA Condition Monitoring Layer OSA Health Assessment Layer OSA Prognostics Layer OSA Decision Support Layer Internet Based Interfaces ADP/Network/ICAS Diagram Four Vent Fans and 80 Sensors (total) Ship Network ADP HTML Page ICAS 44 Parameters 44 Parameters 44 Parameters 44 Parameters Slide27:  ICAS Responsibilities of ICAS and ADP in Relation to DSC Project ADP ICAS will do the following to display data, diagnostic, and prognostic information from vent fans: Notify the operator that a non-normal condition exists on one or multiple vent fans. Open an Internet Web Browser. Select the proper URL/IP address for the vent fans. Open and process the XML files every minute for HTML page updates. ADP will do the following to send displays for data, diagnostic, and prognostic information from vent fans: Pass an integer to ICAS notifying a non-normal condition exists on a fan or multiple fans. Provide the Internet Web Server that hosts the pages to be displayed. Provide the proper URL/IP address for the vent fans. Update the XML files every minute for HTML page updates. Ship Network Slide28:  ICAS XML Files That ICAS Will Access for Data Processed Sensor Data Prognostic Data Seven Time Increments From Each Fan – 28 Files Diagnostic Data Four Files -One per Fan Four Files -One per Fan Slide29:  Progression of Non-normal Identification Selection on ICAS Workstation Normal ICAS screen. Alert icon on Normal ICAS screen. Operator 'clicks' on Alert icon, opening Web Browser. Display of fault area shown on ICAS via Web Browser. Operator can obtain more information by clicking on icons. Processed sensor data, diagnostics, prognostics, and decision support, provided by the ADP, can be accessed via this Web Browser. Operator can terminate at anytime and return to normal ICAS Screens. WBS 2.5.2.2: ADP Test Bed Demonstration:  Description NGNN and NSWCCD (Philadelphia), working in a cooperative effort with vendors, the Navy ICAS community, and various Navy maintenance activities, will implement a demonstration ADP for the detection, diagnostics, and prediction of failures on selected ventilation fans on an operational CVN. WBS 2.5.2.2: ADP Test Bed Demonstration WBS 2.5.2.2: ADP Test Bed Demonstration:  WBS 2.5.2.2: ADP Test Bed Demonstration Subtasks: WBS 2.5.2.2.1 Selected System General Maintenance and Time Frequency Analysis WBS 2.5.2.2.2 CBM System Development and Integration WBS 2.5.2.2.3 Laboratory Testing WBS 2.5.2.2.4 Ship Installation and Testing WBS 2.5.2.2.5 Demonstration WBS 2.5.2.2.6 Evaluation and Process Change Recommendations WBS 2.5.2.2 ADP Test Bed DemonstrationWBS 2.5.2.2.1 Selected System General Maintenance and Time Frequency Analysis:  Objective: Review maintenance reports and determine potential impact of ADP on maintenance cost for ventilation systems Accomplishments Target Demonstration Platform Briefed AIRLANT and have initial approval for installation of ADP on CVN73. Reviewed CVN73 availability schedule and determined it is compatible with installation and test schedule of DSC Project. Evaluated CVN73 existing network and ICAS infrastructures Failure Mode Analysis Evaluating potential target ventilation systems that have high maintenance issues Evaluated metrics methodology with ALTARUM Next Quarter Prepare a Test and Evaluation (Tandamp;E) Report for AIRLANT and obtain necessary approvals Prepare initial Drawings to submit to AIRLANT for approval and insertion into the Availability Work Package Status: 75% complete Deliverable: Fan Maintenance Analysis – Sept 04 WBS 2.5.2.2 ADP Test Bed Demonstration WBS 2.5.2.2.1 Selected System General Maintenance and Time Frequency Analysis WBS 2.5.2.2 ADP Test Bed DemonstrationWBS 2.5.2.2.2 CBM System Development:  Objective: Develop ADP for ventilation system onboard CVN68 class aircraft carrier. Accomplishments Completed Software Requirements Document. Completed Test Plan and Procedure for Sensor and Data Acquisition Software. Procured and installed sensors on test platform fan systems. Performing Test of Sensor and Data Acquisition Software. Developing Test Plan and Procedure for the ADP System. Determined that MIL-STD-3008A is outdated and incompatible with this project. Adapting NGNN ADP system for target systems. Next Quarter Complete test of ADP SYSTEM Complete integration of ADP with ICAS through MIMOSA OSA-CBM schemas Develop configuration data set Enhance current ADP based on NSWCCD failure analysis information Status: 80% Deliverable: ADP System Documentation – OCT 04 WBS 2.5.2.2 ADP Test Bed Demonstration WBS 2.5.2.2.2 CBM System Development WBS 2.5.2.2 ADP Test Bed Subtask WBS 2.5.2.2.2 CBM System Development (Cont):  ADP Integration (March ’04 – Oct. ’04) Integrate the ADP system with the NSWCCD developed Integrated Condition Assessment System (ICAS) via an open systems interface standard Represents a link between a commercial vendor and ICAS Allows embedded diagnostic and maintenance expertise from the vendor/manufacturer Vendors create individual ADPs that send CBM information to ICAS Reduced workload on NSWCCD to develop and maintain: the equipment system data bases equipment expert systems equipment prognostic systems ADP interfaces (for each individual ADP/ICAS interface) WBS 2.5.2.2 ADP Test Bed Subtask WBS 2.5.2.2.2 CBM System Development (Cont) WBS 2.5.2.2 ADP Test Bed Subtask WBS 2.5.2.2.2 CBM System Development (Cont):  Console I/O PLC PLC I/O I/O Typical Core Network HUB 6 HUB 3 HUB 4 HUB 5 HUB 1 HUB 2 I/O PLC PLC I/O I/O HMI Console ICAS Vent Fans Integration of ADP/Network/ICAS WBS 2.5.2.2 ADP Test Bed Subtask WBS 2.5.2.2.2 CBM System Development (Cont) New Installation New Installation WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.3 Laboratory Testing:  Lab Testing Description (Sept’04-Jan’05) Identified, procured, and are testing fan sensors and data acquisition software to ensure reliability Developed test plans and procedures for accomplishing testing of ADP sensors and support equipment and validation of the ADP system. Installed and are testing in the laboratory fan test platform sensors data acquisition software and support equipment. Developing of test plans and procedures for integration of the ADP with ICAS and the network infrastructure Demonstrate ADP diagnostics/prognostics capabilities Status: 60% complete Deliverable: ADP Lab Demonstration – Oct 04 WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.3 Laboratory Testing WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.3 Laboratory Testing:  Lab Testing Description (continued) Integration of the ADP with ICAS via network infrastructure Testing of integrated ADP-ICAS and network application Documentation of test results WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.3 Laboratory Testing WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.4 Ship Installation & Testing :  Shipboard Testing Pre-Requisites: Platform Selection East Coast Carrier – Selected the CVN73 Determined that network/ICAS Infrastructure is Installed CVN73 Ship Schedule Availability is compatible with DSC Project Schedule Approvals Reviewing the Temp Alt. Request Approval Have initial Type Commander Buy-In Reviewing the Tandamp;E Report Requirements Developing Authorization Letter WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.4 Ship Installation andamp; Testing WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.4 Ship Installation and Testing :  Shipboard Installation and Initial Testing (Jan’05-Jul’05) Overview The ADP will acquire data from four representative vane-axial fans in relatively close proximity to each other to minimize installation costs for the project. Installation will be accomplished on an CVN73 during the January scheduled availability. The ADP will be connected via the shipboard network to ICAS where diagnostic and prognostic vent fan information will be displayed to the operator. Status: not started Deliverable: ADP Shipboard initial Demonstration – July 05 WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.4 Ship Installation and Testing WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.4 Ship Installation and Testing (Cont) :  Shipboard Testing (continued) Development of test plans and procedures for accomplishing shipboard testing of ADP sensors, support equipment, and ADP system. Installation of ventilation sensors, support equipment, and ADP. Development of shipboard test plans and procedures for integration of the ADP with ICAS and the shipboard network infrastructure Integration of the ADP with ICAS via the shipboard network infrastructure WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.4 Ship Installation and Testing (Cont) WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.5 Demonstration:  Ship Board Demonstration (June 05 – Dec 05) Monitor the ability of the system to pass any maintenance conditions to ICAS. After 3 months visit the ship and examine ADP/ICAS. After 6 month period review data to confirm the existence or non-existence of failures or problems determine if fan parts usage aligns with ADP fault identification In the event of no failures or problems with the selected fans, implement failure simulation test procedures Document demonstration results. WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.5 Demonstration WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.5 Demonstration :  Simulation Plan Development of test plans and procedures for accomplishing shipboard simulation testing of ADP sensors, support equipment, and ADP system. Stimulate maintenance faults/problems through sensor stimulation and/or through software and determine the ability of the system to pass these maintenance conditions to ICAS. Documentation of test results. WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.5 Demonstration WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.6 Evaluation & Process Change :  Application of Metrics Determine how well the system is working Data logging to determine avoided failures, maintenance procedures, etc. Establishment of informal ship reporting mechanism to monitor the performance Integrate the system into the ship’s routine Drive accomplishment of routine maintenance (PMS mod) Assist in troubleshooting (TM mod) Assist in operation (EOSS mod) Automate logsheet readings (ICAS CDS mod) Status: not started Deliverable: ADP Evaluation and Process Change Analysis Report – Dec 05 WBS 2.5.2.2 ADP Test Bed WBS 2.5.2.2.6 Evaluation andamp; Process Change Slide44:  Project Start October ‘03 Failure Modes Review/Analysis CBM System Development Identify Demo Platform Drawing Development ICAS Integration Shipboard Demonstration Simulation Plan Periodic Reviews Evaluation of Results and Final Report Ship Installation Ship S/W Integration Shipboard Testing Training Mar ‘04 Oct ‘04 Dec ‘05 Feb ‘05 Jun ‘05 WBS 2.5.2.2: ADP Test Bed Timeline Test Procedures Lab Testing of ADP Lab Test of ADP/ICAS Common Processes Agenda:  Time Description Presenter 1:45 Introduction – Objectives Holcomb 1:50 Metrics/Common Tasks VanderBok 2:00 ADP Test Bed Demonstration Major 2:20 AFDRAS Test Bed Demonstration Miller 2:40 Project Management Holcomb Common Processes Agenda Task 3: Test Bed Demonstration 2 – AFDRAS (Automated Fault Data Reporting Assessment System):  Task 3: Test Bed Demonstration 2 – AFDRAS (Automated Fault Data Reporting Assessment System) Goals: Construct a demonstrator to show the ability to collect, interpret, and store data acquired during weapon system (HERCULES) diagnostics and maintenance. Show that stored data is useful for off-system assessment databases or other logistical support functions (CBM+). Integrate data acquisition with the troubleshooting process so that data is collected during maintenance and formatted for transmission to a central database. Common Processes AFDRAS Demonstrator Concept:  Common Processes AFDRAS Demonstrator Concept Uses Current IETM software. Uses Current Enhanced Diagnostic System (EDS) hardware and software. The EDS software will require some changes to record the necessary data. Develop additional software to enable maintainer to record parts information data. Develop software to format data into an XML tagged format for wireless transmission from the field support device. Common Processes AFDRAS Demonstrator Concept:  Extracted System Data Storage Wireless Transmission Maintainer Inputs Common Processes AFDRAS Demonstrator Concept WBS 2.5.2.3: AFDRAS Test Bed Subtasks:  WBS 2.5.2.3: AFDRAS Test Bed Subtasks WBS 2.5.2.3.1 Identifying and Using Data WBS 2.5.2.3.2 Identifying Hardware/Software to Enable Data Collection WBS 2.5.2.3.3 Collecting Data through an IETM WBS 2.5.2.3.4 Extracting Data from the IETM WBS 2.5.2.3.5 Automatic Database Population WBS 2.5.2.3.6 Automating Data Collection and Database Population, Demonstrator Hardware/Software Acquisition, and Assembly WBS 2.5.2.3.7 Demonstration WBS 2.5.2.3.8 Evaluation WBS 2.5.2.3.1 Subtask 1: Identifying and Using Data:  WBS 2.5.2.3.1 Subtask 1: Identifying and Using Data The AFDRAS data field list shown below will be used for the HERCULES (M88A2) Demonstrator. It has been finalized and incorporates customer comments received. The list identifies those items which can be automated and which may require manual entry with the current demonstrator hardware constraints. Status: 100% Complete Bold Items are Specifically Mentioned in the SOW WBS 2.5.2.3.2 Subtask 2: Identifying Hardware/Software to Enable Data Collection:  WBS 2.5.2.3.2 Subtask 2: Identifying Hardware/Software to Enable Data Collection Completed the Make/Buy evaluation as summarized on the next slide for the portions of the software development that are under consideration for outsourcing the Data Compiler and Data Transfer (DCDT) software. Results show that the software development will be most effectively done by UDLP. Completed and began documenting feasibility evaluation of using MIL-STD-3008A XML data tags. Analysis has determined that the primary 3008A tables that UDLP will use for the data recorded are: Table 1 Equipment Type Data Table 17 Related Maintenance Actions Table 20 IETM Fault Result Data Table 21 IETM Maintenance Reporting Data Make/Buy Analysis Summary:  Make/Buy Analysis Summary WBS 2.5.2.3.2 Subtask 2: Identifying Hardware/Software to Enable Data Collection WBS 2.5.2.3.2 Subtask 2: Identifying Hardware/Software to Enable Data Collection:  WBS 2.5.2.3.2 Subtask 2: Identifying Hardware/Software to Enable Data Collection Next Quarter: Complete the identification of Hardware and Software to be used for data collection. Complete documentation of the feasibility evaluation of using MIL-STD-3008A XML data tags. Status: 87% Complete WBS 2.5.2.3.3 Subtask 3: Collecting Data Through an IETM:  WBS 2.5.2.3.3 Subtask 3: Collecting Data Through an IETM Continued developing the methodology for an IETM software enhancement to provide the needed parts information for recording the desired data during each maintenance action. Decision was made to use the HERCULES electronic Replacement Parts and Specialty Tools List (RPSTL) figures and data files from the IETM software and adapt them to the new software module. Continued development of software that will use the data from the IETM SGML file and place it into the correct MIL-STD-3008A file format. Software specification are currently being developed Began software modifications to the IETM EDS to record data that is currently displayed and used by the maintainer for diagnostics. Data Collection:  Data Collection WBS 2.5.2.3.3 Subtask 3: Collecting Data Through an IETM WBS 2.5.2.3.3 Subtask 3: Collecting Data Through an IETM:  WBS 2.5.2.3.3 Subtask 3: Collecting Data Through an IETM Next Quarter: Complete modification to EDS software to record pressure data. Complete software specifications and begin test plan and coding for the parts information module. Status: 75% Complete WBS 2.5.2.3.4 Subtask 4: Accessing (Extracting) Data Through an IETM :  WBS 2.5.2.3.4 Subtask 4: Accessing (Extracting) Data Through an IETM Continued software development to extract troubleshooting and maintenance action information using the SGML file produced by the IETM. UDLP has 'reversed engineered' a DTD for the data file produced by the IETM. Developed a draft specification for the DCDT software. AFDRAS Software:  AFDRAS Software WBS 2.5.2.3.4 Subtask 4: Accessing (Extracting) Data Through an IETM WBS 2.5.2.3.4 Subtask 4: Accessing (Extracting) Data Through an IETM :  Next Quarter: Finalize the DCDT software specification and begin writing the test plan. Begin logic to fuse the three SGML/XML data files into the final XML file to ensure proper time sequencing of recorded data with 3008A data tags. Status: 62% Complete WBS 2.5.2.3.4 Subtask 4: Accessing (Extracting) Data Through an IETM WBS 2.5.2.3.5 Subtask 5: Automatic Database Population:  WBS 2.5.2.3.5 Subtask 5: Automatic Database Population Continued development of alternative solutions to the contract requirements for the trade study evaluation. This trade study will be used to determine the optimal solution to automatically transfer the data to populate a database. Some options are: Cellular Data Link 802.11b Wireless Ethernet Next Quarter: Complete development of alternative solutions to the contract requirements for the trade study evaluation. Complete software plan for implementation of automated data transfer. Develop software test plan in parallel with software implementation plan. Status: 28% Complete WBS 2.5.2.3.6 Subtask 6: Automating Data Collection and Database Population, Demonstrator Hardware/Software Acquisition, and Assembly:  WBS 2.5.2.3.6 Subtask 6: Automating Data Collection and Database Population, Demonstrator Hardware/Software Acquisition, and Assembly Implementation of the developed AFDRAS and installation of hardware and software into the demonstration weapon system (HERCULES). Status: 0% Complete - Scheduled start date of January 2005. WBS 2.5.2.3.7 Subtask 7: Demonstration:  WBS 2.5.2.3.7 Subtask 7: Demonstration Demonstration of AFDRAS data collection and extraction on the HERCULES (M88A2). Status: 0% Complete - Scheduled start date of April 2005. WBS 2.5.2.3.8 Subtask 8: Evaluation and Final Report:  WBS 2.5.2.3.8 Subtask 8: Evaluation and Final Report Document demonstration results and prepare the final report. Recommendations for an implementation plan will be included as part of the final report. Status: 0% Complete - Scheduled start date of October 2005. Slide64:  Task 3: AFDRAS Test Bed Demonstration 2 - Schedule Task 3: AFDRAS Test Bed Demonstration 2 - Schedule:  Task 3: AFDRAS Test Bed Demonstration 2 - Schedule Common Processes Agenda:  Time Description Presenter 1:45 Introduction – Objectives Holcomb 1:50 Metrics/Common Tasks VanderBok 2:00 ADP Test Bed Demonstration Major 2:20 AFDRAS Test Bed Demonstration Miller 2:40 Project Management Holcomb Common Processes Agenda WBS 2.5.2.4: Project Management:  WBS 2.5.2.4: Project Management Continued communication with program offices to build a rapport for future discussions and to share information between common activities. Continued to support a strategy for introducing and integrating our concept into the Future Combat System (FCS). WBS 2.5.2.4: Project Management:  WBS 2.5.2.4: Project Management POP: 10/1/03-12/24/05 10 of 27 months, 37% time expended $843K of $2,118K , 40% of cost expended Slide69:  Questions?

Add a comment

Related presentations

Related pages

200409014 DSC Common Processes Program Review

Information about 200409014 DSC Common Processes Program Review. News-Reports. Published on August 22, 2007. Author: Shariyar. Source: authorstream.com
Read more

Kentucky Department of Education : Program Reviews

Program reviews have been written for five (5) areas: Arts & Humanities, Writing, ... Program Review Audit Process Regional Training Opportunities
Read more

Design review (U.S. government) - Wikipedia, the free ...

This article describes the major phases of that systems engineering process. A design review ... Design review is also ... program or project plan and ...
Read more

DSC

DSC (Digital Security Controls) is a world leader in electronic security. Since the company’s genesis, the experts at DSC have been leading the way.
Read more

DSC

Click on the link below for a list of documents containing answers to some of the most common user questions about specific security systems. ... DSC ...
Read more

Day 1: Intro to PowerShell DSC and Configuring Your First ...

I submit for your review, PowerShell DSC concepts and pull ... Common use cases for PowerShell DSC ... Intro to PowerShell DSC and Configuring ...
Read more

Current Software Reviews - Digital Imaging Software

Current Software Reviews ... from each image it processes. ... want the hassle of keeping up with various programs? Then this is the software for you.
Read more

Digital Photography Review

Current digital photography news, digital camera reviews, articles and discussion forums.
Read more

Update Management Process

Update Management Overview. Update management is the process of controlling the deployment and maintenance of interim software releases into ...
Read more

Professional Development - DSCPA

She will guide you step by step through the process while explaining key ... IRS for this IRS approved program, ... Commons Wilmington, DE 19810 ...
Read more