Configuration_and_logistics Business Information Requirements

Business Information Model Requirements

The business information requirements are provided within the context of the Navy Product Data Initiative (NPDI) and the Ship Common Information Model (SCIM). The previous figure (Figure 3) provided a UML diagram for the scope of this DEX and the associated information requirements. This section provides more details on each of the information objects.

Ship

The Ship (Figure 4) entity represents a ship that operates under the command of the US Navy. It is the primary end product of the design and build activities supported by the IPDE. A ship is uniquely identified by UIC or by Ship Type and Hull Number.

The Ship may have the following types of associations;

• an associated (set of 0 or more) HSC_breakdown;
• an associated (set of 0 or more) Logistics_configuration_item.

Figure 4 —  UML model representing Ship

The entity npd:Ship represents one particular built hull, which is the primary end product of the design and build activities supported by the NPDI specification. The ship is the primary physical end product of the design and build activities. There is a need for an identifiable entity to represent this end product. The npd:Ship entity is used for each of the many stages of the life cycle of a ship, including new project, concept and detailed design, production engineering, manufacturing, operations, and support. Although the npd:Ship represents a single physical hull, it is typically associated with a class, or range of hulls, that share a substantial proportion of design characteristics. The configuration of all product data defining individual hulls of the class is managed using the npd:Hull_applicability entity in the SCIM. The property Hull_number of the npd:Ship entity corresponds to a single hull in the range of hulls identified in the npd:Hull_applicability properties Start_hull and End_hull. The Ship entity is represented in the Navy Ship Configuration and Logistics Support Information System (SCLSIS) Record Type 1 information. Refer to the SCIM Product Life Cycle Support (PLCS) chapter for further details.

A Ship has the following properties defined;

Table 1 — Ship information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Logistics_occurrence

A Logistics occurrence (Figure 5) is an occurrence of a logistics-worthy item (functionally significant item) for which logistics products and data are developed. Logistics occurrences are often identified by a unique Hierarchical Structure Code (HSC) and related to other logistics occurrences via a logistics occurrence assembly. Logistics occurrence items are the central point for which all logistics support information is developed and maintained. Logistics support information includes equipment configuration, maintenance products, reliability/maintainability/availability data, technical publications, training materials, provisioning and supply support information. Logistics occurrence items are related to the design from which they are based and physical occurrence items representing an installed item on specific ship. The entity npd:Logistics_occurrence is also known as "Hierarchical Structure Code (HSC) item" or "Logistics Configuration Baseline (LCB) item".

The Logistics_occurrence may include the following types of associations;

• an associated (0 or 1) Design_occurrence;
• an associated (set of 0 or more) Physical_occurrence (not in scope);
• an associated ( 0 or 1) Logistics_occurrence_assembly (as parent);
• an associated ( 0 or 1) Logistics_occurrence_assembly (as child);
• an associated (set of 0 or more) Configuration_item (not in scope);
• an associated (set of 1 or more) Hull_applicability;
• an associated (set of 0 or more) Document_metada (not in scope);

Figure 5 —  UML model representing Logistics occurrence

Table 1 — Logistics occurrence information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Logistics_configuration_item

A Logistics configuration item (Figure 6) is a type of Logistics_occurrence that maybe an Installed_item or a Rotatable_pool_item. It represents the occurrence of a physical part on the Ship (or other type of Naval_activity). An occurrence of a physical part at a Naval_activity which is managed and tracked for logistics support and maintenance. A Physical_occurrence item installed on a ship is an Installed_item. A training facility is a Naval_activity with selected systems used for training, including Installed_items at the site. A refit facility has alteration items for refit, referred to as Rotatable_pool_items (RPI), which are pulled from specific ships.

The Logistics_configuration_item may include the following types of associations;

• an associated (0 or 1) HSC_breakdown;
• an associated (0 or 1) Repairable_part;
• an associated (set of 0 or more) Lsd_metadata (not in scope);
• an associated Ship;

Figure 6 —  UML model representing Logistics configuration item

Table 1 — Logistics configuration item information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Installed_item

Installed_item (Figure 7) is a type of Logistics configuration item that identifies a Physical_occurrence item installed on a Ship. A Ship configuration baseline in CDMD-OA consists of all Installed_items for a given ship.

The Installed_item may include the following types of associations;

• an associated (set of 0 or more) Rotatable_pool_item (not in scope);

Figure 7 —  UML model representing Installed_item

The entity npd:Installed_item provides a means to collect information on a physical item installed on the ship.

For each physical occurrence of a logistics worthy item (see PLCS_Logistics_occurrence), it is necessary to distinguish between items that are physically located on the ship and items that may be located in some other location such as a depot or maintenance facility (see Rotatable_pool_item).

Table 1 — Installed item information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Repairable_part

Repairable part (Figure 8) is a type of part managed by the US Navy supply system where the part number is specified as a Repairable Identification Code (RIC). A Repairable Part is characterized by a set of physical and logistics properties that may be satisfied by one or more OEM Parts. In addition, if the Repairable Part is an APL or AEL, then it is characterized by a breakdown by quantity of the OEM Parts required for maintenance.

The Repairable_part may include the following types of associations;

• an associated (set of 0 or more) Logistics_configuration_item;
• an associated (set of 0 or more) Repairable_part (as has_alt_ric_of);

Figure 8 —  UML model representing Repairable_part

Entity npd:Repairable_part provides a means to collect information on entities managed by the US Navy supply system.

The Navy manages maintenance and supply activities through the use of identifiers known as Repairable Item Codes (RICs). A RIC is a code assigned to uniquely identify a particular commodity. A Repairable_part is identified by a Repairable Item Code (RIC) and is related to the Logistics_occurrence for a piece of equipment.

Table 1 — Repairable_part information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Logistics_occurrence_assembly

Logistics_occurrence_assembly (Figure 9) is a type of record that captures the relationship of an assembly to one of its children. The child may be a part logistics occurrence or a sub-assembly logistics occurrence.

The Logistics_occurrence_assembly may include the following types of associations;

• an associated Logistics_occurrence (as parent);
• an associated Logistics_occurrence (as child);

Figure 9 —  UML model representing Logistics_occurrence_assembly

The entity npd:Logistics_occurrence_assembly provides the means to create hierarchical product structures of logistics occurrences within the ship product model.

There are a number of scenarios in the ship support and maintenance life cycle which call for explicit hierarchical assembly structures (product structure views) representing assemblies and the constituents of those assemblies.

A constituent of an assembly may itself also be an assembly (i.e., a subassembly), which in turn is made up of constituents. Logistics occurrences make up the leaves of these hierarchal structures.

An additional requirement is that the product structuring mechanism be loosely coupled to the definition of logistics occurrences so that multiple or various product structures can be assembled over the same set of logistics occurrences.

The entity npd:Logistics_occurrence_assembly is also known as "product structure", "next assembly usage occurrence" or "HSC breakdown".

Table 1 — Logistics occurrence assembly information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

HSC_breakdown (Hierarchical_structure_code_breakdown)

HSC_breakdown (Hierarchical structure code breakdown) (Figure 10) is a type of Logistics_occurrence_assembly that identifies a breakdown of the ship based on the structural systems that make up the ship (e.g., hull, decks, and bulkheads), and the engineering systems that support the ship's operation and mission (e.g., piping systems, HVAC systems, command and control systems). Each system in the breakdown is identified through the Ship Work Breakdown Structure (SWBS) code, which is defined by NAVSEA Instruction 4790.1B. Systems can be composed of sub-systems. Parts, and connections between the parts, can be classified according to the system that they belong to. Documents, such as System Diagrams, can be related to the System that they represent.

The HSC_breakdown may include the following types of associations;

• an associated (set of 0 or more) Logistics_configuration_item;
• an associated (set of 0 or 1) System_breakdown;
• an associated Ship;

Figure 10 —  UML model representing HSC_Breakdown

Table 1 — HSC_breakdown information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Design_occurrence

A Design_occurrence (Figure 5) represents the instantiation of a single, location-specific item in the ship design. The Design_occurrence not only represents the design item instance but also provides the means for collecting the properties associated with each design item instance. The properties that apply to a Design_occurrence may vary with respect to the particular type of Design_occurrence (a piping Design_occurrence has different properties from a structural Design_occurrence) or to context (the PDM properties of a Design_occurrence pertain to its configuration management aspect irrespective of design). Its hull applicability characteristics distinguishes a Design_occurrence from a Design_part (which is a design item not associated with any particular hull) as well as from a Physical_occurrence (which denotes one particular item at one particular location on one particular hull).

The A Design_occurrence may include the following types of associations;

• an associated (set of 0 or more) Applied_approval_assignment (not in scope);
• an associated (set of 0 or more) Configuration_item (not in scope);
• an associated ( 0 or 1) Design_part;
• an associated (set of 0 or more) Document_metada (not in scope);
• an associated ( 0 or 1) Logistics_occurrence_assembly (as parent);
• an associated ( 0 or 1) Logistics_occurrence_assembly (as child);
• an associated (set of 1 or more) Hull_applicability;
• an associated (set of 0 or more) Logistics_occurrence;
• an associated (1) Design_occurrence_definition;
• an associated (set of 0 or more) Physical_occurrence (not in scope);
• an associated (set of 0 or more) Analysis_occurrence (not in scope);

Figure 11 —  UML model representing Design occurrence

The entity npd:Design_occurrence denotes a significant item in the design product model that may apply to more than one hull.

The design product model for a ship consists of the definition of a number of design significant items. Some of the parts that make up the model are repeated at different locations. However, the ship design must capture and manage information that is unique to the part's location and context in the ship. Thus a Design_occurrence may be an instance of a Design_part that is also used in other locations within the design, or a Design_occurrence may have no such relationship to a Design_part.

While a Design_occurrence may be an instance of a Design_part that is also used in other locations within the design, the use of the same identifier for each instance, with an associated quantity greater than one, is disallowed. While there are aspects of these common parts that are in fact the same for each instance, the nature of a Design_occurrence is that it can be used to collect information specific to its particular location and context. The Design_occurrence is uniquely identified by its Id property.

Another characteristic of US Navy ship design is that the design may apply to a class of hulls. That is, each design will be employed on a number of hulls. Inevitably, there are variations from hull to hull. An item in the ship design needs to be reuseable across more than one hull and assignable to a set of applicable hulls.

Since a ship design is typically built several times and since portions of the design may be changed for some subset of hulls, each Design_occurrence is qualified by its hull applicability, the sequence of hulls to which the Design_occurrence applies. (Note that hull applicability may be associated with a Design_occurrence directly or indirectly through a Configuration_item. In either case, for each Design_occurrence it is possible to determine to which hulls it actually applies.)

Table 1 — Design occurrence information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

NOTE    This object is currently out of scope, but provided here for completeness.

Design_occurrence_definition

A Design_occurrence_definition (Figure 9) captures the configuration management metadata that pertains to a design occurrence.

The Design_occurrence_definition may include the following types of associations;

• an associated (1) Design_occurrence;
• an associated (set of 0 or more) Change_request (not in scope);
• an associated ( 0 or 1) Material_quality_requirements (not in scope);
• an associated ( 0 or 1) Safety_requirements;
• an associated ( 0 or 1) Weight (not in scope);
• an associated (set of 0 or more) Shape_representation (not in scope);
• an associated (set of 1 or more) External_geometric_model (not in scope);
• an associated (1) Contract (not in scope);
• an associated (1) Certification (not in scope);
• an associated (1) Security_classification (not in scope);

Figure 12 —  UML model representing Design_occurrence_definition

The entity, npd:Design_occurrence_definition provides a means to manage the configuration management metadata for a design occurrence.

In Naval shipbuilding the configuration management of the pertinent design occurrences is a key challenge. Because ships are designed by class and hulls within a class may vary by differing degrees, the configuration management properties of each design occurrence need to be tracked. This includes such matters as creation dates, design authors as well as security, contract, and certification information.

The certification, contract, and security classification data for this design occurrence is provided by means of associations to npd:Certification, npd: Contract, and npd:Security_classification.

Table 1 — Design_occurrence_definition information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

NOTE    This object is currently out of scope, but provided here for completeness.

Design_occurrence_assembly

A Design_occurrence_assembly (Figure 5) captures the relationship of a Design_occurrence_assembly to one of its children. The child may be a part design occurrence or a sub-assembly design occurrence.

The Logistics_occurrence may include the following types of associations;

• an associated (1) Design_occurrence (Parent);
• an associated (1) Design_occurrence (Child);

Figure 13 —  UML model representing Design occurrence assembly

Table 1 — Design_occurrence_assembly information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

NOTE    This object is currently out of scope, but provided here for completeness.

System_breakdown

System Breakdown (Figure 14) is a type of Design_occurence_assembly that identifies a breakdown of the ship based on the structural systems that make up the ship (e.g., hull, decks, and bulkheads), and the engineering systems that support the ship's operation and mission (e.g., piping systems, HVAC systems, command and control systems). Each system in the breakdown is identified through the Ship Work Breakdown Structure (SWBS) code, which is defined by NAVSEA Instruction 4790.1B. Systems can be composed of sub-systems. Parts, and connections between the parts, can be classified according to the system that they belong to. Documents, such as System Diagrams, can be related to the System that they represent.

The System_breakdown may include the following types of associations;

• an associated (set of 0 or more) HSC_breakdown;

Figure 14 —  UML model representing System Breakdown

Entity npd:System_breakdown provides a means to collect information on the engineering system breakdown structure.

The system breakdown structure is developed by the engineering group and used during the design the ship.

There is a need to link the Logistics_occurrence items to the applicable design structure in order access design material from which the logistics products are derived and provides a mechanism to identify changes in logistics products based on changes in the design.

Entity npd:System_breakdown is also know as "Expanded Ship Work Breakdown Structure (ESWBS)".

Table 1 — System_breakdown information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

NOTE    This object is currently out of scope, but provided here for completeness.

Configuration_item

The configuration_item (Figure 15) is a key concept to support explicit configuration management. It represents the identification of a particular configuration, i.e. variation of ship design. A configuration_item is defined with respect to the hulls to which it is applicable.

The configuration_item may include the following types of associations;

• an associated (1) Configuration_item_definition (not is scope);
• an associated (set of 1 or more) HSC_applicability;
• an associated (set of 1 or more) Design_occurrence;
• an associated (set of 1 or more) Logistics_occurrence;
• an associated (set of 1 or more) Applied_approval_assignment (not in scope);
• an associated (set of 1 or more) Document_metadata;

Figure 15 —  UML model representing Configuration_item

The entity npd:Configuration_item provides a means to collect design occurrences so that they can be configuration controlled as a single group.

The ship product model is a large collection of constantly changing items. Configuration management needs to be applied at a number of different levels.

There is a need for an entity which can collect an arbitrary set of design occurrences and assign hull applicability to that collection as a whole.

Note that any design occurrence in the collection which does not have its own hull applicability inherits the hull applicability of the configuration item.

Table 1 — Configuration_item information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Configuration_item_definition

A Configuration_item_definition (Figure 16) captures the configuration management metadata that pertains to a particular Configuration_item occurrence.

The Configuration_item_definition may include the following types of associations;

• an associated (1) Configuration_item;

Figure 16 —  UML model representing Configuration_item_definition

The entity npd:Configuration_item_definition provides configuration management metadata for a Configuration_item.

Configuration management information such as the identification of the product data creator, date of creation, and engineering discipline responsible for the product data are needed, separate from the later management approval of that product data.

Table 1 — Configuration_item_definition information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Hull_applicability

Hull_applicability (Figure 17) is the identification of a ship hull, or a range of hulls within a class of ships, for which particular product data are applicable.

The Hull_applicability may include the following types of associations;

• an associated (set of 0 or more) Configuration_item (not is scope);
• an associated (set of 0 or more) Design_occurrence;
• an associated (set of 0 or more) Document_metadata (not is scope);
• an associated (set of 0 or more) Logistics_occurrence;
• an associated (1) Global_axis_placement (not is scope);

Figure 17 —  UML model representing Hull_applicability

The entity npd:Hull_applicability designates the range of hulls to which a Design_occurrence or other configured item applies.

In the marine industry the concept of hull applicability is extremely important to configuration management.

The hull represents a single ship. Hull_applicability defines the relationship between a Design_occurrence or Configuration_item and one or more hulls.

Using hull applicability, the product model unambiguously designates on which hull or hulls a particular Design_occurrence or Configuration_item is to be used, and which version of that Design_occurrence or Configuration_item is to be used.

For example, hull numbers 701, 702, 703 would be represented with a Start_hull property value of 701 and an End_hull property value of 703.

Table 1 — Hull_applicability information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

Hull_configuration

A Hull_configuration (Figure 18) versions a collection of logistic_configuration and or design_configuration relationships that are valid for a particular Hull_applicability.

A Hull_configuration may include the following types of associations;

• an associated (set of 0 or more) Logistic_occurrence_assembly;
• an associated (set of 0 or more) Design_occurrence_assembly;
• an associated (1) Hull_applicability;

Figure 18 —  UML model representing Hull_configuration

Entity npd:Hull_configuration expanded description to go here.

Table 1 — Hull_configuration information requirements

NOTE    The Simple-Types are generally enumeration lists as documented within the NPDI/SCIM model. As such they form part of the reference data associated with this DEX and are documented within the appropriate section. Other types are dates (mapped to calendar date or date-time plcs representations) or strings (normal/URI).

© US DoD 2010 — All rights reserved