-- GrayBachelor - 05 Jan 2012

OSLC v1.1 Spec Extensions for PLM - Product Definition - aka "PD Spec V1.1"- Draft for discussion

Document Status: Working draft, used for discussionand prototyping. Note that feedback applicable to the Core extensions for PLM and included in the new V1.1 are to be included here, during April 2012.

Introduction

Need for a Product resource within the target scenario

The target PLM scenario A systems engineer responds to a change in requirements shows the need within both the PLM and ALM domains for stakeholders to identify a product and it's relevant requirements and implementation as means of securing their contribution. Within the scenario this is to identify the product which the change request is based upon, or "made from", and to identify the modified or new product, or product version, resulting from the change.

Product is a fundamental business entity within almost every commercial organisation, in some, System is also a primary concept, and may be logically equivalent to Product. Typically however System as a concept centres more on the capability and Product more on the commercial packaging or unit of delivery, System may exploit multiple Products as sub-system components and a Product may be a system, or contain multiple sub-systems. The focus here is on Product as a means of hosting a wide range of concerns.

Within the scenario stakeholders need to locate Change Requests, Requirements and Systems Implementation elements and artefacts from the Product perspective associate such elements and artefacts with the Product and its context. Product context being the relevant configuration, e.g. for the planned or actual phase of the lifecycle of concern or based upon criteria for effectivity or determinants for parameterised composition (i.e computed configuration).

The scenario begins with a product (or system) and associated requirenents and their associated, satisfying, implementations at some definied state; a change request is applied (i.e changes are made to relevant and impacted items) and their version identification are updated to signal completion of the change, with approvals. Version handling of the OSLC resource used in the scenario is needed, which is laid out in the Core extensions for PLM, namely CM, AM and RM resources plus the new proposed PM resource that supports Products, Product Versions and Product Views.

Fig1: Overview of the need for a Product resource to anchor the various concerns

An OSLC Product concept resource needs to support certain key common capabilities

1- Product identification to provide support for location and high-level or limited description of the product

name, description including alternative names* (i.e. psuedonyms)

product family coding and classification* including additional product type information

2- Variation handling to support changes to, or of, the product definition

Identification of versions and revisions, such as to denote that some change has been made

Composition by way of components, such as what a product consists of or is included in, from the various view points like Requirements, Documents, Models, Discipline views

Compositional configuration of viewpoints as versions or variants of a base product or system, such as a configured bill of materials or system breakdown

Effectivity handling, such as when particularly versions or variant become applicable, may be simply by date, manufacturing lot or tracked serial number

3 - Process support*

Event handling for subscriptions and notifications of changes to selectable (filtered) areas of interest baed upon process rules within the Product definition

Lifecyle process handling parameters used to provide business signals, such as availability, withdrawal, special handling needs

Ownership and approvals

(Items marked *Not currently addressed in the proposal)

Needed support for Product composition

Very typically Products are composed from or consist of collections, groupings or assemblies or other products and product components. The relationship can be formal such as a hierarchical decomposition with explicit functional information such as logical behaviour and interfaces or assembly information such as spatial position and orientation, or it can be looser based upon the mix of product sold or shipped together such as accessories. In these examples different compositional viewpoints are needed as the functional view is often composed different from the physical view, both in terms of included element types (e.g. OSLC reosurces) and the semantics of their relationships (e.g. product parts structure).

In general Product composition is a set of relationships between Product resources, as products or components if such a distinction is made, and between Product resources and other related resources, such as Requirements or AM Resources or SCM baselines. More specifically its the relationships between the prevailing, configured, versions of a Product or these other resources is the most interesting as it enables the detailed composition to be tuned or resolved more specifically as needed.

Product composition during the lifecycle can be under, over or precisely stated depending upon the need. Over stated to support future configuration or selection, under stated to allow build up and add-on kits. Even in operation additional options maybe be available from within the running product configuration "as installed". Therefore specification of composition, to configure, a Product is a key need. Furthermore dealing with the configuration specification as a resource in it own right is a likely future OSLC need, but not addressed yet here.

The approach here focuses on the resources and relationships for products, product versions, product views and their application to typical product structures. To inform this apporach we look to the existing industry standards for inspiration and examples

ISO10303 STEP AP239 - for product definitions, change request definition, relationships between products and change requests, resource structures, versioning and relationships

ISO10303 STEP AP233 - for requirements and system definitions and relationships, resource structures, versioning and relationships

OMG SysML - for requirements and system definitions and relationships, resource structures, versioning and relationships

Note: Today these standards provide useful basis for specification of product, product version and product views but the subject of variant configuration is less well covered. Therefore the approach proposed is an initial way of using variant expressions.

The following diagrams outline the needed resource types and their relationships that support composition, applied here to a Product resource but applicable to other OSLC resources like AM Resources and Requirements especially.

Fig2: Overview of the construct to support Product, Product Version and Product View

As can be seen from Fig 2 the construct is recursive to allow deep and tall relationships between products as components in other products and so treat products and their components consistently. This latter point beng of great value in making changes to products, in terms of organisational responsibility, such as make and buy decisions, or the ability to expose internal structure for collating quality or service information.

Using this construct it is then possible to assemble specific product compositional structures, for instance in the OSLC PLM Reference Modelshowing here a top level product, version and view with sample components, linked using the hasPart linktype.

Fig3: Sample application of the three level construct to support Product, Product Version and Product View within the HSUV model (OSLC PLM Reference Model)

Current approaches to defining products with OSLC 2.0 Specs

Clearly its possible to represent a Product or System using existing OSLC resources and properties. For instance at some stage of the lifecycle the Requirements may be the main representation or a product, in another sense the Implementation, repeesented by AM Resources, can represent the system model or an SCM Baseline resource could represent an ALM product release. Furthermore in some organisations the authorised Change Request to realise a new product is the reference for the product definition. It would be possible to adopt existing RDF/XML terms from existing product definition standards to build out such use of existing resource definitions.

Therefore the existing OSLC Specs have some potential to provide support for Product resources, however what this Product Management PM OSLC Spec aims to do is to provide a common and consistent resource definition for Product resource behaviour, clarifying certain resource capabilities. The aim is that such a PM Spec could be adopted by existing OSLC Spec service providers or consumers.

Summary of the Product resource concepts supported in the Product Definition (PD) Spec v1.1

Based upon the above needs the following concepts are included in this initial PD Spec v1.1 draft

1. Identification of a resource as a Product by way of a specific resource type, Product

2. Basic identification of a Product resource by recommended use of existing OSLC Core Spec properties

3. Adoption and application of versioning support as per the Core Extensions for PLM

4. Support for structural composition by way of Product views and related LinkTypes?

5. Initial support for conditional variation support through Variant expressions

Application of relationships with other OSLC Resources to fulfill the scenario

To meet the needs of the scenario the Product related resources need to support links with outher OSLC resources as outlined in Fig 1 above.

The specific relationships recommended and needed are

PM Resource Definition

Property value types that are not defined in the following sections, are defined in OSLC Core - Defining OSLC Properties

Resource Product

The Product resource is used to define products.

The Product resource properties are not limited to the ones defined in this specification, service providers may provide additional properties. It is recommended that any additional properties exist in their own unique namespace and not use the namespaces defined in these specifications.

Name: Product

• Type URI http://open-services.net/ns/oslcdomainname#Product

Prefixed Name	Occurs	Read-only	Value-type	Represen-tation	Range	Description
OSLC Core: Common Properties
dcterms: shortTitle	zero-or-one	unspecified	XMLLiteral	n/a	n/a	Short name identifying a resource, often used as an abbreviated identifier for presentation to end-users. SHOULD include only content that is valid inside an XHTML <span> element. OSLC PM Spec recommended use as Product number., Product version name or product view name.
dcterms: Title	exactly-one	unspecified	XMLLiteral	n/a	n/a	Title (reference: Dublin Core) or often a single line summary of the resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <div> element. OSLC PM Spec recommended use as Product name
dcterms: Description	zero-or-one	unspecified	XMLLiteral	n/a	n/a	Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <div> element. OSLC PM Spec recommended use as Product Description
dcterms:identifier	exactly-one	True	String	n/a	n/a	A unique identifier for a resource. Assigned by the service provider when a resource is created. Not intended for end-user display.
dcterms:isVersionOf	zero-or-one	yes	Either Resource or local resource	Either Reference or Inline	resource of same type	A related resource of which the described resource is a version, edition, or adaptation. OSLC usage requires the target resource MUST be a resource of the same type as the owning resource.
dcterms:replaces	zero-or-many	unspecified	Either Resource or local resource	Either Reference or Inline	resource of the same type	A related resource that is supplanted, displaced, or superseded by the described resource. OSLC usage requires the target resource MUST be a resource of the same type as the owning resource.
OSLC PM Spec: Common Properties
rdf:type	one -or-many	unspecified	Resource	Reference	n/a	The resource type URIs. One of at least has the value of http://open-services.net/ns/oslcdomainname# Product.
rdf:type	one -or-many	unspecified	Resource	Reference	n/a	The resource type URIs. One of at least has the value of http://open-services.net/ns/oslcdomainname# ProductVersion?
rdf:type	one -or-many	unspecified	Resource	Reference	n/a	The resource type URIs. One of at least has the value of http://open-services.net/ns/oslcdomainname# ProductView?
oslc_pm:hasView	zero-or-many	unspecified	Resource	Reference	any	A related resource which is a view of the Product, of type ProductView?
oslc_pm:hasPart	zero-or-many	unspecified	Resource	Reference	any	A related resource which is a compositional element, component part, of the Product. Examples are ProductVersion? , ProductView? or AM Resource Version or AM Resource View

Creation of a Product Resource

Creation of a Product Resource

Appendix A - Sample OSLC Product, Product Version and Product View Resources

Sample resource definitions are included here from the OSLC PLM Reference Model

Resource type	OSLC Ref model example	Scenario version	Usage example	Relationships	Example
PM	AMG54556 HSUV Product	Base	Base PM Product Resource		HSUV Product example from the OSLC PLM Reference Model
PM	AMG54556 HSUV Product Version	Version	PM Product Version Resource	isVersionOf	HSUV Product Version example from the OSLC PLM Reference Model
PM	AMG54556 HSUV Product View	View	PM Product View Resource	hasView hasPart	HSUV Product View example from the OSLC PLM Reference Model