OSLC v1.0 Spec Extensions for PLM - Draft for discussion

Introduction

Need for a Product resource within the current 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, descriptionincluding alternative names (i.e. psuedonyms)

product family coding and classification*

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

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 codes used to provide business signals, such as vaialbility or withdrawal

Ownership and approvals

(Items marked *Not currently addressed in the proposal)

Current approaches 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 PM Spec v1.0

Based upon the above needs the following concepts are included in this initial PM Spec v1.0 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

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

Appendix A - Sample versioned OSLC Resources

Appendix B - Questions and Answers

Appendix C - Next steps