Developed under NSRP ASE ISE-6
Technology Investment Agreement (TIA) 2007-379
Integrated Shipbuilding Environment Consortium (ISEC)
Integrated
Shipbuilding
Environment
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Document Number
ISE-6-TEAM-0001
Version 2.0
Submitted by:
Dr. Burton Gischner
Electric Boat Corporation
Submitted on:
2007-08-13
Approved for public release; distribution is unlimited.
Government Purpose Rights
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
TABLE OF CONTENTS
1
2
3
4
INTRODUCTION
3
1.1
Overall ISE Project Goals
3
1.2
ISE-6 Participants
3
1.3
ISE-6 Objective
4
1.4
Document Scope
5
NOMENCLATURE
6
2.1
Acronyms and Abbreviations
6
2.2
Definitions
9
LIFE CYCLE SUPPORT BUSINESS PROCESSES
11
3.1
Summary of Use Cases
16
3.2
Life Cycle Support Business Process for IPDE Data Exchange
17
DEFINITION AND DESCRIPTION OF EACH USE CASE
18
5 RELATIONSHIP OF PLCS USE CASES TO AP239 APPLICATION ACTIVITY
MODEL (AAM)
6
24
5.1
Comparison of Models
24
5.2
Mapping of ISE-6 Use Cases to AP239 AAM Diagrams
24
5.3
AAM Diagrams and Explanations
26
SUMMARY
ISE-6-TEAM-0001
53
Page 2 of 53
Enabling Shipyard Interoperability
1
INTRODUCTION
1.1
Overall ISE Project Goals
ISE-6 Product Life Cycle Support Use Cases
The Integrated Shipbuilding Environment Consortium (ISEC) was formed in 1999 as a consortium of
several major shipyards and CAD vendors with the goal of developing an information interoperability
capability for U.S. Naval shipbuilding.
ISEC has addressed these interoperability issues in a series of NSRP (National Shipbuilding Research
Program) Projects known as the Integrated Shipbuilding Environment (ISE). The NSRP Advanced
Shipbuilding Enterprise (ASE) was established in 1998 as collaboration of eleven shipyards with Navy
and other federal agencies. It has attempted to solve interoperability and data exchange issues by
awarding various projects over the past eight years to this consortium of shipyards, CAD vendors, and
universities. The projects awarded by NSRP in this area are known informally as: HARVEST, ISPE,
ISE-1, ISE-2, ISE-3, ISE-4, ISE-5, and ISE-6 and they have successfully attacked various phases of the
interoperability problem.
The HARVEST Project completed the STEP Shipbuilding Structural Application Protocols (AP215,
AP216, and AP218) and secured their approval as International Standards (IS). ISPE determined the
requirements for exchanging steel processing product model data in a shipyard independent format.
ISE-1 outlined the requirements and architecture for an interoperability solution. ISE-2 implemented that
solution in the structural and piping disciplines. ISE-3 continued these implementations in the HVAC
and Common Parts Catalog (CPC) interface areas. ISE-4 focused on the areas of Ship Arrangements,
Steel Processing, Engineering Analysis, and Electrical.
ISE-5 continued development and
implementation in the electrotechnical area.
The ISE Consortium is continuing its efforts at developing tools for product data interoperability under
the current NSRP ASE Project for “Enabling Shipyard Interoperability” (ISE-6). This project will run
from March 2007 through March 2009 and is extending the ISE work to Product Life Cycle Support
issues as well as continuing to support the ISE Team’s participation with the International Organization
for Standardization (ISO) and the Navy’s DONXML activities.
1.2
ISE-6 Participants
ISE-6 – Enabling Shipyard Interoperability is an NSRP ASE sponsored, industry led project under the
auspices of the Integrated Shipbuilding Environment Consortium (ISEC). This program is a
collaborative effort that includes several U.S. shipyards, software vendors, and research institutions. The
term “shipyard” is used to mean not only the commercial shipyards, but also the “virtual” shipyard
represented by the U.S. Navy and the NAVSEA CAD-2 program.
The ISE-6 Team is led by Electric Boat Corporation (EB) with members from the following
organizations:








Northrop Grumman Ship Systems (NGSS)
Atlantec Enterprise Solutions (AES)
Industrial Planning Technology (IPT)
Intergraph Corporation (INGR)
Knowledge Systems Solutions, Inc. (KSS)
Naval Surface Warfare Center - Carderock Division (NSWCCD)
Product Data Services Corp. (PDS)
ShipConstructor Software, Inc. (SSI)
ISE-6-TEAM-0001
Page 3 of 53
Enabling Shipyard Interoperability
1.3
ISE-6 Product Life Cycle Support Use Cases
ISE-6 Objective
The objective of the ISE-6 Project is to prototype and evaluate the use of international standards and the
ISE interoperability architecture in the realm of ship’s life cycle support and post-delivery operations.
The project will identify and document the Use Cases and scenarios that apply to data required for postdelivery support and operations, both on shore and on ship. Information requirements will be derived
from the Use Cases and will be documented in XML form in accordance with the ISE methodology. The
project will prototype the ability to manage the identified information elements and will demonstrate that
life cycle support information can be shared among software applications – using the ISE XML neutral
formats. The prototypes will demonstrate a Web-based integration architecture that could be applied to
systems on-board the ship as well as shore-based repair and maintenance systems. This architecture and
consequent prototypes will be based upon the international standard for Product Life Cycle Support
(PLCS) data (ISO 10303-239) and on the S1000D standard for XML-based technical documentation.
In previous projects, the ISE Team has utilized a suite of STEP Application Protocols (APs) to transfer
product model data in various disciplines. These include:








ISO 10303-203: AP for Configuration Controlled Design
ISO 10303-209: AP for Composite and Metallic Structural Analysis and Related Design
ISO 10303-212: AP for Electrotechnical Design and Installation
ISO 10303-214: AP for Core Data for Automotive Mechanical Processes
ISO 10303-215: AP for Ship Arrangement
ISO 10303-216: AP for Ship Moulded Forms
ISO 10303-218: AP for Ship Structure
ISO 10303-227: AP for Plant Spatial Configuration
While these application protocols cover a rich set of product model data, the focus of all of them is on
exchanges in the areas of design, analysis, and manufacturing. The operational and maintenance data
requirements for product life cycle support necessitate the use of an additional AP developed to meet
these requirements, ISO 10303-239: AP for Product Life Cycle Support.
There are several different approaches used in implementing STEP, and as in previous projects, the ISE
architecture will be flexible and accommodate a variety of implementation techniques. Traditionally
when STEP is used for product data exchange, the translators produce a neutral data representation
known as a STEP physical file, or a Part 21 file. Some of the ISE-6 prototype translators will produce
files in this format. However, with the growing use of the Internet and the World Wide Web, a new
STEP format has been developed, called Part 28, which utilizes XML structures to encapsulate the STEP
data.
Processors will be developed during the ISE-6 Project to convert the Part 21 files into XML-based Part
28 files to enable interactive exchanges of PLCS data using the Web. Mediator programs will also be
available to go in the other direction, converting XML-based Part 28 files into the more traditional Part
21 format. Thus some of the ISE-6 – PLCS translators will produce files in Part 21 format while others
will create Part 28 files, but the previously mentioned processors and mediators developed under the ISE
Project will be made publicly available and will enable file conversion between Part 28 and Part 21
formats.
The intent of the ISE-6 Project is to define an information model that encompasses the full range of
logistics data and products, with linkage back to the associated engineering data and drawings. This
equates to the term APSI in the ANSI standard EIA-649-A. What is difficult for shipyards, Participating
Managers (PARMs), and other entities providing life cycle support is managing the collection of logistics
ISE-6-TEAM-0001
Page 4 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
and engineering data in a coherent fashion. Not the least difficulty is that the logistics data and products
typically reside in a large number of independent software systems.
1.4
Document Scope
The purpose of this document is to identify and document the Use Cases and scenarios that apply to data
required for post-delivery support and operations, both on shore and on ship. For each Use Case, it will
be indicated if these activities apply to Ship Acquisition, or Ship Alterations, or both. The information
created in the Use Cases for design new construction can later be used for post-delivery support and
operations. Information requirements will be derived from these Use Cases and will be documented in
XML form in accordance with the ISE methodology.
The PLCS standard contains an Application Activity Model (AAM), which captures life cycle support
activities. However this is a very high level model, which does not adequately capture the specific
activities performed by shipyards and the Navy while executing post-delivery support and operations.
These specific shipbuilding activities must be defined for the resulting information models to truly
integrate shipyard and Navy software systems.
This document defines a set of shipbuilding Use Cases that define activities performed by the shipyards
and the Navy for Product Life Cycle Support pertaining to Ship Acquisition (Design New Construction).
Another set of shipbuilding Use Cases is specified to deal with Ship Alterations and life cycle support.
These were developed based upon the experience and expertise of the participating shipyards and the
ISE-6 Team.
In this document, we will refer to the data defined during the ship acquisition process that is required for
post-delivery support and operations simply as logistics data and products. This includes drawings,
models, and training materials as well as the configuration baseline of the ship. ANSI Standard
EIA-649-A describes these logistics data and products as Product Configuration Information (PCI) which
includes both Product Definition Information (PDI) and Product Operational Information (POI).
Traditionally, logistics data and products are defined by an Integrated Logistics Support (ILS)
organization. Often, separate ILS organizations exist for ship acquisition and life cycle support. In this
document, we will present Use Cases arising from both groups’ activities.
The approach taken in this document is to define the overall business process for the definition,
development, and delivery of logistics products. The specific steps within the business process are
decomposed into individual Use Cases. Finally, the Use Cases are mapped back into the general AP239
AAM.
ISE-6-TEAM-0001
Page 5 of 53
Enabling Shipyard Interoperability
2
NOMENCLATURE
2.1
Acronyms and Abbreviations
ISE-6 Product Life Cycle Support Use Cases
AAM:
Application Activity Model
AEL:
Allowance Equipage list
AES:
Atlantec Enterprise Solutions
ANSI:
American National Standards Institute
AP:
Application Protocol: Documents that specify the format for representing product data
within a set of related processes or activities
APL:
Allowance Parts List
APSI:
Assured Product and Support Information
AP203:
ISO 10303-203: AP for Configuration Controlled Design
AP209:
ISO 10303-209: AP for Composite and Metallic Structural Analysis and Related Design
AP212:
ISO 10303-212: AP for Electrotechnical Design and Installation
AP214:
ISO 10303-214: AP for Core Data for Automotive Mechanical Processes
AP215:
ISO 10303-215: AP for Ship Arrangement
AP216:
ISO 10303-216: AP for Ship Moulded Forms
AP218:
ISO 10303-218: AP for Ship Structure
AP227:
ISO 10303-227: AP for Plant Spatial Configuration
AP239:
ISO 10303-239: AP for Product Life Cycle Support
ASE:
Advanced Shipbuilding Enterprise program of the NSRP
CAD:
Computer Aided Design
CDMD-OA:
Configuration Data Manager Database – Open Architecture
CI:
Configuration Item
CK:
Charlie Kilo
CMRM:
Configuration Management Reference Material
COSAL:
Coordinated Shipboard Allowance List
CPC:
Common Parts Catalog
CPP:
Computer Program Packages
CWI:
Configuration Worthy Item
DEX:
Data Exchange Set
DoD:
Department of Defense
DONXML:
Department of Navy XML Repository created to provide guidance for use of Extensible
Markup Language in a standardized way
ISE-6-TEAM-0001
Page 6 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
EB:
Electric Boat Corporation
EFD:
Equipment Functional Description
EIA-649-A:
ANSI Standard for: Configuration Managememt
EIA-836:
ANSI Standard for: Configuration Management Data Exchange and Interoperability
ESWBS:
Expanded Ship Work Breakdown Structure
EXPRESS:
A formal data specification language that specifies the product information to be
represented
FAA:
Federal Aviation Administration
FMP:
Fleet Modernization Process
FSI:
Functionally Significant Item
GFI:
Government Furnished Information
HARVEST:
NSRP Project to complete STEP Shipbuilding Structural Application Protocols
HSC:
Hierarchical Structure Code
IDEF0:
Integration Definition for Process Modeling
ILS:
Integrated Logistics Support
INGR:
Intergraph Corporation
IPDE:
Integrated Product Data Environment
IPT:
Industrial Planning Technology
IS:
International Standard
ISE:
Integrated Shipbuilding Environment Project
ISEC:
Integrated Shipbuilding Environment Consortium
ISO:
International Organization for Standardization
ISPE:
Integrated Steel Processing Environment Project
KSS:
Knowledge Systems Solutions, Inc.
LSA:
Logistics Support Analysis
LSAR:
Logistics Support Analysis Record
MAMS:
Maintenance Assistance Modules
MRC:
Major Repairable Component
NAVSEA:
Naval Sea Systems Command
NGSS:
Northrop Grumman Ship Systems
NSRP:
National Shipbuilding Research Program
NSWCCD:
Naval Surface Warfare Center - Carderock Division
PARM:
Participating Manager
Part 21:
ISO 10303-21: STEP Implementation Method - Clear Text Encoding of Exchange
Structure
ISE-6-TEAM-0001
Page 7 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Part 28:
ISO 10303-28: STEP Implementation Method - XML representation for EXPRESSdriven data
PCI:
Product Configuration Information
PDI:
Product Definition Information
PDS:
Product Data Services Corporation
PLCS:
Product Life Cycle Support
PIF:
Product In Focus
PMS:
Planned Maintenance System
POI:
Product Operational Information
RIC:
Repairable Identification Code
RMA:
Reliability Maintenance Analysis
SCLSIS:
Ship Configuration and Logistics Support Information System
SCM:
Software Controls Manual
SSI:
ShipConstructor Software, Inc.
STEP:
STandard for the Exchange of Product Model Data: It is the familiar name given for the
international standard ISO 10303 Industrial Automation Systems and Integration Product Model Representation and Exchange. The objective is to provide a mechanism
that is capable of describing product model data throughout the life cycle of a product.
The standard is a collection of parts, each published separately.
SWP:
Software Programs
S1000D:
International Specification for the Procurement and Production of Technical Publications
TIA:
Technology Investment Agreement
TDMIS:
Technical Data Management Information System
TOC:
Total Ownership Cost
VFI:
Vendor Furnished Information
XML:
Extensible Markup Language
ISE-6-TEAM-0001
Page 8 of 53
Enabling Shipyard Interoperability
2.2
ISE-6 Product Life Cycle Support Use Cases
Definitions
Charlie Kilo (CK)
A record of the ship reporting back as to what work has been done as part of a ship alteration.
Configuration Item (CI)
A collection of objects related to the specific functionality of a larger system. Examples of these
objects may be requirements, code, documentation, models, and other files. Configuration
Management systems oversee the life of the CIs through a combination of process and tools.
The objective of these systems is to avoid the introduction of errors related to lack of testing or
incompatibilities with other CIs.
A Configuration Item (CI) can be differentiated from a Configuration Worthy Item (CWI) in that:

a CWI is terminology to translate what is in the design and requires support (initial
determination of a CI)

the CI typically means the actualization of the item onto the ship with its support
Configuration Worthy Items (CWI)
A Configuration Worthy Item (CWI) is defined as any item that requires maintenance or logistic
support during its life cycle.
An item is considered configuration worthy if it meets one or more of the following criteria:
a.
Any item that requires any one of the following elements of logistics: Planned
Maintenance System (PMS), Software Programs (SWP), Software Controls Manual
(SCM), Computer Program Packages (CPP), Maintenance Assistance Modules
(MAMS), or intermediate/depot level maintenance plans or drawings.
b.
Any hardware, software or firmware item required to describe a ship’s functional
hierarchy.
c.
Any clearly identifiable functional assemblies such as pump/motor combinations.
d.
Any electronic functional groups.
e.
Any system or equipment requiring maintenance.
f.
Any Computer Aided Design (CAD) item used in digital data exchange that is
identified separately from the associated software. These CAD items are the
components that are on the drawings or models which need to be supported
logistically.
Coordinated Shipboard Allowance List (COSAL)
The allowance list of spare parts carried onboard the ship.
Data Exchange Set (DEX)
A subset of the overall PLCS information model that is suited for a particular business process. It
also includes usage guidance.
Expanded Ship Work Breakdown Structure (ESWBS)
A five character work breakdown structure, defined by the Navy, which establishes system
boundaries, system descriptions and functional nomenclature for an entire ship class. ESWBS
has many functions, one of them being to serve as a framework for categorizing each and every
item on a ship. The ESWBS is the basis for the development of Hierarchical Structure Codes
(HSC), used by the shipyard to identify all configuration worthy items on the ship.
ISE-6-TEAM-0001
Page 9 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Functionally Significant Item (FSI)
A Functionally Significant Item (FSI) is defined as an item whose failure would have a
significant impact on the availability of a required function or on life cycle costs. An FSI can be
a system, subsystem, equipment, or component, or a summary level of two or more FSIs. For life
cycle management purposes, an FSI is any item that requires any element of logistic support for
which configuration information is needed to operate or maintain the ship that is needed to fully
describe the functional hierarchy of the ship itself down to the lowest level subassembly.
A Functionally Significant Item (FSI) can be considered as an equivalent term to Configuration
Worthy Item (CWI).
Product Configuration Information (PCI)
The term used by the current configuration standards. It is synonymous with the older term
Configuration Status Record and the PLCS term Assured Product and Support Information
(APSI). PCI is produced and managed by the process of Configuration status Accounting. It lists
all product and configuration information for each approved baseline. PCI includes both Product
Definition Information (PDI) and Product Operational Information (POI).
Product Definition Information (PDI)
A synonym for product attributes, configuration documentation, design basis, design information,
design output, engineering drawing, interface control document, interface document, requirements
document, software requirements specification, software design document, software product
specification, or specification.
Product Life Cycle Support (PLCS)
The methodology to handle the life cycle concerns of a component. The methodology handles
hazard (environmental) issues, configuration management, logistics issues, ship specifications,
maintenance engineering, and supply support.
A STEP Application Protocol (ISO 10303-239:2004) has been adopted as an International
Standard to be used for PLCS product model exchanges.
Product Operational Information (POI)
A synonym for product operation and maintenance instructions and other derived information,
operational information, technical manual, or technical order.
Ship Configuration and Logistics Support Information System (SCLSIS)
The Navy standard for logistics systems.
Use Case
A description of a set of sequence of actions performed by a system and initiated by an actor. It is
used to capture the functional requirements of a system.
ISE-6-TEAM-0001
Page 10 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
3 Life Cycle Support Business Processes
The overall Business Process for Life Cycle Support during Ship Acquisition is shown below in Figure 1.
The diagram notionally illustrates the overall process, major participants, and major data flows. This
diagram represents the viewpoint of an ILS organization and does not show all the relationships between
the entities. (For example, supplier VFI is not shown as input to detailed design.) However, the
relationship between design data and ILS is explicitly detailed. Use Cases are explicitly identified where
appropriate, otherwise major ILS activities are further decomposed into specific Use Cases in Figures 3-6
as indicated.
Drawings &
Prod. Data
Define ILS
Approach
(Use Case 19)
Part Usage
Analysis
(See Figure 6)
System Diagrams & Specs
Supportability
and TOC
Analysis
(Use Case 15)
Configuration
Identification
(See Figure 3)
Specs
Procurement
Legend
Customer
Design / Eng
ILS
CWI
Components
Ship
System Design
Design Changes
Detailed Design
Drawings
Define Ship
Support Approach
(Use Case 18)
Production
Changes
Requirements
Ship
Contract
OEM
Components
Logistics Support
Analysis
(See Figure 5)
Logistics
Data
Purchase
Specs
Supplier
VFI
Changes
Shipyard
Configuration Status
Accounting
(See Figure 4)
Logistics
Products
& Configuration
Baseline
External
Navy System
Supplier
Ship
Delivery
GFE
Figure 1 – Overall Life Cycle Support Business Process for Ship Acquisition
ISE-6-TEAM-0001
Page 11 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
This overall process can be summarized as follows:













The contract is awarded, which provides the base requirements for the ship design and
logistics data and products.
The Navy refines their expectations and requirements for the life cycle support of the ship.
The shipyard and Navy ILS organizations define the specific approach and tools that will be
used for this ship contract within the bounds of the contract and the customer life cycle
support approach.
The ship design starts with a system design that defines the system components and their
functional properties. This information is specified in system diagrams and functional
specifications for components.
The supportability and Total Ownership Cost (TOC) of the components are analyzed and
additional specifications are generated.
Procurement utilizes the functional and support specifications to select a supplier.
Vendor Furnished Information (VFI) is provided by the supplier to define the specific
engineering, maintenance, and support properties of the component.
Detailed design develops the full ship design, drawings, and production data. Changes to the
design result from analysis results, design changes, production problems, or design problems.
Configuration worthy components are identified, based initially upon the system design and
later upon the detailed design and design changes. The details are shown in Figure 3.
Once a component has been identified as a Configuration Worthy Item (CWI) and a specific
supplier selected, a Logistics Support Analysis (LSA) is performed to develop the associated
logistics data and products. The details are shown in Figure 5.
The configuration of logistics data and products is maintained by Configuration Status
Accounting (CSA) processes. Newly developed data is added to the baseline. Design
changes are assessed and incorporated. The details are shown in Figure 4.
Government Furnished Information (GFI) is provided by the supplier of Navy systems, either
to the contractor or directly to the Navy. These suppliers are typically PARMs, under
contract to the program office.
The contractor delivers the drawings, configuration baseline and set of logistic products to
the Navy.
Note that each Navy system supplier follows the same process as the prime contractor, usually with the
exception of the last step (unless they are integrating other Navy systems or components).
The overall Business Process for Life Cycle Support during Ship Alteration is shown below in Figure 2.
As in the case of Figure 1, the diagram notionally illustrates the overall process, major participants, and
major data flows. This diagram represents the viewpoint of an ILS organization and does not show all
the relationships between the entities. Use Cases are explicitly identified where appropriate, otherwise
major ILS activities are further decomposed into specific Use Cases in Figures 3-5 as indicated.
ISE-6-TEAM-0001
Page 12 of 53
Enabling Shipyard Interoperability
Ship
Alteration
Contract
Develop Ship
Alteration
Package
ISE-6 Product Life Cycle Support Use Cases
Ship
Installation
Contract
SCD
Procurement
Configuration
Identification
(See Figure 3)
CWI
Components
Supplier
OEM
Components
Design
Changes
Fabrication of
Material
Logistics Support
Analysis &
Documentation
(See Figure 5)
Changes
Legend
Customer
Design / Eng
ILS
Shipyard
External
Develop Kitting
Plan
(Use Case #21)
Logistics
Data
& Docs
Kitting of
Material
LAR
Reverse LAR
Kits
Configuration
Status Accounting
(See Figure 4)
Logistics
Products &
Configuration
Baseline
Logistics
Products &
Configuration
Baseline
Logistics
Data
& Docs
Install Ship
Alt On Ship
Installation Status
Plan
Configuration
with ILS
Certification
(Use Case #22)
Report Ship
Alt Status
Update
Configuration with
Installed
Alterations
(Use Case #23)
Figure 2 – Overall Life Cycle Support Business Process for Ship Alteration
ISE-6-TEAM-0001
Page 13 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Configuration Identification
Identify
Identify Configuration
Configuration Worthy
Worthy
Items
Items
(Use
(Use Case
Case #2)
#2)
Classify
Classify Instances
Instances based
based on
on
Functionality
Functionality
(Use
(Use Case
Case #3)
#3)
Identify
Identify Hierarchy
Hierarchy Classification
Classification
for
for Functional
Functional and
and System
System
Designators
Designators
(ESWBS
(ESWBS Breakdown)
Breakdown)
(Use
(Use Case
Case #1)
#1)
Figure 3 –Configuration Identification Use Cases
Configuration Status Accounting
Initial Assessment for Configuration Changes
(Use Case #4)
Develop Planned Change
(Use Case #16)
Update Configuration Data & Support Products
(Use Case #5)
Release Configuration Data & Support Products
(Use Case #17)
Figure 4 –Configuration Status Accounting Use Cases
ISE-6-TEAM-0001
Page 14 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Logistics Support Analysis & Documentation
Develop Logistical Technical Data
(Use Case #6)
Develop Provisioning Technical Documentation Packages and
Assign Repairable Identification Code
(Use Case #7)
Perform Maintenance Planning Development
(Use Case #11)
Establish Stowage Requirements and Identify Locations
(Use Case #13)
Develop Training Tools and Documentation
(Use Case #14)
Figure 5 –Logistics Support Analysis & Documentation Use Cases
Part Usage Analysis
Perform Reliability Maintenance Analysis
(Use Case #8)
Perform System Safety Review
(Use Case #9)
Perform Human Factors Review
(Use Case #10)
Identify Environmental Concerns
(Use Case #12)
Perform Part Supportability and Life Cycle Cost Analysis
(Use Case #20)
Figure 6 – Part Usage Analysis Use Cases
ISE-6-TEAM-0001
Page 15 of 53
Enabling Shipyard Interoperability
3.1
ISE-6 Product Life Cycle Support Use Cases
Summary of Use Cases
The set of Use Cases for Life Cycle Support during Ship Acquisition and Ship Alterations, illustrated in
Figures 1-6 above, are summarized below. These two sets of Use Cases will be the basis of the context
schemas and exchanges to be developed during the ISE-6 Project.
In the table below, Use Cases that apply only to Ship Acquisition are indicated by Type = “Acquisition”,
while those Use Cases that apply only to Ship Alterations are indicated by Type = “Ship Alt”. Use Cases
that are applicable to both Ship Acquisition and Ship Alterations are indicated by Type = “Both”.
Life Cycle Support Use Cases for Ship Acquisition and/or Ship Alterations:
Type
1. Identify Hierarchy Classification for Functional and System Designators
Both
2. Identify Configuration Worthy Items
Both
3. Classify Instances Based on Functionality
Both
4. Initial Assessment of Change for Configuration Changes
Both
5. Update Configuration Data & Support Products
Both
6. Develop Logistical Technical Data
Both
7. Develop Provisioning Technical Documentation Packages and Assign
Repairable Identification Code
Both
8. Perform Reliability Maintenance Analysis
Acquisition
9. Perform System Safety Review
Acquisition
10. Perform Human Factors Review
Acquisition
11. Perform Maintenance Planning Development
Both
12. Identify Environmental Concerns
Acquisition
13. Establish Stowage Requirements and Identify Locations
Both
14. Develop Training Tools and Documentation
Both
15. Part Usage Requirements
Acquisition
16. Develop Planned Change
Both
17. Release Configuration Data and Support Products
Both
18. Define Ship Support Policy
Acquisition
19. Define ILS Approach
Acquisition
20. Perform Part Supportability and Life Cycle Cost Analysis
Acquisition
21. Develop Kitting Plan
Ship Alt
22. Plan Configuration with ILS Certification
Ship Alt
23. Update Configuration with Installed Alterations
Ship Alt
ISE-6-TEAM-0001
Page 16 of 53
Enabling Shipyard Interoperability
3.2
ISE-6 Product Life Cycle Support Use Cases
Life Cycle Support Business Process for IPDE Data Exchange
The Use Cases described above have focused on the business processes of life cycle support during ship
acquisition as well as for ship alterations.
Although these two scenarios provide the basis for the ISE-6 context schemas and have led to the Use
Cases defined in this project, it is felt that these are not ideal scenarios for the project demonstration
scheduled for March 2008. That demonstration will focus on life cycle support business processes that
represent exchange between multiple Integrated Product Data Environments (IPDEs). This scenario is
illustrated in Figure 7 and will be executed in the ISE-6 Demo.
The Use Cases described in Figure 7 are a subset of those from the previous two scenarios, so the
demonstration will not require any new schema development.
User C View Data
User A Creates
IPDE Data and
Stores in System
Ship Acquisition
Use Cases
(See Figure 1)
User A
Data Store
User B Extracts
Data for Use
Use Case # 5
Update
Configuration Data
and Support
Products
User B
Data Store
Use Case # 17
Release
Configuration Data
and Support
Products
User C
Resynchronization
of Data
Use Case # 23
Update
Configuration with
Installed Alterations
User D Extracts
Data
Use Case # 5
Update
Configuration Data
and Support
Products
User D
Data Store
User D Updates
Data
Use Case # 16
Develop Planned
Change
Figure 7 - Overall Life Cycle Support Business Process for IPDE Data Exchange
ISE-6-TEAM-0001
Page 17 of 53
Enabling Shipyard Interoperability
4
ISE-6 Product Life Cycle Support Use Cases
DEFINITION AND DESCRIPTION OF EACH USE
CASE
Use Case #1 -
Identify Hierarchy Classification for Functional and
System Designators
Develop the hierarchy classification for functional and system designators. This is done by selecting the
appropriate Expanded Ship Work Breakdown Structure (ESWBS) code from the Users Guide for
Expanded Ship Work Breakdown Structure (ESWBS) for All Ships and Ship/Combat Systems. The
ESWBS is a work breakdown structure, utilizing a five character numbering system, to identify
functional areas, systems, and major components. Systems to be included on the ship should be specified
by the Navy (not all ESWBS groups are used on all ships). The ESWBS is the basis for the Hierarchical
Structure Code (HSC), developed later to classify all Configuration Worthy Items (CWI).
The top level ESWBS is shown below in Table 1. An example ESWBS breakdown structure is shown in
Table 2.
Table 1 – Top Level ESWBS Breakdown
ESWBS
Equipment Functional Description (EFD)
10000
HULL STRUCTURE, GENERAL
20000
PROPULSION PLANT, GENERAL
30000
ELECTRIC PLANT, GENERAL
40000
COMMAND AND SURVEILLANCE, GENERAL
50000
AUXILIARY SYSTEMS, GENERAL
60000
OUTFIT AND FURNISHINGS, GENERAL
70000
ARMAMENT, GENERAL
Table 2 – Example of a Specific ESWBS Breakdown Structure
ESWBS
Equipment Functional Description (EFD)
51500
AIR REVITALIZATION SYSTEMS
51510
CO/H2 BURNERS
51511
CO/H2 BURNER - NO. 1
51512
CO/H2 BURNER - NO. 2
ISE-6-TEAM-0001
Page 18 of 53
Enabling Shipyard Interoperability
Use Case #2 -
ISE-6 Product Life Cycle Support Use Cases
Identify Configuration Worthy Items
Based on design models and system diagrams, identify component instances that are configuration
worthy. A Configuration Worthy Item (CWI) is defined as any item that requires maintenance or logistic
support during its life cycle.
An item is considered configuration worthy if it meets one or more of the following criteria:
a. Any item that requires any one of the following elements of logistics: Planned Maintenance
System (PMS), Software Programs (SWP), Software Controls Manual (SCM), Computer
Program Packages (CPP), Maintenance Assistance Modules (MAMS), or intermediate/depot
level maintenance plans or drawings.
b. Any hardware, software or firmware item required to describe a ship’s functional hierarchy.
c. Any clearly identifiable functional assemblies such as pump/motor combinations.
d. Any electronic functional groups.
e. Any system or equipment requiring maintenance.
f.
Any Computer Aided Design (CAD) item used in digital data exchange that is identified
separately from the associated software. These CAD items are the components that are on the
drawings or models which need to be supported logistically.
Use Case #3 -
Classify Instances Based on Functionality
Assign each instance of a CWI a unique HSC classified by system within the functional area. The HSC
is an indenturing code of up to 12 characters, which identifies the functional/hierarchical relationship of
the ship, ship systems, and equipment configuration records. HSC is typically defined for the entire ship
class.
Associated with each HSC is an Equipment Functional Description (EFD) which provides a unique
functional description of the component.
Further breakdown of the component is possible, to support subcomponents identified as configuration
worthy.
HSC Guidelines:

The first five characters: Positions 1-5 must be in the accordance with the Master Default
ESWBS file (available in the reference section of the CDMD-OA Database and the
Configuration Management Reference Material (CMRM) websites).

The sixth through the twelfth characters: The seven digit character sequence, which follows the
ESWBS, breaks the equipment into subsystems, components, assemblies and subassemblies.
Valid values for each of the last seven characters include combinations of digits “0-9” and
characters “A-Z”, excluding the characters “O” and “I”. Typically, two alpha characters in the
sixth and seventh position denote the functional group of the component (i.e. “DH” is a valve).
ISE-6-TEAM-0001
Page 19 of 53
Enabling Shipyard Interoperability

ISE-6 Product Life Cycle Support Use Cases
Usage note:
o
For equipment, the structure starts with the highest-level equipment followed by lower
components in functionally related groups.
o
For piping systems, the structure starts with the source to the demand consistent with the
system diagrams, indenturing at major components and services.
o
Components may also be split into different groupings according to component types,
e.g. globe valves, butterfly valves, etc.
The ESWBS breakdown example given in Table 2 is extended to illustrate an HSC breakdown structure
in Table 3 below.
Table 3 – Example of a Specific HSC Breakdown Structure
ESWBS
Equipment Functional Description (EFD)
51500
AIR REVITALIZATION SYSTEMS
51510
CO/H2 BURNERS
51511
CO/H2 BURNER - NO. 1
51511SG1
CO/H2, BURNER #1
51511SG1A
CO/H2, BURNER #1, ELECTRIC MOTOR
51511SG1D
CO/H2, BURNER #1, ELECTRICAL ASSY
51511SG1D1
CO/H2, BURNER #1, CONTACTOR
51512
Use Case #4 -
CO/H2 BURNER - NO. 2
Initial Assessment of Change for Configuration
Changes
This assessment reviews a design or logistics proposed change to determine the logistical impact. It
identifies the items which are planned for removal, modification, or addition to the baseline with the
impact to its technical documentation, maintenance, and provisioning.
Use Case #5 - Update Configuration Data & Support Products
Incorporate the updated configuration data and support products resulting from a design or logistics
change. This will update the configuration baseline.
Use Case #6 -
Develop Logistical Technical Data
For each instance of a CWI, develop the appropriate technical data and documentation required to
effectively operate and maintain each class of ship throughout its life cycle. This may be developed at
the system level and/or the equipment level. This documentation will be used to effectively operate and
maintain each class of ship throughout its life cycle.
Damage Control Plates are included as a part of the Logistics Technical Data.
ISE-6-TEAM-0001
Page 20 of 53
Enabling Shipyard Interoperability
Use Case #7 -
ISE-6 Product Life Cycle Support Use Cases
Develop Provisioning Technical Documentation
Packages and Assign Repairable Identification Code
This process, occurring after procurement, involves the decomposition of a Configuration Worthy Item
(CWI) into components which themselves are CWIs. Each CWI is assigned a Repairable Identification
Code (RIC) to the component so that the item will have full logistical support. The RIC provides the
interface key to the supply support of components and to the components technical documentation such
as identifying technical manuals in the Technical Data Management Information System (TDMIS) and
identification in the supply system.
A RIC uniquely identifies a particular commodity. When the code is related to an Allowance Parts List
or an Allowance Equipage List, it is known as an APL or AEL, respectively. Although the Hierarchical
Structure Code (HSC) identifies a function on a ship, the Repairable Identification Code (RIC) identifies
the commodity that is performing that function. The RIC relates to a set of characteristics which identify
a particular system, equipment, or component.
Please note that another term which may be used for a Configuration Worthy Item (CWI) is Functionally
Significant Item (FSI).
Use Case #8 -
Perform Reliability Maintenance Analysis
Ensure that the ship and its systems are designed in a way that the top level Reliability Maintenance
Analysis (RMA) requirements imposed by the customer are met. The requirements ensure that the ship
meets its operational requirements with minimal down time for equipment. There is also an evaluation of
proposed procurement items, which happens before procurement and provisioning.
Use Case #9 -
Perform System Safety Review
Support the timely identification of hazards and the initiation of actions necessary to eliminate hazards or
reduce the associated risks to an acceptable level within the system.
Use Case #10 - Perform Human Factors Review
Perform Human Engineering review of arrangement drawings, digital and physical mockups or
operational consoles designed for areas involving human interface.
Use Case #11 - Perform Maintenance Planning Development
Determine and set up the conditions required to perform specific repairs and preventive maintenance.
This includes developing maintenance plans, maintenance standards, and maintenance requirement cards.
Maintenance plans and maintenance requirement cards are developed for each Major Repairable
Component (MRC).
The Maintenance Planning and Development Phase provides a cost effective life cycle approach which is
consistent with the Class Maintenance Program Procedure.
ISE-6-TEAM-0001
Page 21 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Use Case #12 - Identify Environmental Concerns
This is the process of identifying and documenting the chemical material properties that make up a
component, structure, or piping. This provides documentation (an 'Environmental Map') of where
hazardous compounds are used onboard the ship.
Use Case #13 - Establish Stowage Requirements and Identify
Locations
Identify and track items identified on the Coordinated Shipboard Allowance List (COSAL) for stowage
requirements. The COSAL is made up of equipment/components required for the ship to perform its
operational requirements, and repair parts, special tools and miscellaneous portable equipment required
to repair those items. This provides the basis for development of the stowage requirements. The stowage
items identified in this process produce the stowage requirements for the locations to stow those items.
Use Case #14 - Develop Training Tools and Documentation
Develop training materials and trainers that support personnel procedures for operation, maintenance and
repair of ship systems.
Use Case #15 – Part Usage Requirements
Identify part usage requirements relating to logistics and support, and incorporate them into procurement
specifications.
Use Case #16 – Develop Planned Change
Develop updates for configuration data and support products to address a proposed design or logistics
change.
Use Case #17 – Release Configuration Data and Support Products
Release configuration data and support products to the ship owner.
Use Case #18 – Define Ship Support Policy
This is the process by which the ship owner defines the policies that will be employed to support the
ship. This may include: the contractual arrangements for support (such as organic support, contractor
logistic support, contract for availability); the maintenance philosophy to be applied (such as reliability
centered maintenance or calendar based maintenance); inventory management policy; the stock
management philosophy policy to be applied (such as just in time supply or managed inventory); training
philosophy to be used (such as on-the-job training). These policy choices will be influenced by many
factors including: ship capabilities, intended missions, contractor capabilities, available technology, the
program office, expected budget, DoD and Navy policy, as well as experience from the other ship
programs.
ISE-6-TEAM-0001
Page 22 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Use Case #19 – Define ILS Approach
This is the process of specifying and implementing the processes, procedures, and tools that an ILS
organization will use to develop logistics data and products for a specific ship or ship class. Different
ship contracts have different requirements which may be satisfied by various combinations of processes,
procedures, and tools. This is a collaborative process between the ILS organization and the Navy
customer and will be influenced by the specifics of the ship support approach adopted.
The resulting ILS Support Plan is utilized throughout the ILS organization in all activities relating to this
ship contract. (This is not shown in Figure 1.)
Use Case #20 – Perform Part Supportability and Life Cycle Cost
Analysis
Ensure that the part is designed in a way that the top level supportability and life cycle cost requirements
imposed by the customer are met. Supportability and life cycle cost analysis includes the whole life
cycle of system and support elements. The analysis ensures that the ship will achieve optimum system
performance at minimum life cycle cost.
Use Case #21 - Develop Kitting Plan
Specify and define kits required by the AIT to install the Ship Alteration. Kitted material is supplied to
the AIT by the planning yard.
Use Case #22 - Plan Configuration with ILS Certification
Plan the finalizing of the Ship Alteration, including incorporating all planned configuration changes in
the configuration baseline and approval of the ILS Certification, indicating all required support products
are complete.
Use Case #23 - Update Configuration with Installed Alterations
Update the configuration baseline to incorporate all configuration changes reported from the installation
of the Ship Alteration.
ISE-6-TEAM-0001
Page 23 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
5
RELATIONSHIP OF PLCS USE CASES TO AP239
APPLICATION ACTIVITY MODEL (AAM)
5.1
Comparison of Models
AP239 Application Activity Model (AAM)

General model for logistics support which may include the development of logistics support
systems and procedures

Many activities relate to planning and development of requirements for support
ISE-6 Use Cases

Assume Navy infrastructure will be used for logistics support
o
o
o

Overall support requirements established by Navy
o
5.2
Logistics support systems have been implemented
Most logistics support procedures are defined
CDMD-OA – Navy LSAR
Contractor typically negotiates specific support requirements with Navy for given ship
class contract
Mapping of ISE-6 Use Cases to AP239 AAM Diagrams
Table 4 below relates each ISE-6 PLCS Use Case to the AP239 Application Activity Model (AAM)
Diagram(s) that best correspond to that Use Case.
Only a segment of the AAM Diagrams are used and there is not a perfect correlation in all cases because
the AAM focuses on providing through life support, while the ISE-6 Use Cases focus on managing the
support information during ship acquisition or ship alterations.
ISE-6-TEAM-0001
Page 24 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Table 4 – Comparing ISE-6 PLCS Use Case to AP239 AAM Diagram
ISE-6 Use Case
AP239 AAM
#
AAM
Diagrams
Name
See Figures
Below
1. Identify Hierarchy Classification for Functional and
System Designators
A1211
16
2. Identify Configuration Worthy Items
A1211
16
3. Classify Instances Based on Functionality
A1212, A1213, A1214, A122
4. Initial Assessment of Change for Configuration Changes
15, 16, 17
A111, A112
5. Update Configuration Data & Support Products
10, 11, 12
A134
18, 20
6. Develop Logistical Technical Data
A1215, A133
16, 18
7. Develop Provisioning Technical Documentation Packages
and Assign Repairable Identification Code
A1215, A133
16, 18
8. Perform Reliability Maintenance Analysis
A1215, A133
16, 18
9. Perform System Safety Review
A1215, A133
16, 18
10. Perform Human Factors Review
A1215, A133
16, 18
11. Perform Maintenance Planning Development
A1215, A133
16, 18
12. Identify Environmental Concerns
A1215, A133
16, 18
13. Establish Stowage Requirements and Identify Locations
A1215, A133
16, 18
14. Develop Training Tools and Documentation
A1215, A133
16, 18
15. Part Usage Requirements
A1215, A133
16, 18
16. Develop Planned Change
A1131, A1132, A11331-A11335
17. Release Configuration Data and Support Products
18. Define Ship Support Policy
19. Define ILS Approach
21. Develop Kitting Plan
22. Plan Configuration with ILS Certification
23. Update Configuration with Installed Alterations
ISE-6-TEAM-0001
A134
18, 20
A2431
24
A131, A132, A21
20. Perform Part Supportability and Life Cycle Cost Analysis
13, 14
18, 19, 21, 22
A1215, A133
16, 18
A223, A41121, A41122, A41123
23, 25, 26
A111, A112
10, 11, 12
A134
18, 20
Page 25 of 53
Enabling Shipyard Interoperability
5.3
ISE-6 Product Life Cycle Support Use Cases
AAM Diagrams and Explanations
Figures 9 through 26 show the actual AAM Models that correspond to or include the activities
represented in the ISE-6 PLCS Use Cases. The graphical form of the application activity model is
presented in the IDEF0 activity modeling format. Activities and data flows that are out of scope are
marked with asterisks.
Figure 8 describes the basic notation used in IDEF0 modeling. Each activity may be decomposed to
provide more detail. If an activity has been decomposed, a separate diagram is included. In an IDEF0
diagram:
 Boxes represent activities
 Inputs are represented by arrows entering the Box on the left hand side
 Controls are represented by arrows entering the Box from the top
 Mechanisms are represented by arrows entering the Box from the bottom
 Outputs are represented by arrows leaving the Box on the right hand side
CONTROL
INPUT
OUTPUT
MECHANISM
Figure 8 — IDEF0 Basic Notation
ISE-6-TEAM-0001
Page 26 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 9:

A0 -
Provide Through Life Support for Product

A1 -
Manage Information to Support a Product

A2 -
Generate Support Solutions

A3 -
Commission Support System

A4 -
Provide Support
Figure 9 – AP239 AAM Diagram A0 – Provide Through Life Support for Product
ISE-6-TEAM-0001
Page 27 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 10:

A11 -
Manage Configuration Change

A111 -
Manage Issue

A112 -
Establish Requirement for Change

A113 -
Evaluate & Coordinate Solution or Variance

A114 -
Assess Audit Feedback
Figure 10 – AP239 AAM Diagram A11 – Manage Configuration Change
ISE-6-TEAM-0001
Page 28 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 11:

A111 o
o
Manage Issue
Action to record and assess issues according to type and priority.
NOTE: Issues that require change action are passed to the other configuration change
management activities. A unique identifier is issued as part of activity A1.2 (manage
identification). Issues include any issue, problem or proposal related to configuration
management. Such issues can be variances, documentation error reports from any source
but principally from support engineering, resource management, maintenance and
feedback or configuration discrepancy reports, perhaps arising from change monitoring
or audit activity.

A1111 -
Register Issue

A1112 -
Assess Issue
Figure 11 – AP239 AAM Diagram A111 – Manage Issue
ISE-6-TEAM-0001
Page 29 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 12:

A112 o
o
Establish Requirement for Change
Action to document and assess the problem or change opportunity.
NOTE: This activity covers documentation of the change opportunity or problem and the
creation of a suitable description, analysis of the opportunity or problem, and the reason
for a possible change along with a statement of expected impact sufficient for evaluation,
determination of the appropriate level of priority, and the raising and the approval of a
valid need for change as an input to evaluating and coordinating a solution or variance.

A1121 -
Identify & Prioritize Change

A1122 -
Document Change Opportunity or Problem

A1123 -
Analyze Change Problem or Opportunity
Figure 12 – AP239 AAM Diagram A112 – Establish Requirement for Change
ISE-6-TEAM-0001
Page 30 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 13:

A113 -
Evaluate & Coordinate Solution or Variance

A1131 -
Develop Change
o
o

A1132 o
o

Action to refine the preliminary assessment to determine all potential consequences of a
possible change including necessary coordination between the impacted items to enable
effectivity to be determined.
NOTE: The preliminary assessment occurs in activity A1.1.2. The level of analysis
required will depend on the nature of the change taking into account effects on support
engineering and resource management and impacts on other approved changes.
Plan Change
Action to establish which members of the PIF are to be changed, including new
production and existing products.
NOTE: There are many influencing factors on this activity including an assessment of
the urgency and priority of the change and the availability of parts and materials,
software and replacement parts. Determining an effectivity requires knowledge not only
of the lead times associated with changing the product (whether in production or by
retrofit, recall or other means) but of the actions and lead times necessary to effect the
associated change in all impacted support areas (such as the update of support software,
availability of spare and repair parts, or revision to operating and maintenance
instructions). Once the change is approved detailed implementation planning, which
expands but remains consistent with the basic planning is normally required.
Implementation of a change involves the release of new or revised configuration
documentation including requirements and design information. This implementation may
involve changes to information on operation and maintenance, build and test, and
commercial documentation. The new or revised information is identified and released
within activity A1.3 (manage information). The release process ties the document
revisions to a change. It is not always necessary to have a plan before a change task can
be authorized. However, a change implementation plan is usually needed.
A1133 -
ISE-6-TEAM-0001
Establish Business Solution & Authorize Change
Page 31 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 13 – AP239 AAM Diagram A113 – Evaluate & Coordinate Solution or Variance
ISE-6-TEAM-0001
Page 32 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 14:

A1133 -
Establish Business Solution & Authorize Change

A11331 -
Assess Solution Risk
o

A11332 o



o
Compare Solution Options
Action to select the solution that best meets the valid need for change.
A11336 o
Compile Justification for Solution
Action to review the total change package and complete a justification for the
implementation requirements with a recommended classification and priority.
A11335 o
Classify Solution
Action to classify the chosen solution with respect to appropriate parameters.
NOTE: Change solutions can be classified in many ways, including:
 Nature of change, such as safety critical
 Scale of change, such as major or minor
 Implementation impact, such as an in-service change
 Regulatory interest, such as FAA approval required.
A11334 o
Establish Cost of Solution
Action to evaluate the cost of a change by subjecting the most beneficial solution to a
commercial pricing exercise, creating a price that meets the implementation and
effectivity requirements.
A11333 o
o

Action to assess the risks associated with a quantified solution to a valid need for
change.
Authorize Change
Authorization, rejection or deferment of a recommended change based on the associated
justification.
NOTE: If the change is authorized a change order will be issued for implementation. If
the change is rejected a further review can be initiated.
ISE-6-TEAM-0001
Page 33 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 14 – AP239 AAM Diagram A1133 – Establish Business Solution & Authorize Change
ISE-6-TEAM-0001
Page 34 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 15:

A12 -
Manage Identification

A121 -
Identify Product and Support System Elements

A122 -
Define Product Structure
Figure 15 – AP239 AAM Diagram A12 – Manage Identification
ISE-6-TEAM-0001
Page 35 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 16:

A121 -
Identify Product and Support System Elements

A1211 -
Define PIF Boundary
o
o

A1212 o
o

o
Define Interface between Elements
Action to identify any interfaces between elements that will be subject to configuration
management.
The nature of interfaces depends on the nature of the elements themselves. The interface
description may include the physical and functional attributes of the connection, spatial
relationships, parent-child relationships and other forms of reference, such as the links to
product, support and configuration data. This activity provides the foundation on which
to generate the checklist that is used when changes to elements are proposed and ensures
all consequences of a proposed change are considered. The descriptions of interface
elements also provide a starting point for the development of product structures.
A1214 o
o
Identify Element
Action to provide unambiguous names and identifiers for all elements of the Product in
Focus and the support system.
NOTE: An element may have many identifiers, each assigned by a different organization.
This model assumes that the pair of values for "identifier" and "assigning organization"
are unique across the PIF scope. This should be reflected in the Information Management
Rules.
A1213 o

Action to provide a boundary definition of the set of products for which support is
required, including an indication of the level product decomposition at which support is
expected.
NOTE: The PIF is the set of operational products, usually sharing a common product
design, for which support is required. This set of products may be further subdivided
across several deployment environments, each requiring a tailored support solution based
on a common set of task specifications.
Classify Element or Interface
Action to classify elements to provide a convenient reference in the business context.
NOTE: The classification method will also assist in defining information needs.
Classification of elements can include:
 The selection of configuration items and configuration item interfaces
 Differentiation by size or complexity, using distinctions such as, major unit,
minor unit, assembly, and raw material
 Differentiation in respect of types of information to be held, including those
items that require load testing.
ISE-6-TEAM-0001
Page 36 of 53
Enabling Shipyard Interoperability

A1215 o
o
ISE-6 Product Life Cycle Support Use Cases
Define Information Required for Element or Interface
Action to define what APSI shall be developed and maintained for each item in question,
to enable the support solution definition to be implemented and maintained throughout
the life of the PIF
NOTE A configuration item can have a large quantity of associated information. Such
information can include:
 design data
 configuration item interfaces
 specifications
 interface control documentation
 records of support analyses such as reliability centred maintenance analysis, or
level of repair analysis
 the support solution definition
 technical publications
 test results and certification
 quality assurance documentation
Figure 16 – AP239 AAM Diagram A121 – Identify Product and Support System Elements
ISE-6-TEAM-0001
Page 37 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 17:

A122 o
o
Define Product Structure
Action to develop the required views of each relevant product, in the form of assembly
structures or breakdowns built from classified elements and to establish necessary
relationships between the different views to provide navigation between views.
NOTE: The managed set of product views (the PIF structure) provides unambiguous
identification of the PIF for support management purposes and a key mechanism for
navigating and managing the effectivity of all related information, including that
specified by the information need providing the product definition and support solution.

A1221 -
Develop Structure Views

A1222 -
Define Link between Product Structures
Figure 17 – AP239 AAM Diagram A122 – Define Product Structure
ISE-6-TEAM-0001
Page 38 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 18:

A13 -
Manage Information

A131 -
Develop Information Management Plan
o
o
Action to generate a plan for the information management activities required to achieve
and sustain a coherent information environment, reflecting the information management
strategy and requirements.
NOTE: Activities within the plan include specification of required information
deliverables, development of the information management rules, development of
information exchange agreements between participating organizations, development and
testing of information exchange capability, tasks to reformat information to comply with
the rules. The information strategy requirements usually originate in customer or
contractor policies and standards (covering information technology, business-to-business
trading, configuration management, quality assurance). The contractual requirements
usually originate in the change management plan or a change order.

A132 -
Define Information Architecture or Rule

A133 -
Populate Information Structure
o
o

Action to populate the PIF structure with the information specified by information needs.
NOTE: This activity captures all necessary information on product and support elements,
including relevant interfaces and inter-changeability information, and establishes
appropriate relationships with the PIF structure to establish a sufficient set of product
and support information for the PIF to meet life cycle support needs.
A134 -
ISE-6-TEAM-0001
Release Assured Product and Support Information
Page 39 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 18 – AP239 AAM Diagram A13 – Manage Information
ISE-6-TEAM-0001
Page 40 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 19:

A132 o
o

Define Information Architecture or Rule
Action to establish necessary information management rules to achieve unambiguous
information sharing and exchange capability in a digital environment including
definition of the meaning, structure and organization of data required by the extended
enterprise engaged in product support.
NOTE: This activity covers the production of an information model that defines how the
product data will be held. The architecture may prescribe a set of tools or specify an
open data architecture. The activity generates the associations and relationships between
data and documents and a definition of how that information is represented in different
views. This may involve the specification of relevant parts of ISO 10303 or other
standards, such as EIA-836 or EIA-649-A.
A1321 o
o
Develop Information Model
Action to produce or select a conceptual information model to define the entities,
attributes and relationships of interest to product life cycle support, and define the format
in which required information shall be captured so that relevant information can
managed over time.
NOTE: This part of ISO 10303 can be used for this purpose.

A1322 -
Identify Product Structure View

A1323 -
Define Information Management Procedure
ISE-6-TEAM-0001
Page 41 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 19 – AP239 AAM Diagram A132 – Define Information Architecture or Rule
ISE-6-TEAM-0001
Page 42 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 20:

A134 o
o
Release Assured Product and Support Information
Action to authorize and release the assured information needed to achieve product life
cycle support.
NOTE: This action involves checking the APSI for:
 Completeness against the information need
 Compliance with the change order and the information management rules
 Timely release as required by the change implementation plan.

A1341 -
Create Information Release plan

A1342 -
Verify Suitability for Release

A1343 -
Implement Information Release Plan
Figure 20 – AP239 AAM Diagram A134 – Release Assured Product and Support Information
ISE-6-TEAM-0001
Page 43 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 21:

A2 o
o
Generate Support Solutions
Identify, develop, validate, and enhance an optimized support solution definition for the
product in focus, exercising appropriate influence on the product design.
NOTE: This activity is assumed to be performed in an environment of concurrent
engineering and integrated teams as defined by the life cycle owner. It may applied when
designing the product and its support concurrently, when developing a support solution
for a pre-existing product that is not yet in use or when updating an existing support
system. The PIF maybe supported by several support solution definitions, each tailored
to a specific group of products, users, roles and support capabilities, collectively known
as a deployment environment. The activity includes:
 Identification and analysis of support requirements
 Definition of the support activities
 Definition of the resources required for support, including skilled personnel
 Specification of design requirements for support elements and for embedded
support features
 The identification, definition, generation and management of support
engineering analysis data
 The identification, definition and analysis of support cost and readiness drivers
 Identification and analysis of product availability and support system
performance metrics during life cycle of the product. This activity can be
necessary more than once for any given product in focus in order to meet
changing and evolving requirements.

A21 -
Manage Support Engineering Program

A22 -
Define Support Context

A23 -
Establish Requirements for Support Solution

A24 -
Design Support Solution

A25 -
Assess Support Performance
ISE-6-TEAM-0001
Page 44 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 21 – AP239 AAM Diagram A2 – Generate Support Solutions
ISE-6-TEAM-0001
Page 45 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 22:

A21 o
Manage Support Engineering Program
Action to manage the development of a support solution definition for each deployment
environment, over the life cycle of the PIF, by defining objectives and acceptance
criteria, establishing a support strategy, developing a support engineering plan and
monitoring resultant activities

A211 -
Define Objectives of Support Engineering Program

A212 -
Identify Support Risks and Improvement Opportunities

A213 -
Plan Support Engineering Activity

A214 -
Review Support Engineering Program
Figure 22 – AP239 AAM Diagram A21 – Manage Support Engineering Program
ISE-6-TEAM-0001
Page 46 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 23:

A223 o
Define Available Support Resources
Action to define the support resources required at each location including environment,
capabilities, and stowage locations

A2231 -
Identify Support Locations

A2232 -
Define Environment at Each Location

A2233 -
Define Support Capability at Each Location
Figure 23 – AP239 AAM Diagram A223 – Define Available Support Resources
ISE-6-TEAM-0001
Page 47 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 24:

A243 -
Define Support Solution

A2431 -
Define Support Policy
o
o
Action to define the approach to be taken when designing the support solution for a set
of products within a support context, including any requirement to develop and compare
alternative support solution options
NOTE: The support policy includes:
 contractual arrangements for support such as organic support, contractor logistic
support, contract for availability
 the maintenance philosophy to be applied such as reliability centred maintenance
or calendar based maintenance
 the stock holding policy to be applied such as just in time supply or managed
inventory
 training philosophy to be used such as on-the-job training

A2432 -
Develop Support Plan

A2433 -
Complete Task Procedures

A2434 -
Assemble Support Solution

A2435 -
Predict Support Performance & Resource Use
ISE-6-TEAM-0001
Page 48 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 24 – AP239 AAM Diagram A243 – Define Support Solution
ISE-6-TEAM-0001
Page 49 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Activities in Figure 25:

A4112 -
Develop Support Schedule

A41121 -
Identify Intended Tasks

A41122 -
Establish Task Logic


o
Action to establish logic and plan for tasks
o
NOTE: This includes logic and plans for Kitting
A41123 -
Identify Required Resources
o
Action to identify required resources
o
NOTE: These resources include Kitting material
A41124 -
ISE-6-TEAM-0001
Schedule Activities
Page 50 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 25 – AP239 AAM Diagram A4112 – Develop Support Schedule
Activities in Figure 26:

A41121 -
Identify Intended Tasks
o
Action to identify intended tasks
o
NOTE: These tasks include those required for Kitting

A411211 -
Establish State of Products Needing Support

A411212 -
Identify Triggered Tasks

A411213 -
Select Commissioning Tasks

A411214 -
Identify other Required Tasks

A441215 -
Identify Consequential Tasks
ISE-6-TEAM-0001
Page 51 of 53
Enabling Shipyard Interoperability
ISE-6 Product Life Cycle Support Use Cases
Figure 26 – AP239 AAM Diagram A41121 – Identify Intended Tasks
ISE-6-TEAM-0001
Page 52 of 53
Enabling Shipyard Interoperability
6
ISE-6 Product Life Cycle Support Use Cases
SUMMARY
The majority of the Total Ownership Cost (TOC) of a Navy ship accrues after the ship has been delivered
by the shipbuilder to the Navy. The processes of life cycle support; repair, maintenance and overhaul,
ships’ operations, testing, and training are all information intensive processes. The Navy has steadily
moved toward more modern systems and technologies to cope with the burgeoning information needs,
but technology has evolved faster than the deployed solutions. As a result there are a number of
incompatibilities or opportunities for significant process improvement as a result of systems technologies
advances.
The configuration of a ship changes during it's lifecycle as a result of maintenance, repair, and
modernization activities. The SHIPMAIN process defines this overall process. Modernization activities
are planned and scheduled as ship Alterations. This is defined by the Fleet Modernization Process
(FMP). The SHIPMAIN and FMP processes are available at: www.fmp.navy.mil.
At the same time the business environment for post-delivery support is changing. Shipyards have become
responsible for the life cycle support of ships, including managing maintenance and logistics data over
the life of the ship. This is the so-called full service contract. The shipyards have, in the meantime,
deployed sophisticated digital Integrated Product Data Environments (IPDEs). This presents a new
opportunity for a shipyard to efficiently integrate its acquisition product model data with life cycle
support product model data. This information is also required to develop the logistics data for the ship.
After ship delivery, the acquisition data is required to initialize life cycle support systems for the ship.
Technical publications, required to operate and maintain the ship, also require similar ship product model
information. All of the systems and processes are highly inter-related through the information that they
share. Today, system, technological, and process boundaries inhibit information interoperability. The
shipyard’s cost and performance on these new Navy contracts can be improved significantly through the
efficient transfer and incorporation of ship product model data.
The ISE-6 Team is developing a system architecture to enable the information required for Product Life
Cycle Support (PLCS) to be captured in a manner that is interoperable and portable across the various
ship platforms. The Use Cases described in this document capture the functional requirements of the
system and will be mapped to various DEX’s (Data Exchange Sets) in AP239. This will enable the
derivation of a consistent and extensible information model to capture a set of information requirements
that span application domains.
REVISION HISTORY
Rev
1.0
2.0
Rev
Date
06/22/07
08/13/07
Revised By
ISE-6-TEAM-0001
BFG
BFG
Description
Reason
Initial Release
Use Cases to Support Ship Alterations Enhance Report to Support Use Cases for
both Design New Construction and Ship
Alterations and to incorporate comments
from review by ISE-6 Team members
Page 53 of 53