| Business DEX (NDLO005):— individual_product_data | Date: 2007/10/12 12:27:18 Revision: 1.27 |
Purpose
This NDLO-DEX shall enable exchange of life-cycle product data from the development stage through the retirement stage, as input and reference to management processes, technical analyses, support and operation.
Usage
This NDLO-DEX provides input data for budget, planning and operation.
This section provides an overview of the business DEXs.
Product as realized
The figure above illustrates the main product (e.g. the ship) in the planning stage as product_as_individual and as product_as_realized when the product is built.
Parent product identification
The figure above grouped by the rectacles in different colours illustrates the following: the blue box indicates the fleet, the green box the main product product (e.g. the ship) and the red box relates the built product to possible siblings.
Component usage
The figure above grouped by the rectacles in different colours illustrates the following: the green box represents a configuration item, the light yellow box represents maintainable parts. The red box represents the main product and the dark yellow boxes represent the relations between a product, its parts and configuration items.
This NDLO-DEX is divided into 3 business DEXs and supports the business functions listed below. An "x" in the table indicates that the business function is available for the business DEX.
|
Function id |
Function description |
Business constraints |
Product as realized |
Parent product identification |
Component usage |
|---|---|---|---|---|---|
| 1 | Identify organization that assigned an identifier | This is a mandatory data item for all identifiers. | x | x | x |
| 1.1 | Assign CAGE code to the organization | There shall be only one instance of the class for an organization | - | x | - |
| 1.2 | Assign name to the organization | There shall be only one instance of the class for an organization | x | x | x |
| 2 | Identify the life cycle stage for which the data are valid | There shall be only one instance of View_definition_context with the same pair of classes for life-cycle stage and application domain. | - | x | - |
| 2.1 | Identify the life cycle stage to be the support stage | - | x | - | |
| 2.2 | Identify the life cycle stage to be the production stage | - | - | - | |
| 2.3 | Identify the life cycle stage to be the allocated baseline | - | - | - | |
| 2.4 | Identify the life cycle stage to be the functional baseline | - | - | - | |
| 2.5 | Identify the life cycle stage to be the product baseline | - | - | - | |
| 2.6 | Identify the life cycle stage to be the requirement baseline | - | - | - | |
| 3 | Identify the application domain for which the data are valid | A Product_view_definition shall reference only one instance of View_definition_context with the same pair of classes for life-cycle stage and application domain. | - | x | - |
| 3.1 | Identify the application domain to be product life-cycle support | - | x | - | |
| 4 | Identify the individual product | - | x | - | |
| 4.1 | Identify the individual product by contractor given serial number | - | x | x | |
| 4.2 | Identify the individual product by owner given serial number | There shall be only one such identifier with the same 'Owner_of' for a Product_as_individual. | x | x | x |
| 5 | Identify the planned version of the individual product | A planned version is optional information. Link Product_as_planned to Step #4. | x | x | x |
| 6 | Identify the realized version of the individual product | A realized version is optional information. Link Product_as_realized to Step #4.If 'exchange_data' not set, insert value '000.00' as required by S1000D. A code value is unique across all instances of Product_as_realized. | - | - | - |
| 7 | Relate the planned product to its realization | Links instances of Steps #5 and #6, i.e., #5 and #6 shall be versions of the same #4. | - | - | - |
| 8 | Identify the part that represents the design of the individual product | Link the Part that gets its identifier here to Step #4. | - | - | - |
| 8.1 | Identify a design part by its owner part number | There shall be only one such identifier with the same 'Owner_of' for a part. | - | x | - |
| 8.2 | Identify a design part by its OEM part number | There shall be only one such identifier with the same 'Owner_of' for a part. | - | - | x |
| 8.3 | Relate the individual product to its design | Link #6 to #8 . | - | - | - |
| 9 | Define the baseline context that the planned and realized product views represent | Use View_definition_context instances as appropriate with life-cycle stage classes that are defined in #2.x . | - | - | - |
| 10 | Identify contract award date for the individual product | Check for valid dates. Needs to be before the end of warranty date.Shall be assigned to both #5 and #6. | - | x | - |
| 11 | Identify planned and/or actual milestone date in production process (e.g. keel laying date) | Usual check for valid dates. Needs to be after contract award date and before the launching date.May be assigned to both #5 and #6. | x | - | - |
| 12 | Identify planned and/or actual release date from construction (e.g. launching date) | Check for valid dates. Needs to be after contract award date and before the end of warranty date. May be assigned to both #5 and #6. | x | - | - |
| 13 | Identify planned and actual delivery date | Check for valid dates. Needs to be after contract award date and before the end of warranty date. May be assigned to both #5 and #6. | x | - | - |
| 14 | Identify on-going or completed verification and validation tests for the individual product | There may be many activities with this code. They are distinguished by the context that they are assigned to via Applied_activity_assignment. | x | - | - |
| 15 | Identify planned and actual start for verification and validation tests | Check for valid dates. Needs to be after contract award date and before the end of warranty date. Shall be assigned to #14. Context of #14 decides whether this is planned or actual. | x | - | - |
| 16 | Identify planned and actual end for verification and validation tests | Check for valid dates. Needs to be after contract award date and before the end of warranty date. Shall be assigned to #14. Context of #14 decides whether this is planned or actual. | - | - | - |
| 17 | Identify on-going or completed warranty period for the individual product | There may be many activities with this code. They are distinguished by the context that they are assigned to via Applied_activity_assignment. | x | - | - |
| 18 | Identify planned and actual start date for warranty | Check for valid dates. Needs to be after contract award date and before the end of warranty date. Shall be assigned to #14. Context of #14 decides whether this is planned or actual. | - | - | - |
| 19 | Identify planned and actual end date for warranty | Check for valid dates. Needs to be after start of warranty date and before the hand-over date. Shall be assigned to #14. Context of #14 decides whether this is planned or actual. | x | - | - |
| 20 | Assign name to the individual product | There shall be only one such identifier for a Product_as_individual with the same 'Owner_of'. | - | - | - |
| 20.1 | Identify owner organization that has assigned an identifier | There shall be only one instance of the class for an organization. | - | - | - |
| 20.2 | Identify contractor organization that has assigned an identifier | There shall be only one instance of the class for an organization. | - | - | - |
| 21 | Define the requirement on the realized product for the probability to find a spare on site | May be assigned to #5 or #6 only. Apply #21.1, #21.2, #21.3, #21.4, #21.5, #21.6, #21.7, #21.8 . | - | - | - |
| 21.1 | Identify the requirement for the probability to find a spare on site | There shall be only one such identifier for a requirement. | - | - | - |
| 21.2 | Identify the requirement version for the probability to find a spare on site | There shall be only one such identifier with the same 'Owner_of' for a requirement version. | x | x | x |
| 21.3 | Identify the property and its value for the probability to find a spare on site | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 . | x | - | - |
| 21.4 | Identify the requirement source by its name | Assign to Document_version in #21.8 .There shall be only one such identifier for a Requirement_source. | - | - | - |
| 21.5 | Identify the organization that is the source of the requirement by its name | There shall be only one such identifier with the same 'Owner_of' for an Organization. | - | - | - |
| 21.6 | Identify the address of the organization that is the source of the requirement by its name | There shall be only one such identifier with the same 'Owner_of' for an Organization. | - | - | - |
| 21.7 | Identify the document that describes the requirement | Use #1 . | - | - | - |
| 21.8 | Identify the version of the document that describes the requirement | Relates to #21.7 .Use #1. | - | - | - |
| 22 | Classify the representation of the quantity value as required value | There will be no more than one class instance for one instance of the value_component. | - | - | - |
| 23 | Classify the representation context of the quantity value owner data | There will be no more than one class instance for one instance of the value_component. | - | - | - |
| 24 | Assign the requirement for the number of maintenance levels to the realized product | May be assigned to #5 or #6 only.Apply #24.1, #24.2, #24.3, #21.4, #21.5, #21.6, #21.7, #21.8 . | - | - | - |
| 24.1 | Identify the requirement for the number of maintenance levels | There shall be only one such identifier with the same 'Owner_of' for a requirement. | - | - | - |
| 24.2 | Identify the requirement version for the number of maintenance levels | There shall be only one such identifier with the same 'Owner_of' for a requirement version. | - | - | - |
| 24.3 | Identify the property and its value for the number of maintenance levels | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 . | x | - | - |
| 25 | Assign the requirement for the number of days of independent operation with no spare replenishment to the realized product | May be assigned to #5 or #6 only.Apply #25.1, #25.2, #25.3, #21.4, #21.5, #21.6, #21.7, #21.8 . | - | - | - |
| 25.1 | Identify the requirement for the number of days of independent operation with no spare replenishment | There shall be only one such identifier with the same 'Owner_of' for a requirement. | - | - | - |
| 25.2 | Identify the requirement version for the number of days of independent operation with no spare replenishment | There shall be only one such identifier for a requirement version. | - | - | - |
| 25.3 | Identify the property and its value for the number of days of independent operation with no spare replenishment | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 .Combine the value with its unit as per Step #25.4 . | x | - | - |
| 25.4 | Identify days as unit of measure for time based properties | Unit.si_unit='f'. There is one Time_unit instance for one Part_view_definition instance. | - | - | - |
| 26 | Assign the requirement for the period for support resources at higher echelon with no replenishment to the realized product | May be assigned to #5 or #6 only.Apply #26.1, #26.2, #26.3, #21.4, #21.5, #21.6, #21.7, #21.8 .Typically echelon=2. | - | - | - |
| 26.1 | Identify the requirement for the period for support resources at higher echelon with no replenishment | There shall be only one such identifier with the same 'Owner_of' for a requirement. | - | - | - |
| 26.2 | Identify the requirement version for the period for support resources at higher echelon with no replenishment | There shall be only one such identifier with the same 'Owner_of' for a requirement version. | - | - | - |
| 26.3 | Identify the property and its value for the period for support resources at higher echelon with no replenishment | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 . | x | - | - |
| 26.4 | Identify years as unit of measure for time based properties | Unit.si_unit='f'. There is one Time_unit instance for one Part_view_definition instance. | - | - | - |
| 27 | Assign the requirement for the time period until planned product modernization to the realized product | May be assigned to #5 or #6 only.Apply #27.1, #27.2, #27.3, #21.4, #21.5, #21.6, #21.7, #21.8 . | - | - | - |
| 27.1 | Identify the requirement for the time period until planned product modernization | There shall be only one such identifier with the same 'Owner_of' for a requirement. | - | - | - |
| 27.2 | Identify the requirement version for the time period until planned product modernization | There shall be only one such identifier with the same 'Owner_of' for a requirement version. | - | - | - |
| 27.3 | Identify the property and its value for the time period until planned product modernization | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 . | x | - | - |
| 28 | Assign the requirement for the planned time period between base overhaul to the realized product | May be assigned to #5 or #6 only.Apply #28.1, #28.2, #28.3, #21.4, #21.5, #21.6, #21.7, #21.8 . | - | - | - |
| 28.1 | Identify the requirement for the planned time period between base overhaul | There shall be only one such identifier with the same 'Owner_of' for a requirement. | - | - | - |
| 28.2 | Identify the requirement version for the planned time period between base overhaul | There shall be only one such identifier with the same 'Owner_of' for a requirement version. | - | - | - |
| 28.3 | Identify the property and its value for the planned time period between base overhaul | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 . | x | - | - |
| 28.4 | Identify months as unit of measure for time based properties | Unit.si_unit='f'. There is one Time_unit instance for one Part_view_definition instance. | - | - | - |
| 29 | Assign the requirement for the planned time period between major overhaul to the realized product | May be assigned to #5 or #6 only.Apply #29.1, #29.2, #29.3, #21.4, #21.5, #21.6, #21.7, #21.8 . | - | - | - |
| 29.1 | Identify the requirement for the planned time period between major overhaul | There shall be only one such identifier with the same 'Owner_of' for a requirement. | x | - | - |
| 29.2 | Identify the requirement version for the planned time period between major overhaul | There shall be only one such identifier with the same 'Owner_of' for a requirement version. | - | - | - |
| 29.3 | Identify the property and its value for the planned time period between major overhaul | Combine the value with its classifications as per Step #22 and #23 .There shall be only one such property for a Requirement_view_definition.The Requirement_view_definition.initial_context shall be classified according to #2.1 and #3.1 . | - | - | - |
| 30 | (not used, yet) | - | - | - | |
| 31 | Identify the customer account of an individual product | There shall be only one such identifier with the same 'Owner_of' for a requirement. | - | x | - |
| 32 | Identify the contractor that has built the individual product | There shall be only one organization with such a role assigned to a Product_as_individual. | - | - | - |
| 33 | Identify the home base organization of the individual product | There shall be only one organization with such a role assigned to a Product_as_realized. | x | - | - |
| 34 | Identify organization responsible for life cycle support | There shall be only one organization with such a role assigned to a Product_as_realized. | x | - | - |
| 35 | Provide additional information about the individual product | Shall be assigned to an appropriate Product_as_individual_view. | - | x | - |
| 36 | Relate individual product to its functional location | .relating_version relates to Step #36.2, and .related_version relates to Step #6. | - | - | - |
| 36.1 | Identify a functional location | Breakdown_element may be instantiated as Functional, Physical, System, or Zone_element.There shall be at least one Breakdown_element_version for this Breakdown_element.Use #20.2 | - | - | - |
| 36.2 | Identify version of functional location | Breakdown_element_version shall be instantiated as one of its subtypes and in accordance to the selected subtype in #36.1 .Use #20.2 . | - | - | x |
| 37 | Identify onboard installation date for individual product | Check for valid dates. Needs to be before delivery date.Shall be assigned to Step #36. | - | - | x |
| 38 | Identify manufacturing date for the individual product | Usual check for valid dates. Needs to be before delivery date.Shall be assigned to #6. | - | - | x |
| 39 | Assign the contractor purchase order document to the individual product | Link #39.2 to #4. | - | - | x |
| 39.1 | Identify the contractor purchase order document for the individual product | Use #1 with #20.2 . | - | - | - |
| 39.2 | Identify the version of the contractor purchase order document | Use #1. | - | - | - |
| 40 | Assign classification for special logistics reporting requirements to the individual product | An instance relates to an instance of Step #48. | - | - | x |
| 40.1 | Classify the representation of the text property as descriptive text | There will be no more than one class instance for one instance of the value_component. | - | - | - |
| 41 | Indicate that installation of individual product in parent product has been verified | An instance relates to an instance of Step #36.2. | x | - | x |
| 42 | Indicate which organization purchased an individual product where | Apply classification as in Steps #35.1 and #35.2 .Shall be assigned to an appropriate Product_as_individual_view. | - | - | x |
| 43 | Assign document to individual product | - | - | - | |
| 43.1 | Identify any document of any relevance for the individual product | - | - | - | |
| 43.2 | Identify the version of a document of any relevance for the individual product | - | - | - | |
| 44 | Define relation type between different individual products of the same type | Only one such classification to the same instance.Link two instances of #6.The older one of the two shall be the relating Product_as_realized. | - | x | - |
| 45 | Identify an individual, government furnished item by its government given code | Use #1 with #20.1 . | - | - | x |
| 46 | Add a dummy identifier to an individual product that only is identified by its breakdown element identifier | An instance of the class shall be associated to an instance of Step #4.1 when Steps #4.1 or 45 have no value. Identifiers to this entity apply in the order defined here. | - | - | x |
| 47 | Link breakdown element to the indivdual product that they describe a view of | .related_version relates to an instance of Step #36.2, and .relating_version realtes to an instance of Step #6 and 4.1. | - | - | x |
| 48 | Establish a view for a configuration item represented as breakdown item | .defined_version relates to an instance of Step #36.2. .initial_context relates to an instance of View_definition_context classified as in Step #2.1 and 3.1. | - | - | x |
Table 0 — Business functions present in different business DEXs
© OASIS 2010 — All rights reserved