ISO 10303 Ship Product Model Data Schema Suite - Description

XML schemas are being developed by the Navy and the shipbuilding industry for the following ISO 10303 parts:
       ISO 10303-212:2005, Application Protocol: Electrotechnical Design and Installation
       ISO 10303-215:2004, Application Protocol: Ship Arrangement
       ISO 10303-216:2003, Application Protocol: Ship Moulded Forms
       ISO 10303-218:2004, Application Protocol: Ship Structures
       ISO 10303-227:2005, Application Protocol: Plant Spatial Configuration
       and for a US ship industry Common Parts Catalog.


Non-Manifold Surface Representations (edo216)

This ship moulded forms information use case describes the information needed to define the product model for ship's moulded form definitions and related hydrostatic properties. This use case also includes one geometric representation: the non-manifold surface representation. (A companion use case, edo216w, should be used for systems and processes that rely on a wireframe representation).

For a more detailed description of the information requirements of this use case, see ISO10303-216: Ship moulded forms. Note that this standard, also known as Application Protocol (AP) 216 is a superset of the current use case and includes a number of information elements not used in this use case: such as wireframe geometric representations, changes and version history, approvals.

This information is developed during the following process stage:

  • Create preliminary hull form design
  • Create preliminary general arrangements
  • Estimate hydrostatics and powering
  • Create preliminary structural design

This information supports the following activities:

  • Preliminary structural design, including hull form design
    • Design of control surfaces, including propellers
    • Design of decks
    • Geometric design of ship compartment boundaries and other structural elements
    • Definition of hydrostatic properties of the ship moulded form

This information is used in the following interchanges:

  • Preliminary design engineer and detailed design engineer
  • Naval architect and design engineer
  • Integration of designs from different design engineers
  • Shipyard and customer (design deliverable)

This information contains the following kind of entities and associations:

  • Characterization and definition of moulded forms, including ship moulded forms
  • Hydrostatic properties
  • Ship's general characteristics
  • Ship moulded form design parameters

This information contains the following geometric representation:

  • The geometric shapes of moulded forms are represented using non-manifold surface representations.

Wireframe Representations (edo216-w)

This ship moulded forms information use case describes the information needed to define the product model for ship's moulded form definitions and related hydrostatic properties. This use case also includes one geometric representation: the non-manifold surface representation. (A companion use case, edo216, should be used for systems and processes that rely on a non-manifold surface representation).

For a more detailed description of the information requirements of this use case, see ISO10303-216: Ship moulded forms. Note that this standard, also known as Application Protocol (AP) 216 is a superset of the current use case and includes a number of information elements not used in this use case: such as non-manifold surface representations, changes and version history, approvals.

This information is developed during the following process stage:

  • Create preliminary hull form design
  • Create preliminary general arrangements
  • Estimate hydrostatics and powering
  • Create preliminary structural design

This information supports the following activities:

  • Preliminary structural design, including hull form design
  • Design of control surfaces, including propellers
  • Design of decks
  • Geometric design of ship compartment boundaries and other structural elements
  • Definition of hydrostatic properties of the ship moulded form

This information is used in the following interchanges:

  • Preliminary design engineer and detailed design engineer
  • Naval architect and design engineer
  • Integration of designs from different design engineers
  • Shipyard and customer (design deliverable)

This information contains the following kind of entities and associations:

  • Characterization and definition of moulded forms, including ship moulded forms
  • Hydrostatic properties
  • Ship's general characteristics
  • Ship moulded form design parameters

This information contains the following geometric representation:

  • The geometric shapes of moulded forms are represented using wireframe representations.

Computer Aided Design (CAD) (edo218-cad)

This ship structures (3D geometric design) information use case describes the information needed to define the explicit 3D geometric product model for the detailed design of ship structures - including hull, bulkheads, decks and foundations. This use case consists of the items that comprised the structures detailed design product model and the associated 3D solid (Brep) geometric representation. Beyond the items and their geometric representations, this use case entails very little additional design information. See the other edo218 use cases for those design definitions.

This use case is based upon entities and associations defined in ISO10303-218, Ship structures. Note that this standard, also known as Application Protocol (AP) 218 is a superset of the current use case and includes a number of information elements not used in this use case: such as various geometric representations, changes and version history, approvals, engineering analysis definitions and manufacturing definitions.

This information is developed during the following process stage:

  • Create structures detailed design

This information supports the following activities:

  • Preliminary structural design, including hull form design
    • Design transverse bulkheads
    • Design transverse frames
    • Make hull detail design
    • Define plates
    • Define profiles
    • Define brackets
    • Define holes and penetrations
    • Define notches for cutouts

This information is used in the following interchanges:

  • Detailed design engineer and visualization clients
  • Integration of designs from different design engineers
  • Shipyard and customer (design deliverable)

This information contains the following kind of entities and associations:

  • Characterization and definition of structural parts and systems (plate, profile, built_profile, plate_strake, corrugated_structure, panel_system)
  • Structures functional definitions
  • Structures design design definitions
  • Solid (Brep) explicit geometric representations

The following are out of scope for this use case:

  • Associations to moulded surfaces
  • Cross sections
  • Joint and weld design definitions

Feature Based Design (edo218-feat)

This ship structures (feature-based design) information use case describes the information needed to define the product model for the detailed design of ship structures - including hull, bulkheads, decks and foundations. This use case consists of a parameterized feature-based representation of the product items that comprise the ship structures detailed design. This use case does not contain any other (explicit) geometric representation of the design product model. The geometric entities contained in the use case are used only for the definition of explicit user-defined features.

This use case is based upon entities and associations defined in ISO10303-218, Ship structures. Note that this standard, also known as Application Protocol (AP) 218 is a superset of the current use case and includes a number of information elements not used in this use case: such as various geometric representations, changes and version history, approvals, engineering analysis definitions and manufacturing definitions.

This information is developed during the following process stage:

  • Create structures detailed design

This information supports the following activities:

  • Preliminary structural design, including hull form design
    • Design transverse bulkheads
    • Design transverse frames
    • Make hull detail design
    • Define plates
    • Define profiles
    • Define brackets
    • Define seams and beveling
    • Define holes and penetrations
    • Define notches for cutouts

This information is used in the following interchanges:

  • Detailed design engineer and structural analysis engineer
  • Detailed design engineer and manufacturing engineer (for lofting, nesting)
  • Integration of designs from different design engineers
  • Shipyard and customer (design deliverable)

This information contains the following kind of entities and associations:

  • Characterization and definition of structural parts and systems (plate, profile, built_profile, plate_strake, corrugated_structure, panel_system)
  • Structures functional definitions
  • Structural part connections (joints)
  • Weld design definitions

This information contains the following geometric representation:

  • The geometric shapes of ship structures are represented parametrically using a designated set of structural features. For an explicit geometric representation, see use case edo218-cad.

Heating, Ventilation, and Air-Conditioning Design (edo227-hvac-physical)

The HVAC physical design information use case entails the information needed to describe one or more heating, ventilation and air-conditioning (HVAC) spatial designs. The spatial design corresponds to the final, physical design, which describes the layout of the HVAC system and components in the ship and provides enough detail so that the system can be manufactured or acquired.

This information is developed during the following process stage:

  • Finalize HVAC layout and spatial design

This information supports the following activities:

  • Shop fabrication; outfitting/installation
  • Material ordering

This information is used in the following interchanges:

  • Design engineer and system engineer
  • Design engineer and fabricator
  • Integration of designs from different design engineers
  • Shipyard and customer (design deliverable)

This information contains the following kind of entities and associations:

  • Characterization of physical HVAC components
    • Including Ducting, the types of HVAC fittings used in ship construction.
    • Sufficient detail to support acquisition or manufacture of the components.
  • Identification of catalog information associated with each component
  • Connections (joints) and connectors (ports) for HVAC components

This information contains the following geometric representation:

  • The shapes of HVAC components and ducting are specified parametrically based on a small number of values per each type of component.

Physical Piping Design (edo227-pipe-physical)

The piping physical design use case (edo227-pipe-physical) describes the information needed to define the product model for ship's piping detailed design. The purpose of the use case is to provide enough information regarding the centerline geometry, connectivity, joints, pipe and piping components to manufacture and install the piping product model. This use case includes the specification of the occurrences (instances) of the piping product model as well as the parts (i.e., engineering data for a pipe or piping component that is applicable to all occurrences of that part).

For a more detailed description of the information requirements of this use case, see ISO10303-2227 (ed 2). Note that this standard, also known as Application Protocol (AP) 227 is a superset of the current use case and includes a number of information elements not used in this use case.


Functional Piping Design (edo227-pipe-functional)

The piping functional design use case (edo227-pipe-functional) describes the information needed to define the product model for ship's piping functional design. This entails the information traditionally associated with a piping diagram, exclusive of the schematics. The purpose of the use case is to provide enough information regarding the connectivity, joints, pipe lines and piping components to define the piping product model from a functional perspective. This use case includes the specification of the occurrences (functional instances) of the piping product model as well as the parts (i.e., engineering data for a pipe or piping component that is applicable to all occurrences of that part).

For a more detailed description of the information requirements of this use case, see ISO10303-2227 (ed 2). Note that this standard, also known as Application Protocol (AP) 227 is a superset of the current use case and includes a number of information elements not used in this use case.


Common Parts Catalog (cpc)

The Common Parts Catalog uses cases describe scenarios for the sharing and representation of parts and associated document information. These scenarios include not only the sharing of parts data among internal shipyard applications but also across organizations for collaborative purposes. The uses cases can be found at NIIIP ISEC Phase 3 Electronic Commerce Task Milestone 6 - CPC Use Cases.

The primary purpose of the CPC context is to provide a means to represent parts data, specifically, procured, commodity parts. Each part type contains the properties needed to describe the characteristics needed to evaluate the usefulness of a part for a particular purpose and to distinguish the part from other alternative parts available perhaps from other vendors. There are two categories of "parts" that are deliberately excluded from this context: complex, high-level assemblies and CAD parts. Although the CPC datastore provides for rudimentary product structuring, high-level, custom designed assemblies are represented in PDM contexts. Similarly, while each catalog part is associated with one or more geometric (CAD) representations, these representations are not managed as part of the CPC context - rather these parts are represented in the product model contexts by discipline.

One of the most challenging aspects of parts data management is identification. Each part in the CPC context is identified, persistently, by an identifier that is unique to the organization supplying the part; and that organization's identifier is, thus, a component of the part identifier. The CPC context also supports part equivalency; an equivalency association links a part to the equivalent parts in other CPC datastores. This association is needed because parts identifiers are specific to each owning organization. Finally, CPC parts may also be associated to National Stock Numbers.

One feature of the parts schema is that it embodies a particular classification scheme. There is one base type for all parts (cpc:Catalog_item), but every kind of part is a subtype. The inheritance of part types is forms a hierarchy, which is the CPC classification scheme. It should be noted that other classifications could be applied to CPC data and that this particular classification, because of the convenience that it provides for navigating CPC part types, is explicitly captured in the information model. Some classifications may be somewhat unexpected; for example, many part types are distinguished by means of a separate metric and non-metric part type.

Another important feature of the CPC context is that it includes parts-related documents, that is, various documents that are need to qualify and describe the parts themselves. Part documents include various specification documents. Parts documents may be versioned and amended; particular versions of part documents are associated with the pertinent parts. Moreover, the association of part document to part also designates the hull applicability, those hull to which this particular version of a part document applies. Specification histories and part audit histories can also be represented. Finally, parts may be associated with various supplemental "documents", such as allowance parts lists (APL), CAS, and environmental legislation.