Product as Individual Business Process

AP239 Application Activity model definitions

The AP239 Application Activity Model (AAM) is an IDEF0 representation of the business activities that assist understanding of the scope and information requirements defined in AP239. The model is presented as a set of figures and a set of definitions of the activities and their associated information flows.

This DEX will support a subset of the activities and data flows. These are highlighted in yellow in the subsequent figures.

Activities and data flows that are out of scope of AP239 are marked with an asterisk.

AP239 Activity model definitions

The following terms are used in the application activity model.

Manage identification

action to provide unambiguous identification of all elements, and versions, of the product or support system to which reference needs to be made, identification of interfaces between elements, the necessary assembly, and other breakdowns structures, required to manage the product through life and definition of the information to be held for each type of product and support system element

NOTE   

This activity occurs throughout the product life cycle and is the basis of management of configuration change and configuration status accounting of a product and all constituent configuration items. The purposes and benefits of this activity include:

• determining the structure (hierarchy) of a product and the organization and relationships of configuration documentation and other product information;
• documentation of the performance, interface and other attributes of a product;
• determination of the appropriate level of identification marking of product and documentation;
• unique identification of a product or component part of a product;
• unique identification of the technical documents describing the product;
• modification of identification of product and documents to reflect incorporation of change;
• distinction between product versions;
• correlation of document revision level to product version;
• correlation of a PIF to related user or maintenance instructions at the configuration item level.

request for identifier

request to provide identification for new elements of the product or support system element

NOTE    Requests may arise from new product concepts, developing breakdowns of existing products, or from changes.

information need *

specification of the information that shall be developed and maintained within the APSI for any PIF or support system element or class of elements

PIF structure

integrated set of classified elements and interfaces, product structure views and relationships between product structure views required to provide life cycle support

NOTE   

The PIF structure comprises:

• the set of breakdown and assembly views being maintained for the product in focus including effectivity statements on the current, required and permitted configurations of each individual planned or realized product;
• relationships between breakdown and assembly views such as functional to physical links for both design and individual structures;
• identification of interfaces between elements.

PIF scope

identification of the group of actual or potential operational products and related items that require support during their life cycle

NOTE   

The PIF scope can include:

• many versions of a product design;
• many operational products, used by different users in different ways;
• any part of the operational product needing support;
• any related item that requires support.

product & support element information

any information about the product in focus and related support elements that is required by participants in life cycle support

NOTE   

This information may include:

• product definition information;
• product performance information;
• predicted failures;
• diagnostic data;
• descriptions of the product or support element;
• manufacturing records;
• product characteristics of relevance to support;
• descriptions of people and organizations;
• the operating and maintenance history of individual acquired items if relevant to future support.

Manage information

action to manage the information related to a PIF

NOTE    This activity corresponds to configuration and data management and the major output is APSI, which encompasses the entire configuration and support data. A subset of the APSI is the configuration status record. The dynamic nature of the configuration and data management activity, and its importance within the operation of a consistent configuration management process throughout the product life cycle requires a formal approval process to attain APSI status. All configuration documentation (requirements and design documentation) and associated operational information (operating procedures, parts catalogues, and so on) that comprise the configuration status record must be formally managed and approved. In essence, approve, release and record is a process that makes configuration and support documentation available for use, subjects it to configuration change management and maintains the assured status of the APSI.

APSI and related information

set of assured and related information used to develop and deliver support for a product in focus, including feedback from using and supporting the product over its life cycle

NOTE    Related information includes records of the history of the usage or support of realized products, design and support analysis results and reasons why decisions were taken. Such information includes design and failure analysis records, logistic support analyses, running hours, environment descriptions, operating profiles; test results, records of maintenance activities, resources used, and faults found plus any other content deemed relevant to life cycle support.

Identify product & support system elements

action to provide both unambiguous identification and classification of all elements forming part of the PIF and its support system to which reference needs to be made, including interfaces and other relationships between such elements to which configuration management shall apply

NOTE    Classification of elements and interfaces can be used to assist in defining information needs.

classified element or relationship

element of the PIF or its support system and that has been identified and assigned to one or more classes of element, plus any relationships between elements needing to be tracked for support purposes

NOTE    Unambiguous identification includes the assignment of a name (for use by humans) and an alphanumeric identifier (for use within computers) that are unique within a context. The context for a name or identifier is the organization that provides the name and identification. Elements can have more than one name and identifier assigned by different organizations. The classification of an element can include a class that helps identify the APSI that is required for this element type. Relationships can include any of those specified by the information model of this part of ISO 10303.

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.

DEX Business application

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 D002: fault_states), the analysis of tasks required to be performed (see D003: task_set), and the generation of a logical plan for support (see D005: 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 D007: operational_feedback). If maintenance is required, then a package of work is defined (see D004: 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 D009: work_package_report). The design from which the product has been manufactured is represented by the use of D001: product_breakdown_for_support, and references to the design are supported, as necessary by this Dex.

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.

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.