Overview of experience gained with definition and support of

Overview of experience gained with
definition and support of extended Product
& System lifecycle scenarios using OSLC
Co authors: Gray Bachelor (IBM), Hiroaki Nakamura (IBM),
Arvind Rengarajan (IBM), Mike Loeffler (GM)
Speaker: Gray Bachelor
Solution Architect
IBM Rational HQ CTO Office
[email protected]
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Today’s topics
Motivation for additional resource behaviour needed for
collaboration along the product and service lifecycle
Work done
– Applying what is available
– Identifying gaps to fill
– Prototyping to build up specification proposals
Results
Looking ahead
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Acknowledgements and thanks to:
Michael Loefller
Systems Engineering IT Specialist
General Motors
Nakamura, Hiroaki 中村 宏明
Research Scientist
IBM Tokyo Research Laboratory
Arvind Rengarajan
Auto Industry Architect
IBM Global Business Solution Center
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Motivation
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Motivation
Companies rush on the opportunities for SMARTer products and services
But daily activities for all lifecycle participants becomes more interdependent and
complex
Most enterprises need to reduce the cost and time to achieve system quality, risk
and cost
Excess effort is needed to manually align, check and correct information
originating in product engineering: problems go undetected, improvement
opportunities are lost
Such problems cause product delays and quality problems resulting in poor
performance in the market
OASIS OSLC seeks to apply open web integration techniques to increase
collaboration along the lifecycle to address these root causes of poor information
access and use
Having focused initially in the software lifecycle, the OSLC community wanted to
identify capability needed for the product and system lifecycle……….
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Work done
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Our OSLC kitchen !
Define scenarios and select one
Assess use of existing OSLC specs and typical major applications (ALM and PLM)
Identify new needs
Gain inspiration from existing approaches
Draft Spec and resource shapes
Prototype using OSLC eclipse Rio/Lyo JDK
Propel into OSLC Spec making and convergence
– Core
– Configuration Management
– ALM-PLM Interoperability
Publicise for additional feedback and refinement
….
..
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Main scenario: Systems Engineer Reacts to Changed Requirements
Define
Product
CR
Impact
Analysis
Revise
Requirements
Define
System
Solution
Assign & communicate the change request (a1, a2, a3)
– Assign change request context
Submit change request
Locate change request from notification
Apply change request context to establish impacted requirements & implementation (a4, a5, a6)
– Locate requirements in change request context
Create new revision of requirements context and reserve for editing
Open new revision of context
Locate re-usable implementations to meet changed requirements (a7)
– Located reusable implementation to satisfy change ?
Then a choice of either update solution by way of adaption of re-usable implementations (a8, a9,
a10, a13, a14, a15)
– Add selected implementation to change request as solution
Merge selected implementation into context
Trace to discipline responsibility
Analyse detailed requirements & existing implementation
Design minor updates to existing implementation
Design by sub-team needed ?
or design solution by original design (a10, a11, a12, a15)
– Trace to discipline responsibility
Design new implementation
Add new design to change request solution
Design by sub-team needed ?
Close CR
&
Release
Approve change request solution (a16, a17)
– Passed review of implementation for change request closure?
Close change request
http://open-services.net/bin/view/Main/PlmSystemsEngineeringScenarioSystemsEngineerReactstoChangedRequirements
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Our scenario focuses on the ability to make associations between
the 4 key artefacts and control them during change
Change Request
System or
product context
Requirements
Implementation
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Analysis by way of usage of existing OSLC 2.0 Specs
Summary of OSLC CM, RM, AM and QM resource types
and relationship properties
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
We analysed the application of the existing OSLC resources
within the scenario
CM Spec 2.0
ChangeRequest
Change Request
State 1
Existing
released
product
definition
CM
Problem item, Makefrom or impacts
released product config (context)
System or
product context
Implementation
Requirements
AM
RM
RM Spec 2.0
Requirement
State 2
New
product
definition
Requirements
AM Spec 2.0
Resource
Solution item: New released product
config (context)
System or
product context
Implementation
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Key needs from the scenario
A means of identifying a concept / artefact as a product
A means of identifying a revision / version of products and other artefacts
A means of representing structure of products and other artefacts
A means of associating product context with products and other artefacts
A means of traversing links find related artefacts
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Inspiration for product resource behaviour
Origin
“Style and Protocols”
“Product & System representation”
OSLC
Linked data, RDF, RESTful services,
Indirectly through properties on
existing Resource
HTTP - GET, PUT, POST
OMG PLM Services 2.0
AP214 EXPRESS schema
Product ID, meta-data, structure
WSDL
OASIS PLCS
AP239 Express schema
Public services not defined
OASIS AP233
AP233 Express schema
Product ID, structure, work
breakdown, reqmnts
System ID, structure, reqmnts
Public Services not defined
OMG SysML
XMI
Indirectly
Public Services not defined
AP233 mapping potential
MARTE has indirect references
PLM applications e.g. Focal Point,
TeamCenter, Enovia etc
Proprietary WSDL
AutoSAR
Not assessed to any significant
degree during the workings
EAST-ADL
Not assessed to any significant
degree during the workings
Other e.g. SOA initiatives
Home grown WSDL “Any XML”
ESB Restful consumer and provider
Own product or system lifecycle
services
PLM Services, vendor, home-grown,
SOMA based
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Summary of the product resource behaviour needs within
the scenario
Resource behaviour
The resource shall
provide relevant
behaviour to support
the product and/or
system lifecycle
Identity1
Variation
management2
Event handling3
The resource shall
provide coding and
classification
identity
The resource shall
support parametric
configuration
Responding to
events e.g.
changes, approvals
Version
Effectivity
Compositional
relationships
The resource shall
support
identification of
versions
The resource shall
support version
effectivity
The resource shall
provide composition
by viewpoint
Note 1: Basic identity only is currently included in the scenario
Note 2: Basic version handling is currently within the workgroup focus, additional material is being developed for richer support for variations
Note 3: The current scenario does not address the detail of event handling e.g. definition of events, subscription filters and notification
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Examples of Lyo extensions prototyping environment
OSLC Façade on enterprise application
– General Motors Electrical Systems Process Methods & Tools org
IBM’s PoC setup
IBM network
– IBM Research
Server 2
Lyo based prototyping
Repos
– IBM Research and GBS/Rational
GM’s
Linux
Tomcat
Lyo CM+PLM ext
Server
CM + PLM
provider
eclipse
Client
Lyo Web
Client
CM + PLM
consumer
CM+PL
MCM+PL
ext
M ext
CM + PLM
consumer
CM+PL
CM+PL
Me
xt
M e xt
CM + PLM
provider
RTC API or OSLC extension
WAS 7 bundle
eclipse
RTC Rich
Client
RTC Server
Linux
RTC Web
Client
DB2 Bundle
Server 1
Firewall
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Sample use cases to validate the basic support provided
by the OSLC ALM-PLM Interoperability extensions
prototyping
CR
AffectsPlanItem
System or
product context
Requirements
Satisfies
Implementation
1
An OSLC CM resource can
be associated with an OSLC
Product Resource
2
An OSLC Resource can be
used to locate an OSLC RM
or AM resource, typically via
it’s versions and views
3
A SPARQL query can show
linkage across multiple
resources
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Results
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
How we used the OMG SUV model
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
“Pre-condition” for OSLC scenario
After Act 2 in CM scenario
HSUV 2016
Title
ShortTitle as Product name
Product
isVersionOf
Title
Product
Version
hasView
AMG54556
HSUV2016
ShortTitle as Version name
01
HSUV2016
Title
Product
View
AMG54556 – Product View
ShortTitle as View name
hasPart
Product B version
hasPart
Product C view
hasPart
AM Resource X version Y
hasPart
AM Resource W view V
hasPart
SCM directory Version U
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Draft specification – Product definition V1.1
http://open-services.net/bin/view/Main/PlmSpecExtensions
Resource type Name: Product
The Product resource is used to define products.
The Product resource properties are not limited to the ones defined in the 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.
Type URI http://open-services.net/ns/oslcdomainname#Product
Common properties
– dcterms:isVersionOf
A predicate related resource of which the described resource is a version, edition,
or adaptation
– dcterms:replaces
A related resource that is supplanted, displaced, or superseded by the described
resource
– oslc_pd:hasView
A related resource which is a view (e.g. structure) of the Product, of type Product (or
other resource
– oslc_pd:hasPart
A related resource which is a compositional element, component part, (of the
Product or other resource
Additional recommendations on the usage of existing OSLC properties
– dcterms: shortTitle Product name or number
– dcterms: Title Product name
– dcterms: Description Product Description
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
PoC Linktype properties to support traversal queries
CR
CM >
> PM
affectsPl
anItem
Is Based
upon
RM >
> CM
implemen
ted-by
CM >
> RM
trackReq
CM >
> RM
Impleme
ntsRequir
ement
Controlled
config
RM >
> PD
System or
product context
implemen
ted-by
PD >
> CM
implemen
ted-by
CM >
> RM
trackReq
archoitect
edBy
Implementation
Requirements
RM >
> AM
RM >
> AM
isSatisfie
dBy
AM >
> RM
Satisy
depende
ncy
CM >
> AM
trackCha
ngeSet
IBM PoC
GM PoC
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Examples from ALM-PLM integration – Product Resource
view
Product resource associated
with ChangeRequest
Product Selector (Delegated
UI)
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
GM PoC example
Teamcenter EC accessed
through OSLC CM
specification based web
service
Teamcenter Requirement
documents accessed through
OSLC RM specification based
web services
Change Request associated
with requirements using
OSLC CM and RM properties
– Tracks Requirement
– Implements Requirement
– Affects Requirement
Artefact versioning
Carry PLMXML in OSLC
wrapper via namespace
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
OSLC provides support for tool interoperability and is being applied
for ALM-PLM workflows and collaboration support
Project
CM
CM
Activities
PD1
Configurations
TRS
RM
CfgM2
AM
QM
Fulfilment
of Requirements
Test
Note 1: Product definition spec if draft
Note 2: Configuration Management spec is in formulation
24
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
The future …………
If we succeed such traceability views will be possible widely across the enterprise an
supply chain
Video
2nd European Conference on Interoperability for Embedded Systems Development Environments
Video
Stockholm Dec 2013
Conclusions
A product resource is a useful extension to the small family of OSLC resources to
enable different resource types to be associated in different ways
Resource versioning is vital for handling the resource revisions within the
scenario
A means is define structure is needed we propose a view resource and link type
Recent analysis has shown that the ability to have a place holder in a structure
could be useful too
Examples of variant expression have been shown but more work is needed
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
Invitation for next steps ….
Renew the scenarios and needs discussion with additional interested groups
– OMG MBSE WG underway
– EC Artemis projects underway
– OASIS plcs ?
– Other ?
Converge the Spec proposals within the OSLC 3.0 timeline
Within Configuration Management WG
– clarify Resource types > Version, View, Part
– Clarify Properties > isVersionOf, replaces
Within ALM-PLM Interoperability WG
– clarify Resource types > Product, View, Part
– clarify Properties> hasView
Roadmap for variant handling
Investigate the efficacy of aligning model structure to product and requirements using the
proposals (OMG MBSE WG is active here)
??
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013
2nd European Conference on Interoperability for Embedded Systems Development Environments
Stockholm Dec 2013