A testcase framework for the PLCS-IF

1. A testcase framework for the PLCS-IF Ben Kassel Naval Surface Warfare Center Carderock Division Distribution Statement A : Approved For Public Release; Distribution is unlimited

2. Part & System Definition (Caterpillar 3512, Starboard Main Engine, Propulsion System) Design Definition (12 cylinder 4 stroke diesel engine ) Physical (Geometry, material connections, etc.) Engineering Definition (1175 HP, 6464kg, 170mm bore, 190mm stroke) Process Definition (Starting instructions, shaft alignment) Logistics Support (FGC, SCLSIS, etc.) Digital Product Model Data A brief review Product Model data is the combination of 3D geometry and non-graphic attributes to define ship objects such as a piece of equipment, deck, bulkhead, etc. Product Model data can be organized to define interim products and ultimately the entire ship. Advocates anticipate substantial economies from Product-Model-based design, construction, and service-life support activities due to better integration and reduction of engineering effort to locate, verify, and transform information.

3. Digital Product Model Data … its more than just design and construction The DPM should be the primary source of data for all pre milestone B activities. The DPM should be used by NAVSEA to validate the design during the Detail Design and Ship Production phases. The DPM should be the authoritative source of data in support of the Situation Incident Room upon delivery of the ship. The DPM should be the authoritative source of data for technical manuals, training. The Digital Product Model can support the entire ship’s lifecycle.

4. Uses of the Digital Product Model Rear Admiral Eccles affirmation

5. NAVSEA Instruction 9040.3A Acquisition and Management of Product Model and other Technical Data Ship and ship system design, acquisition, and fleet support activities shall procure and accept product model data in accordance with ISO 10303, Standard for the Exchange of Product model data (STEP) format, native Computer Aided Design (CAD) files, and/or Leading Edge Architecture for Prototyping Systems (LEAPS) format. This should be based on solutions that provide the best technical and cost performance as determined by a NAVSEA business case analysis. Provide guidance for the acquisition of product model and related technical data. This instruction applies to product models and technical data derived directly from the product model such as engineering analysis, bills of material, and drawings. This instruction implements the DON POLICY ON DIGITAL PRODUCT/TECHNICAL DATA issued in 2004 and the NAVSEA SHIP DESIGN AND TOOLS GOALS issued in 2008. This instruction does not specify a format explicitly, but instead requires Navy stakeholders to reach consensus on the definition and delivery of product model data. Balances cost, data utility, and data exchange technology.

6. Product Model Data Definition and Exchange A NAVSEA perspective A two level approach for the exchange of product model data First level : Second level : Support configuration management, logistics support, provisioning, spares, and repairs through the use of STEP for geometry, product structure, non graphical attributes, and to manage configuration items of the as-built / as-maintained ship. Deliver the as-designed class model of • molded forms suitable for defining a general arrangement • scantling level of detail of structure to support structural (and other types of) analysis • functional distributed systems model (i.e. path, components, and connections) • compartmentation, including accesses, opening, and tightness • plates, stiffeners, brackets, collars, and other structural components as parts • distributed system components, fittings, and equipment as parts.

7. Implementing the Policy Ships Specification 098 – 3D Product Model The Digital Product Model shall be delivered in both a native and neutral format. The neutral format shall comply with the Department of the Navy Policy on Digital Product/Technical Data dated 23 October 2004. ISO 10303 Part 214 shall be used to define the Digital Product Model geometry. ISO 10303 Part 239 shall be used to define product structure, the relationship between objects, and configuration management data. The Builder shall provide a list in the PPM1 of each data exchange specification (DEX) that will be used to support the ISO Part 239 exchange. In the event the contractor can demonstrate the need for an additional DEX, then the contractor shall develop a NAVSEA approved DEX. 1 Process and Procedures Manual

8. Archiving Ship Product Model Data Mining ShipConstructor Product Model Definition EXTRACTED GEOMETRY NATIVE ShipConstructor® DATA EXTRACTED NON-GRAPHICAL ATTRIBUTES

9. A testcase framework for PLCS-IF Test case ultimate depth and breadth

10. A testcase framework for PLCS-IF A small distributed system Electrical Components ● Mechanical Components ● Piping Components Systems ● Subsystems ● Assemblies

11. A testcase framework for PLCS-IF A sample USE case (Product Operational Information) The useful life of gate valves used in fuel oil service is 20 years. Gate valves between 10 and 20 years old should be inspected periodically, and their condition reported. This is not a critical issue so the repair does not need to be made immediately. However, planning is required to purchase new seals or replacement valves depending on their condition. From the product model repository Attributes to support USE case Ship Hull Number Date put in service Location Availability System Attributes Type (SWBS?) Fluid Type Part Attributes Seal type Model number Serial number Seal material Install date Overhaul date Size Monitor Gate Valve condition 1. Locate all of the valves in fuel oil service 2. Determine the date the valve was placed in service 3. If the valve is more than 20 years old flag it to be replaced 4. If the valve is between 10 and 20 years old, issue a service bulletin to inspect for signs of seepage and report back 5. For all reports that indicate seepage, schedule valve replacement during the next scheduled maintenance period 6. Determine the next time the ship has maintenance scheduled 7. For all reports that indicate no problem make a notation in the ships maintenance logs

12. A testcase framework for PLCS-IF Scope like stuff Provide sufficient data to develop a product model and collect all the “other technical data” necessary to perform the aforementioned task. The test shall be of sufficient breadth and depth that the output products required to support the aforementioned tasks can be generated automatically from the product data. Additionally, there will be sufficient information to associate the other technical data to the product data and to allow simultaneous configuration management of the product data and other technical data. The test case was developed to exercise Parts Assemblies Systems Configuration Management Multiple product structures Workflow Revision control Parts placed in a system Parts placed in an assembly Assemblies placed in a system Systems divided into subsystems The test case includes information required to Design the system Develop the work package to assemble a system Purchase components Maintain the system Repair the system Operate the system

13. A testcase framework for PLCS-IF Bill of Material (well almost)

14. A testcase framework for PLCS-IF Systems of Parts

15. A testcase framework for PLCS-IF Assemblies of Parts

16. A testcase framework for PLCS-IF Parts Libaries

17. A testcase framework for PLCS-IF Catalogs

18. A testcase framework for PLCS-IF Drawings

19. A testcase framework for PLCS-IF Ordering Information

20. A testcase framework for PLCS-IF Configuration Management 20

21. A testcase framework for PLCS-IF Configuration Management 21

22. A testcase framework for PLCS-IF Connections and Connectors distJoint_5 distJoint_6 distJoint_7 distJoint_8 J03 J04 distPort_20 distPort_23 V01 distPort_22 distPort_62 J05 distPort_63 distPort_24 J06 distPort_25 distPort_26

23. A testcase framework for PLCS-IF Connections and Connectors J15 P06 P06 Port 2 J15 Port 2

24. A testcase framework for PLCS-IF Ports