Business Overview

Business introduction

This DEX enables the exchange of information about a Product_as_individual for the purpose of supporting that product throughout life (product in focus (PIF)). It provides unambiguous identification of the PIF for support management purposes, its life and usage is reported on by utilising other DEXs (see fault_states), the analysis of tasks required to be performed (see task_set), and the generation of a logical plan for support (see maintenance_plan). The support solution is put in place (commissioned) for when the PIF is in build and thereafter in service. From this point on, information is collected and feedback is provided to the support facility (see operational_feedback). If maintenance is required, then a package of work is defined (see work_package_definition). Once the work is authorized and carried out, a report is produced to indicate when the work was completed together with any documentation required for the item repaired (see work_package_report). The design from which the product has been manufactured is represented by the use of product_breakdown_for_support, and references to the design are supported, as necessary by this Dex.

Figure 3 —  Context of Dex 008

The Product_as_individual is a generic term given by PLCS to a product which is in the process of being realized and becoming an artefact rather than the subject of a design.

The Product_as_individual is conceived, designed, planned, fabricated or acquired, assembled, is in-service, retires, and is destroyed, recycled, or discarded. During its life cycle, almost anything about it may change:

• Its structural configuration may change as replaceable units are removed and replaced in the context of maintenance activities.
• Its usage role within the structure of another product may change, as it is removed and reassembled into a different actual assembly, in a different slot, possibly even a different design.
• Its properties may change as it is maintained, or as it wears.
• Owners and even part identifiers may be added or discarded, due to changes in processes, suppliers, or ownership.

This DEX collects all the capabilities to instantiate and refer to products as planned and products as realized, and to identify them, their configuration, and the associated designs, as these vary over time.

Life Cycle Context

The Product_as_individual consists of two types; the Product_as_planned and the Product_as_realized. This is described in detail by the capability representing_product_as_realized
Error C1: Capability representing_product_as_realized not in dex_index.xml
.

The former supports the view of the product planned for manufacture or future configuration (when in service). These two business uses are at different stages of the lifecycle but both clearly have a dependence on the design and a relationship to each other.

During the design process the product is allocated a "part number". During manufacture, the OEM may allocate a line (or assembly) number which is responsible for the production of the individual products. During this "plan for manufacturing" stage, the line/assembly number is allocated to the product as planned. Once the product has been built, it is allocated a serial number. The serial number is added to the product as realized entity.

When producing a complex product, the design will often allow the use of standard parts in various modes of configuration. A production facility may already have a supply of some parts available, so the serial numbers of these parts may already be known when the OEM executes a plan for manufacture. These can of course then be added to the planned version in the model. However, this would be in addition to the line/assembly number as this also allocates supplies to the production/assembly line.

Unless there is a close relationship between the manufacturing facility and supplier, the serial number of supplied parts may not be known until delivered. This means for a production line using just-in-time methods, it may not be possible to identify serial numbers before production. Alternatively, the parts to be fitted may attract no maintenance interest in them as individual products (e.g. nuts, bolts etc.,). In these cases, it is usual that the parts are either known by their catalogue or stock number, Hence, the product as planned may attract either of these at this stage of the lifecycle. After-market products (generic parts usually made to fit a range of products already in service) are generally reffered to through their part number (attached to the design). Such parts usually provide non-critical functions additional to that of the design.

Supplied parts provided in conjunction with the overall product design, may themselves be managed products with their own life cycle of planned production and realization. They may attract a maintenance interest or may simply be replaced when necessary as described by the OEM of those parts or as specified in the context of their use.

The latter representation of individuals supports the product as realized. This allows for the representation of a serial number for through-life support by the end user or support facility. However, during the support period, the realized configuration may need to change (for whatever reason). This plan for the future configuration of the product is represented using new instances of the product as planned entity. If serial numbers are known for key parts then these are added to the instance data. Other components would attract part number, a catalogue number, or a stock number instead, or until the serial number can be determined. The distinction here, during this in-service phase, is that there is no line/assembly number information. This is because the product is no longer on a production line.

When the refit or change to the configuration occurs, a new set of product as realized instances are created recording the serial numbers of all new the items attracting usage or maintenance infromation.

This information may be added to the original product data so that both the configuration representation and the relationships between the versions are accessible in the support environment. The end user, however, may only be interested in the current configuration information rather than the historical aspects.

The table below attempts to set out the use of these concepts and identifiers.

Table 1 — Typical Life Cycle Stages and PLCS Concepts and Identifiers

NOTE    This figure (and table) is for illustration only. The different life cycle views are discussed below.

Manufacture, Assembly and As-Built

The main difference between the representation used for the product planned for manufacture / assembly stage versus that of the design, is that the former uses instances of Product_as_planned rather than instances of Part which are used for the design.

Each instance of Product_as_planned has a relationship back to the representation of the design from which it originated. The Product_design_to_individual provides this functionality for this situation. If there is no corresponding design part, (for example if using an after-market 'generic spare'), a new part instance may be created (along with any required concessions for use), and related to the planned version.

The original equipment manufacturer (OEM) may also specify an assembly line number (or similar) to indicate the plant equipment used in the manufacture / assembly process. This allows tracking of the part by the OEM back to the tools, equipment and raw material inventory of the factory / plant.

When the various parts are either identified by serial number or gain a serial number through manufacture, the representation may be transformed into instances of Product_as_realized. When this happens would be a business decision based upon when the product is deemed to be complete enough to be referred to "as-built". For example, a ship's build date may be determined when the keel has been laid (usually a concrete ballast). As construction procedes, additions to realized representation are constantly added to after this date as the ship is built - usually right up to commissioning. During this time more and more of the planned product becomes realized.

When instances of Product_as_realized are created, and the realized product is the result of a planned configuration, these instances are related (through Product_planned_to_realized) back to their corresponding Product_as_planned instances. Hence, because the planned product will have a relationship back to the design, the final realized product can be traced back to it's design.

When serialized parts are available and the "as-built" configuration is already populated, there may be no Product_as_planned version produced. This might apply when creating an installation straight from the design with parts already available, or perhaps when a repair is carried out in an emergency. For occasions such as this, the Product_as_realized is related directly to the design Part through an instance of Product_design_to_individual where the individual is the realized product.

The result is an as-built product which is represented by a set of product as realized instances. However, in a practical real-world environment, the reality may be that there exists a mix of product as realized and product as planned individuals at the as-built stage. This is because for very complex products, some systems may not have been installed or parts have been difficult to source.

In all, there may now exist 3 separate product trees; one of the design view (using Parts), one of the planned view (using Product_as_planned), and one of the as-built view (using Product_planned_to_realized). However, as noted before, there are relationships established between them such that the configuration can be tracked at each stage.

The figure below attempts to show the life cycle progression of a typical product and to show the relevant PLCS concepts used at each stage.

Figure 4 —  Typical Life Cycle Stages and PLCS Concepts

Establishing the Current Configuration Baseline

Occassionally, not all product configurations have been completed as planned and a ship might sail either with deficient equipment or with a different set of parts than was planned. Hence there may be a difference between the planned and that which is realized. In the first case. where product configuration components have been planned, but not fitted and no alternative or substitutes have been used, then there will exist a set of Product_as_planned instances, but with no corresponding realized instances since the parts have not been fitted.

In the latter case, where valid alternatives have been used, then there will exist a set of Product_as_realized instances along with references back to the design through Product_design_to_individual relationship instances.

NOTE    An alternative only differs from the ‘as planned’ by part No./manufacturer.

When valid design alternatives are not available (e.g. when at sea) then it may be practical to either;

• cancel operation
• operate with the equipment effectively disabled
• operate with equipment with a reduced functionality
• operate with a re-configured piece of equipment (without the missing parts)
• operate with a make-shift replacement in current configuration

In the last two situations a variance against the configuration might be justified and a deviation logged under the in-service set of realized instances. In the former of these two, the variance would be against the permissible configuration(s), whereas the latter would be against the alternatives. These two variances will have no link back to the design options as with other alternates, because this was not catered for by the design. However, new (dummy) part instances should be created in the design and linked to the new realized instances of the current configuration to ensure a consistent representation (along with the relevant documents, approval, justification and classification (as a variance)). The most expensive option is not to run (operate) the ship at all, although this would be an extreme case and would be considered a major issue.

In-service Changes

During the operation of the product, damage occurs, trade routes and missions change, requiring a refit or a change in configuration of the product. This will require another set of instances of Product_as_planned to represent the future configuration of the product.

Just as in the manufacturing stage, there should be a set of relationship instances (Product_design_to_individual) linking the planned version back to the representation of the design from which the configuration options originated. Thus, even during the in-service phase, planned products are still required.

The planned representation may be held separately from the current in-service configuration or together as one. The new planned view needs to reference where in the current configuration it fits and vice-versa. The planned components may only have catalogue or stock numbers available when originally determined, although when the change is approved, a serial numbered part may be allocated by a stores / provisioning allotment. Hence, even though the product is still planned, there may already exist a serial number for some parts. For example, an electric motor on a stores shelf.

NOTE    There is no explicit representation to identify the process of serialized part allotment, only the implicit deduction when a serial number has been provided.

During the refit, the supplied components have their serial numbers read and a new set of realized instances can be created along with the links to the parallel planned instances. Once the configuration has been updated to reflect the latest build, the items concerned can resume or begin their lifing and usage recording.

It is unlikely that during a refit any design / manufacturing / assembly line information will be added to the planned version.

The changes to the configuration are all recorded on a Configuration Status Record which ensures assurance of the Product and Support Information.

© OASIS 2010 — All rights reserved