OSLC ALM-PLM interoperability Discussion

OSLC PLM extensions Product Product, Version isVersionOf AMG54556_002 Product, View hasView AMG54556/001-View Resource, View hasPart Requirement, View hasPart AMG60112/001-View CR affectsPlanItem affectedByPlanItem Product, View hasPart AMG12345/001-View

SUV example (1) – Create an SuV Configuration Un released product (s) New and existing engine (ranges) New and existing engine control units (ECUs) New and existing ECU Software Product configuration “as designed” What are the steps ? What are the needed resources ? How “mark” existing resources ? What new resources needed ? How are variants defined ?

The basic precursor to the main scenario focuses on the ability to make associations between the 3 key OSLC entities Requirements Implementation System or product context RM Spec 2.0 Requirement RM AM Spec 2.0 Resource PD Spec draft Product PM AM New unreleased product definition Requirements Implementation Variant A Variant B Variant params SCM Spec 2.0 Baseline AM

In our product sandbox Create initial product identity –(Postpone getting the formal identity from the master register Add initial classification –Product families, types, organisational ownership –Add from Catalogs of existing terms may inherit the requirement traceability Add preliminary lifecycle codes (state indicator) e.g. preliminary, not for sale Add business rules for state changes –Workflow is assigned –Or Manually controlled Typically already under version control Pause button: Resource type = Product, Version, number of properties

In our product sandbox (2) Define options and combinational/evaluated rules –From a catalog –From a requirement –From selecting a compositional “thing” –Valid combinations Pause: Added variant parameters and variant expression Issue: shown examples but not proposed vocabularies

Discussion 1.Identification of coding and classification –Membership of Families, ownership, functionality …? –Includes variant parameters ? –Pedigree or provenance e.g. supercedes or replaces … 2.Need for type =version and property isVersionOf 3.Role of a base resource + variant parameters vs “direct” access of a version resource ? –Both needed ? 4.What about combinations of variant parameters to be assigned to multiple “designs” as variant configuration “Specs”? 5.Definition of structure (and containment) ? –Views as specific resource type vs hasPart or isViewOf property –View identifier for multiple domains –Versioning of views –Structure via linkage to views or base or versions with view specifiers –Linktypes for product relationships

SUV example (2) – “Make from” (Make Configuration B from Configuration A by way of a Change Note) Existing product(s) Related product Existing engine (ranges)New low emission engine (ranges) Existing engine control units (ECUs)Engine control unit (ECUs) updates Existing ECU Software ECU Software updates Product configuration “as designed” Related product configuration “as designed”

Our scenario focuses on the ability to make associations between the 4 key OSLC entities and control them during change Change Request Requirements Implementation System or product context Requirements Implementation System or product context Problem item, Makefrom or impacts released product config (context) Solution item: New released product config (context) RM Spec 2.0 Requirement CM Spec 2.0 ChangeRequest CM RM AM Spec 2.0 Resource PM Spec draft Product PM AM State 1 State 2 Existing released product definition New product definition

Overview of the alignment to existing OSLC Specs Change Request Requirements Implementation System or product context The AM Spec is flexible enough to allow definition of many resource types and relationships but does not apply existing domain definitions A product resource could be created from the AM Spec, but OSLC lacks a separate product resource No direct relationship, the AM Spec AMLinkType could be applied isSatisfiedBy or tracksChangeSet RM Spec Requirement CM Spec ChangeRequest No direct relationship, existing example CM Spec affectsPlanItem Indirectly via trackChangeSets No overall product configuration with variation management. The draft SCM Spec supports baselines and versions. However neither CM, AM or RM Specs support versioning or variation handling directly CM RM AM