1 / 46

October 23, 2003

SMMOA Supply, Maintenance, Monitoring Open Architecture. Presented by David Perrussel SMMOA Project Lead. TOSA Team. October 23, 2003. “Plug and Play” Storage Devices for common interface. Open Systems Architecture.

juanboyd
Download Presentation

October 23, 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SMMOA Supply, Maintenance, Monitoring Open Architecture Presented by David Perrussel SMMOA Project Lead TOSA Team October 23, 2003

  2. “Plug and Play” Storage Devices for common interface Open Systems Architecture • The Open System Architecture (OSA) concept was developed by the computing industry in the 1970’s and 1980s to help compatability among vendors, thus reduce costs. • Involves defining an architecture and “open standards” for interfaces within that architecture • Multiple companies are then free to build (innovative) products that “plug into” open standard • Widely used throughout Information Technology (IT) Industry Examples of OSA Interfaces

  3. IMPLEMENTATION B IMPLEMENTATION A Open Systems Approach Industry can choose any implementation (including proprietary) to meet OSA interface Performance Specification + OSA Interfaces Acquisition of System = Performance Spec: • Performance • Envelope • Human Factors • Power consumption • ILS docs OSA Interfaces • Physical (Geometric & Tolerances) • Electrical • Air interfaces • Cooling interfaces • Control Sensors, Monitoring interfaces • Piping connections • Human Factors • Survivability/Vulnerability: shock/vibration/EMI/EMC • CG / VCG

  4. 41+ Years of Technology Advancement 6+ Years of Technology Advancement OSA facilitates exploitation of commercial market & technology advances throughout ship development & operation phases Equipment Selection/ Design Freeze Equipment Installation Ship Life Cycle Design and Construction DoD/Navy Unique Need • Platforms with increasingly long lifecycles (30+ years) • Increased used of commercial technologies • Short lifecycles of COTS (<7 years) • Often obsolete by time fielded • Increased market “exposure” & small market strength • Increased emphasis on Technology Refresh & Insertion • Response to COTS / Market changes • Response to Mission changes • Response to New Technologies (evolutionary and disruptive) OSA is a large component of the answer

  5. Open System Benefits • Flexibility • Allows access to multiple vendors at system and component level • Competition during acquisition and over lifecycle • Avoid sole source constraints • Upgradability • Allows new technology to be inserted cost effectively • Does not limit industry’s ability to innovate • Scaleability • For future upgrades • Affordability • Reduces procurement costs • Reduces production costs • Reduces construction costs • Reduces O&S costs • Projected Cost Savings based on studies to date: • Acquisition : 20 - 25% • O&S : 20 - 35%

  6. TOSA Vision: The Adaptable Ship 21 Open Zones Open Modules Ordnance Various Machinery Equipment Open Distributed Systems C4I HVAC IPS Organic Off board Vehicles (OOV) TSCE Etc. Topside +Monitoring Other +Maintenance +Supply

  7. Need for Supply, Maintenance and Monitoring Open Architecture • Increasedoperational readiness – particularly when optimal manning is specified (e.g.DDX). • Use Open Standards for better Interoperability and technology upgrade & refresh. • Optimal efficiency for shipboard maintenance and supply functions • Condition assessment • Condition-Based maintenance • Automation of supply functions (such as inventory and parts ordering) • Solutions must be acceptable to both system integrators and component manufacturers for new ships and compatible with on going ISEA programs.

  8. Fleet Support ISEAs / FTSCs Supply SUPPLY Tech Data Library CM Personnel Config Data Mgr Maintenance JIT Parts Maintenance Assist Personnel Monitored Data CBM Accurate CM Data Tech Infusion Tech Data Update Training Assist Benefits of open information exchange Configuration Management Human Resources Supply Maintain Damage Control Vendors Monitor Engineering Operational Readiness SMMOA Vision

  9. SMMOA Elements • TOSA has established the following elements as part of the SMMOA Focus Area Team: • Open Sensor/Network Interface (OSNI) Development • Open Material Condition Information (OMCI) Development [For Condition Based Maintenance] • Open Logistics Support Interface (OLSI) Development

  10. Open Sensor/NetworkInterface (OSNI) Development

  11. Automation andOpen Architecture • Reduced/optimized manning requirement for future ship classes drives for increased automation. • Increased automation will require a significantly increased number of transducersinstalled aboard ship • Possibility of 25,000 (or more) transducers on DD(x) class of ships • Levies unique requirements for future Naval platforms • Open architecture approach will be key to achieving vision of highly automated ship in a cost effective manner • Reduced installation costs • Allow for Technology Insertion / Upgrade • Allow for streamlined Maintenance & Supply

  12. OSNI Goals & Objectives • Explore various sensor-bus standards & interfaces • Perform Risk Mitigation on candidate sensor-bus standards • Help establish a set of Navy Open Architecture sensor-bus standards & interfaces • Work with Standards Bodies to develop Open Sensor-Bus Standards for both Industry and Navy • Promulgate the use of sensor-bus standards for Navy systems to shipyards, systems integrators and vendors

  13. Total Ship Total Ship Computing Computing Open Sensors/Networks and Total Ship Computing (TSCE) Sensors Sensors Distributed Distributed Local Local Computing Computing Processing Processing HM&E HM&E Combat Combat System System Sensors Sensors Network Network Total Ship Total Ship C4I C4I Computing Computing Other Other Systems Systems Network Network Other Other Systems Systems Future Systems Open Systems Architecture Approach for TSC Similar approach for sensors/sensor networks

  14. OSNI Initial Focus onIEEE 1451 Family We have chosen our initial focus on the IEEE 1451 family: • The IEEE 1451 sensor-bus network family attempts to address interoperability issues • 1451 family allows for interoperability among different network AND transducer manufacturers • 1451 family allows for plug & play of transducers and network • 1451 family allows for easy upgrade • Development of the 1451 family is evolving OSNI chose to focus on IEEE 1451 as a candidate open interface sensor/network standard

  15. Network Interface Sensor Interface Open Interface Open Interface 1451.1 Network Capable Application Processor (NCAP) Smart Transducer Interface Module (STIM) 1451.2 Transducer Bus Interface Module (TBIM) 1451.3 Network Network Future Gen Network Future Gen Network Next Gen Network Next Gen Network Various Networks/ Protocols Various Networks/ Protocols 1451.4 Mixed Mode Interface (MMI) IEEE 1451 Standards Family 1451.5 1451.5 is Wireless

  16. DistributedSensor-bus Network Work Stations Ship wide LAN(s) Compartments & Application Zones Distributed Processing Module Transducers Distributed Processing Modules

  17. Bus Interface Bus Interface Bus Interface Bus Interface Work Station T T T T ModularSensor-bus Interfaces Interfaces installed when ship built Command and Control Network Remote Station Replaceable Transducers

  18. Initial Risk Mitigation • Development of an Open Sensor/Network Interface Demonstrator • IEEE 1451.3 (multi-drop bus) chosen for testing • Used an early draft of the standard (2001) • Examine and explore Navy needs and requirements • Tested a concept of additional backup features added to help address Navy specific issues • Help demonstrate the use of plug-and-play for sensor-bus networks • Adapted existing COTS parts and systems to simulate IEEE 1451.3 network • Pressure & Temperature sensors • Encoder & Stepper motor actuators

  19. OSNI Demonstrator

  20. Open Material Condition Information (OMCI)

  21. OMCI Requirements • Need to reduce/optimize manning for DDX • Need to reduce maintenance man-hours • Requires more Sophisticated and Extensive Maintenance Applications • There are multiple Navy and commercial maintenance information interfaces • Maintenance developments including future Condition Based Maintenance (CBM) applications require: • Access to expanding commercial developments. • Interoperability between commercial CBM systems and maintenance information systems. • A Navy/commercial standard interface for maintenance applications. • An Open Material Condition Information • Standard is Required

  22. Material Condition Information Data Flow Stable values Updated at preset intervals CBM Processor Software samples value(s) at preset intervals ID ASW53001 SENSOR Software Continuous Fluctuating value (500 +/- x%) (500) (500) Software logs & time stamps values at preset intervals Discrete value (low or good) (good) (good) Database ID ASW53002 SENSOR Data Acquisition Board Other Signals Permanent info Sensor IDs, etc. Alarm Value (500) NCAP Automated Work order and supply request LAN Add Time Stamp Value (700) Sensors Processed value or Discrete signal Trigger Rule? Value (300) Y End

  23. Common Database Open Material Condition Information On-Ship Off Ship Common Database Common Data Schema Common Data Schema Common Data Schema Common Data Schema • A common database information schema for all material condition information, NOT just CBM data. • Integration of CBM and Information Systems • Information Interoperability

  24. Military Market Surveillance/Technology Projection Navy Development Efforts • Total Ship Monitoring (TSM) • Battle Group Automated Maintenance Environment (BG-AME) • Enterprise Resource Planning (ERP) • DDX • Etc. Working Groups • Gas Turbine Working Group • Maintenance Engineering Technology Team (SEA04M) • Joint Wireless Working Group (SPAWAR) Other CBM Data Activities • Army Diagnostic Improvement Program • AAAV • JAHUMS • OSA-CBM • MIMOSA • Etc. R&D Programs • Reduce Ships crew through Virtual Presence (RSVP) • SMARTSHIP Initiatives • Submarine Towed Arrays • Submarine Maintenance Monitoring Program • Etc.

  25. MIMOSA • Maintenance Information Management Open Systems Alliance • Consortium of 50+ system integration providers, component vendors and end-users • MIMOSA addressing the interoperability deficiency in information integration and exchange. • Developing open specifications for all material condition information, not just CBM • MIMOSA goal to become an ISO Standard • SMMOA Selected MIMOSA as • a Candidate Navy OMCI Standard

  26. Engineering Units Transducer Types Data Source types Measurement Location Types Fixed Reference Data Segments - ESWBS Assets – EC/LAPL/APL Navy Specific Reference Data Assets on Segments – CMDM-OA Measurement Locations – ICAS CDS, VTAGS, Thermographic Routes, Etc. Ship Specific Reference Data Pressures Temperatures Vibration Signatures Data Values MIMOSA Database Structure

  27. OMCI ServerDemonstrator OSA-CBM Server Initial Agreement PS/ARL Lab Server Initial Agreement TOSA MIMOSA Demo Server CRIS CRIS CRIS CRIS ICAS Server Pending Agreement Predict/DLI Server Initial Agreement Goal: Demonstrate Information Interoperability

  28. Open Logistics Support Interface (OLSI)

  29. New Support Paradigm “TOSA Enabled” Acquisition (Year 2010) Navy Design Navy CM Control Full Data Disclosure Stable Technology Stable Supplier Support Bit &Piece Maintenance Organic Support Vendor Design/CM Control Limited Data Disclosure Limited Supplier Stability Rapid Technology Change COTS Acquisition (Mid 90’s) Performance Based Contracting Multiple Suppliers Rapid Tech Insertion TOSA Interface Specs Condition Based Maintenance Global Information Grid Legacy MILSPEC Support System Modular Maintenance Organic/Contractor mix

  30. 6 JOPES JTAV GTN SARSS WPS Network CentricLogisticsEnvironment OLSI Vision OPERATIONS LOGISTICS C2 Integrated Real-Time Situational Awareness INTELLIGENCE VADM Holder Director of Logistics The Joint Staff

  31. Logistics Requirements • Reduced Manning • Necessary to automate Logistics • Ability to seeassets while in storage or transit • Streamlined Acquisition & Tracking Management • Increase Operational Readiness • Accountability for necessary items • Ability to obtain items from multiple sources • Utilize Open Standards • Increased Life Cycle Support • Reduced Total Ownership Costs • Interoperability between different systems

  32. OLSI Goals • Integrate supply support with material condition monitoring and maintenance data bases to enable exchange of data and interoperability • Advance the use of open standards for critical interfaces • Enhance asset visibility to reduce cost and enhance readiness • Automate supply chain management through use of Material Handling Equipment and Automatic Identification technologies Leverage industrial and government best practices, new technology, and emerging standards

  33. Market Surveillance& Technology Projection • Universal Identification (UID) part marking • Universal Identification Code • Smart stores/smart shelves • Radio Frequency Identification (RFID) • Ultra Wide Band (UWB) • Serial Number Tracking • Data Matrix Symbology • Contact Memory Buttons • AIT networks • Material handling equipment

  34. OLSI’s Use ofOpen Standards • Review and evaluate evolving standards for AIT, inventory management, MHE, storage & transportation • Become involved in standards development • Better interoperability between systems • Insure various Logistics systems communicate with each other • From hand-held bar-code readers & CMBs to databases to communications systems

  35. Integrated Supply, Maintenance, and Monitoring Workflow Shore facilities Ship Monitoring Data collection (OSNI) Trend analysis (CBM, OSNI) Identify material degradation or pm requirement (OMCI) Maintenance planning Estimate repair resources (OMCI) Determine sources of supply (OMCI) Set priority (OMCI) Supply chain management Acquire parts (OLSI) Ship/transport parts (OLSI) Track Parts (OLSI) Detect P Supply chain management Initiate requisition (OLSI) Process & approve requisition (OLSI) Maintenance execution Part installation & checkout (OMCI)

  36. RAPID RESPONSE ILS ScenarioMajor Unplanned Maintenance ENCODED VENDOR A CBM ONBOARD VENDOR B CONDITIONED BASED MAINTENANCE SURVEILLANCE TEAM VENDOR C IN PLACE CONTRACTS Global Readiness Center Rapid Response Team

  37. Conclusion • SMMOA is a Prime Concern for Navy’s future • Future Manning requires better use of technology for monitoring, maintenance and supply • Open Standards should be developed/used for interfaces • Need risk mitigation on candidate Open Standards • Need to reach common Agreements & Strategies • Consensus set of Standards for SMMOA • Open Sensors, Databases and Supply & Logistics management • Promulgate these standards to Naval and Industry Systems Integration Teams

  38. SMMOA Contacts David Perrussel SMMOA Lead/OSNI Lead (540) 653-6820 PerrusselDB@nswc.navy.mil Win Royce OMCI Lead (301) 227-7632 RoyceWW@nswccd.navy.mil Sam Judge OLSI Lead (301) 227-3673 JudgeSD@nswccd.navy.mil Jack Abbott TOSA IPT Lead/BlueSky DDX (301) 227-7631 AbbottJW@nswccd.navy.mil Contact Information

  39. Backup

  40. TOSA Industry-Navy Integrated Product Team Steering Committee R&D Community Customers Acquisition Programs Design Community IPT Marine Engineering Shipbuilders Commercial System Vendors System Integrators (Defense) Industry Logistics Community

  41. Open Systems Mil-Std 200 ton A/C Plant OSA Examples Closed Systems A/V-8B Avionics Direct Drive Propulsion UYK-44 Joint Strike Fighter UYQ-70 Chilled Water Module Advanced Food Service Ship Habitability Modules Ship/UAV Interface

  42. Background/Initial Research • Began with a comprehensive market surveillance of CBM programs and projects • Identified key players and key programs in the CBM arena • Identified standards bodies and standards development work with potential TOSA implications • Established contacts/working relationships with key CBM programs, projects, and companies • Commercial companies • Navy R&D projects • Other military service programs • Universities involved in CBM

  43. OMCI Work Flow Sensor Data (OSNI) Organize data per schema Establish client/server interoperability Transmit/receive data Collect Data Identify critical systems/ conditions Perform CBM on data Project life/failure probability Analyze faults Modify operations/ Initiate maintenance action/ Issue work order Obtain resources, order parts, etc. To OLSI

  44. Segments Assets GE LM2500 Model112 Serial 76132910 Propulsion Plant Propulsion Units Propulsion Gas Turbines Propulsion Gas Turbines, Support Systems Propulsion Gas Turbines, Main Asset On Segment GT Start Air GTM1A GT LOF&S GTM1B Measurement Locations Compressor Discharge Pressure Cooling Air Outlet Temperature MIMOSA Database Structure

  45. MIMOSA Implementation Issues • MIMOSA is the gatekeeper for the fixed reference tables • We need a gatekeeper for the Navy specific reference tables • MIMOSA DB’s ship and shore have to be maintained as ship configuration changes • Application software is needed to simplify setup of the MIMOSA database • Hooking up real-time data acquisition to demo server • 1451 demonstrator • PS ARL • Predict DLI • ICAS

  46. MIMOSA Interfaces • MIMOSA defines interfaces for the following “technologies” • Trend – static values (pressure or temperature and alarm values) • Dynamic – spectral values (vibration, ultrasonic, electric current) • Sample – fluid tests such as oil analysis or gas tests • BLOB (binary large objects) – graphic files (thermographic or digital camera images) • Diagnostic – text values (diagnostics and recommendations) • Reliability – FMEA information • Registry – asset management information • Work – work management information • MIMOSA Compliance is determined on a technology by technology basis • Not all applications use all “technologies “

More Related