The CPC 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.

CPC Interface Document Draft 03 Outline

CPC Service WSDL

Latest Deliverable:
cpc#current.zip
cpc#current-metadata.zip