| DEX: (D001) product_breakdown_for_support — Product Breakdown for Support |
Use of this DEX can be broken down into several aspects:
The capabilities that provide this functionality are summarised in Figure 1
NOTE The diagram above illustrates those capabilities that have a bearing upon the definition of the product to be supported. They are collected into functional groups which relate the capabilities within. The diagram does not show the relationships between the capabilities within or across these functional groups. Each capability shows how they use others in an overview diagram within the Information Model section at the beginning of each capability.
NOTE A part may be refered to through it's design by the EXPRESS entity Part, though the actual occurence of a version of the product may also be referenced instead, as represented (for example,) by the EXPRESS entity Product_as_realized.
Managing information relies upon identification and this is a recurring key concept within PLCS and this Dex.
An Identification_assignment (see capability C001: assigning_identifiers for details), is the assignment of an identifier to product or activity data. Such items are identified by creating an identifier that is unique in the context of an organization (or enterprise) and assigning the identifier to the item. Examples of items to be identified include; Parts, Tasks and Organizations.
The approach adopted is compatible with that provided in the DOD Memorandum "The Department of Defence Guide to Uniquely Identifying Items, Version 1.3" dated November 25th, 2003.
EXAMPLE Identifiers can be Serial Numbers, Part Numbers, Nato Stock Numbers, CAGE Codes etc..
EXAMPLE Organizations that provide the context for an identifier include; Prime Contractor, Design Owner, MOD, Catalogue Owner.
PLCS uses a general approach to identification that comprises the following four key assignments;
An approval is an action by means of which a product or activity or other item is agreed to or officially confirmed as acceptable or satisfactory by a person or organization. See capability C019: assigning_approvals for details.
EXAMPLE A product design might be approved by a customer prior to the commencement of manufacture.
In basic approvals, only one signature or authorization is required. In complex approvals, a series of authorizations may be required for a single approval with a particular status, or a cycle of coordinated approvals that vary in status. Moreover, a single approval may apply to a number of different items. In the case of an approval that applies to a number of items, the assignment of the approval may have a single role or multiple roles.
EXAMPLE An example of a basic approval might be the authorizing of a part design by an individual on a certain date.
EXAMPLE An example of a complex approval with a multiple approval statuses might be an approval cycle where provisional approval is required from a subordinate before an item may be considered for final approval by a superior.
EXAMPLE An example of a complex approval where an approval applies to a number of items might be the authorization of a series of sub-contracts for a sub-assembly designs on the same day.
Approvals are established through the creation of Approval objects and related to other constructs using Approval_assignment objects. Persons and or organizations are related to Approval objects using Approving_person_organization objects. Relationships between Approval objects are established by means of Approval_relationship objects.
Representing the product structure can be broken down into several aspects:
The representation of the product parts;
The representation of a Part, defines the design of a Part whether it be designed to be independent or a component of a larger product or assembly. Parts need to be identified because, through life, they may need to be replaced. For example, due to wear, life expectancy, failure rate, or part alternatives. They may also need to be removed or substituted for other parts through mission requirements, upgrades or due to variants from redesign or reconfiguration.
Without adequate identification, the owner cannot be certain of the configuration of a product, that correct spares are available, that timely maintenence is being carried out, or that the product will fulfill it's functional requirements.
Therefore, each Part must be able to be uniquely identified so that it's usage in all Products that contain parts, such as assemblies, and other products can be recorded across both versions and variations of those products.
With adequate identification, the usual operations of the product might then be supported, for example, regular maintenance, condition based maintenance, usage reporting, failure reporting, part changes, function changes, replacements and the upkeep to both the product and the APSI can be enabled.
The AP239 approach to representing parts is detailed in capability C002: representing_parts and comprises the following steps;
The representation of the product design's assembly definition;
The assembly definition is represented using explicit hierarchical product structures (e.g. Next_assembly_usage) representing assemblies and the constituents (Parts) of those assemblies. This explicit part structure corresponds to the traditional engineering and manufacturing bill of material (BOM) indentured parts list. Relationships between (Part_view_definitions are the principle elements used to structure an explicit part assembly configuration. The relationship itself represents a specific usage of the constituent part definition within the immediate parent assembly definition. Mechanisms to represent quantity associated with this Assembly_component_relationship usage are also provided.
It also has the capability to identify and track a specified usage of a component definition in an assembly at a higher level than the immediate parent subassembly. Consider a wheel-axle subassembly composed of one axle and two wheels, the right and the left. A higher-level chassis assembly is in turn composed of two wheel-axle subassemblies, the front and the rear. The requirement to individually identify the left-front wheel, for example, is supported by this capability.
Different view definitions of the same version of a part may participate in different explicit product structures. For example, a design/as-planned view of a particular version of a part, representing the design discipline part definition, may be engaged in an explicit design assembly structure. A manufacturing/as-built view of the same part version represents the definitional template for the actual physical part, and may participate in a manufactured assembly structure that is different from the design assembly structure. Finally, a support/as-maintained view of the part version representing the physical part definition may participate in yet another different disassembly structure.
In addition to hierarchical assembly structures, capability C003: representing_assembly_structures supports relationships between parts to characterize explicit alternates and substitutes for the assembly. Other relationships between part definitions exist to characterize the make from relationship and for supplied part identification.
The representation of the various breakdown views to aid the support solution;
The representation of the various breakdown views provides the necessary information to enable the delivery of assured product and support information (APSI) from the Original Equipment Manufacturer (OEM) (for example, Ship Builder , weapon system developer, bicycle manufacturer), to the owner, operator or maintainer who is required to support the product when in service.
Depending upon the specific product, various views of the product will be required to enable the identification of the various systems, functions, or physical parts, together with identifying zones within the product or a combination of these (hybrid view).
A breakdown is a partitioning of a product into a set of related elements to support engineering, analysis and other activities that may be performed in relation to the product. These breakdowns are explicit, parent-child views that comprise the product elements.
These views may be represented through a Breakdown (that specifies the representation of various breakdowns of products), or through one of it's subtypes, such as; System_breakdown (for the representation of various breakdowns of a systems), Functional_breakdown (for the representation of various functional breakdowns of products), Physical_breakdown (for the representation of various physical breakdowns of products), Zone_breakdown (for the representation of various zonal breakdowns of products), or through a Hybrid_breakdown (for the representation of various hybrid breakdowns of products).
With the identification of these aspects, the usual operations of the product might then be supported, for example, regular maintenance, condition based maintenance, usage reporting, failure reporting, part changes, function changes, replacements and the upkeep to both the product and the APSI can be enabled. These views are documented as various types of product breakdowns.
The AP239 PLCS approach to product breakdown (as defined within capability C004: representing_breakdown_structure) comprises the following;
The alignment of the breakdown views to the assembly;
The breakdown views (see the C004: representing_breakdown_structure capability for details), are complementary to the assembly structure and bill of materials views that are the primary focus for manufacturing of a product (see the C003: representing_assembly_structure capability for details). They may add further relationships between part view definitions that already exist. Breakdowns may be of designs or realized individual products. For any product, more than one breakdown may exist to support various different activities.
Because breakdowns and assemblies are complimentary, they must be consistent whenever and wherever possible. Hence a part in an assembly maybe the realization of a physical_breakdown_element. It could also be that the functional_breakdown_element "provide fuel to engine", is realized by the physical_breakdown_element "pump". By defining the links between the assembly and breakdowns the views become dependent upon each other which is useful to the assessment of impacts when the product undergoes support.
A property is the definition of a special quality and may reflect physics or arbitrary, user defined measurements. Properties may be assigned to parts, assemblies or to any other product.
STEP allows the assignment (see C076: assigning_product_properties) of multiple properties to products. It also makes a clear distinction between the property itself (covered in this capability) and how the value of the property is represented (see C079: representing_properties_numerically and C080: representing_properties_textually).The STEP approach is flexible, allowing new properties to be defined "on the fly". This can lead to problems of properties not be understood by receiving partners. Hence, the PLCS approach, and this Dex, uses the STEP property model, with the added requirement that all assigned properties must be classified using reference data. This retains the flexibility, but adds the semantic rigour required for unambiguous data exchange.
The Dex supports the definition of product concepts, which define products from a market or customer oriented viewpoint. As they are offered to the customers, these product concepts often define conceptual 'product models' which are available or delivered to the customer in different configurations or variations.
Configuration identification in this Dex is the identification of product concepts and their associated configurations, the composition of which is to be managed. If a configuration of a product concept is implemented by a certain design, i.e., a particular part version, this version can be associated with the configuration and managed using configuration effectivity.
NOTE Explicit representation of the configurations of a product concept is suitable for management of design as-planned manufacturing configurations, the traditional BOM inputs to manufacturing resource planning. These explicit configurations may also be suitable for management of other activities 'downstream' from the design phase, such as as-built and as-maintained configurations.
The representation of configuration identification is described in the capability C063: representing_product_configuration, and whilst closely related, the representation of configuration composition management is described in the capability C006: assigning_effectivity.
Representing Product Configuration
The products that are sold by an organization to its customers are often defined as variations or configurations of a common product model, referred to as product concept. This product concept is defined in a market context and can be seen as a logical container for all of its variations. In the PLCS Schema, product concept identification is the representation of these product concepts with their related market context.
A Product_concept describes a class of similar products that an organization provides to its customers. It represents the idea of a product as identified by potential or actual customer requirements. Therefore, a Product_concept may exist before the Parts have been defined that implement it.
Depending on the kind of industry and products, a product concept might be offered to the customers in one or many different configurations. If exactly one Product_configuration is defined, the Product_concept corresponds to a particular Part design. If the product concept is offered in different configurations, each of these Product_configurations is a member of the class of products defined by this Product_concept.
EXAMPLE There might be a manufacturer of a personal computer system which is marketed to both the US and the European markets. The design may allow for two configurations; one for the US and one for Europe. The configuration is only different in that a different power supply is used depending upon which market the PC is assembled for. Another manufacturer may have a switchable PSU and may therefore, only need one configuration.
NOTE The identification of the Product_concept is provided in more detail in the C001: assigning_identifiers capability.
NOTE There might be several levels of product concepts defined in a company. The description of product concept structures and relationships is not supported by the current PLCS Schema, nor this Dex. It is therefore recommended to instantiate the lowest level product_concept that is offered to the customer.
A Product_concept represents a conceptual idea of a class of similar products that are offered to a Market. No design or manufacturing related product data can be attached to the Product_concept directly. The members of that product class are the different configurations that are available for the Product_concept. Within the PLCS Schema, these configurations are defined explicitly as Product_configurations, each of them being potentially related to the Parts that implement the particular configuration. A Product_concept will usually be referenced by at least one associated Product_configuration specifying a particular configuration. See the capability C063: representing_product_configuration for more details.
The Product_configuration defines a manufacturable end item, or something that is conceived and expected as such. The association between a Product_configuration and a corresponding part design (Part_version) is established using an instance of Item_design_association. The valid use of component parts for planned units of manufacturing of a particular Product_configuration may be specified using configuration effectivity (see C006: assigning_effectivity.
An instance of Part_version represents the version of a definition (Part_view_definition). These definitions may be related together to produce an assembly (a parent-child relationship) using instances of Next_assembly_usage. This provides one of the key ways for representing the design of an assembly, the details of which, are provided in C003: representing_assembly_structure.
Effectivity is a key concept to control the valid use of product data. This Dex supports the association of effectivity information to different types of product data through the Item_usage_effectivity entity. This entity represents a tuple of; a resolved_configuration (an instance of Item_design_association - see above or C063: representing_product_configuration), an effectivity_domain (an instance of a type of Effectivity), and an item_usage_relationship (i.e. an instance of a type of View_definition_usage, such as Next_assembly_usage (see above or C003: representing_assembly_structure).
The Effectivity entity supports the specification of a domain of applicability for product data. Effectivity is a generic concept defining the valid use of the product data to which the effectivity is assigned.
The subtypes of Effectivity include;
These subtypes restrict the domain of applicability of the associated product data to a date range, a particular lot or serial number range, or to a time interval respectively.
Hence, an instance of Item_usage_effectivity may associate a Product_configuration (through the Item_design_association), and a definition of the assembly (Next_assembly_usage through View_definition_usage) with a type of Effectivity.
Configuration effectivity allows attachment of effectivity information to occurrences of component parts in the context of a particular configuration item. This enables the specification of the valid use of a part occurrence in the context defined for a particular product configuration. This controls the constituent parts that are planned to be used for manufacturing end items of a particular product configuration within a dated time period or for a certain lot or serial number range of the end items.
While configuration effectivity (as described above) is used to define the planned usage of components in the context of a particular product configuration, the Dex also allows assignment of general validity periods to product data that control the usage of these product data independent of any particular life cycle or context.
The validity period of Effectivity may be applied to different types of product data, potentially specifying an additional role in which the effectivity is assigned. The Effectivity_assignment entity defines a general mechanism to associate a general period of validity to some product data or activity.
The entity Effectivity_assignment refers to one or more items (instances) of product data to which the validity period is assigned. The types of product data to which an effectivity may be assigned are defined in the effectivity_item select type.
NOTE The assignment of effectivities is often done during the approval process, i.e, when releasing product data for the next stage of the development process, it gets effectivity information assigned to determine when and in which context these product data may be used.
The representation of the documentation of the product;
A Document may be used to represent many aspects of the product, such as;
Documents may be associated with product data in a specified role, to represent some relationship between a document and other elements of product data. Constraints may also be specified on this association, in order to distinguish an applicable portion of an entire document or file in the association. A Document_assignment may be used to relate a managed document to other product data. There is no limit on the number of documents assigned to a product or a component within an assembly or breakdown.
A Document can be thought of as a type of product, and as such, requires to be managed. A managed document is one under revision control, and may distinguish various representation definitions of a document version. The Document_version represents the minimum identification of a managed document under revision control. A Document_definition may be either a Digital_document_definition or a Physical_document_definition. The former of these may contain a number of Digital_files, whereas the latter may refer to a number of Hardcopy components. Document_definitions or Files may also be identified as an item of an externally referenced source (External_source_identification).
EXAMPLE A configuration controlled paper document such as a drawing would generally be represented through an instance of the entity Document, with a Document_version and a Physical_document_definition representating the view definition according to this approach.
External files are identified through a File_location_identification which allows the source to be associated with either a Document_definition or a File (digital or hardcopy). An external file is normally managed independently of the system - hence no revision control or any representation definitions are to be expected in such situations.
Extensive use is made of Reference Data Libraries to allow industry specific terminology to be called in to characterise the basic model. This Dex has the ability to classify entities in an exchange file as belonging to a class, where the definition of the class is provided in class library that is not part of the data exchange. The class library is often referred to as a reference data library (RDL).
Reference data are terms and definitions that has to be mutually understood by all parties involved in a information exchange.
In OASIS PLCS, reference data is used to extend and to tailor the AP239 data model to suit different groups of users.
EXAMPLE Standards such as DEFSTAN 0060 define a number of codes that classify documents. These would be considered reference data. They are agreed terms that could be stored in a RDL and then referenced by all parties in the exchange.
Reference data is applied using the Classification assignment, Attribute classification, and External class modules.
The reference data being applied has to be defined in an external source such as e.g. a database, a web-site or a published document. The source of the reference data should be stated in the id attribute of the External_class_library entity. The identification could be a URL, Document id or any other identifier that uniquely identifies the source. A complementary decription of the source can provided using the External_class_library description attribute
The reference data being applied can either be stated by name using the External_class name attribute, or by a unique identifier in the External_class id attribute provided that the source uniquely identifies each reference data element.
The relationship between the reference data and the entity being described/classified is established using Classification_assignment.
The reference data capability and it's use is described in greater detail in C010: assigning_reference_data.
Information describing an exchange of information by the usage of this DEX is provided by the capability C014: messaging. This is used to communicate meta-data associated with a specific message, such as the intent of the sender, identification of the business process (if any) of which the message forms part, or status information relating to the message itself.
Although this DEX will be used to communicate information about the product breakdown for support, it can also be used to exchange the assembly, breakdowns and documents, separately or together. In addition, variants or derivatives of a product may also be developed which may require only partial exchanges of the complete product. The assembly may be matured over time and different breakdown views may be adjusted accordingly. The alignment of breakdowns and assembly will, similarly, require subsequent adjustment.
These aspects are described above and are defined by the following capabilities;
Thepurpose of the communication may itself, be amplified by
associated documents. These are described by the capability
C005: representing_documents and referencing_documents![[warning:]](../../../../images/dex/warning.gif){kind=small}
Error C1: Capability referencing_documents not in dex_index.xml
.
Specifically, this DEX utilises the following capabilities:
C019: assigning_approvals C036: assigning_date_time C006: assigning_effectivity C001: assigning_identifiers C076: assigning_product_properties C010: assigning_reference_data C014: messaging C016: representing_person_organization C002: representing_parts C005: representing_documents C003: representing_assembly_structure C004: representing_breakdown_structure C079: representing_properties_numerically C080: representing_properties_textually C063: representing_product_configuration
NOTE Each capability has a "usage" section which provides a list of dependent modules and entities within it's scope. In addition, each capability provides an overview of how the capability relates to other capabilities. Each Dex, similarly, has a "Development views" section which provides a list of dependant capabilities and modules.
© OASIS 2010 — All rights reserved