2. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
3. Company Overview
Shareholders
Over 24 years experience
with engineering interoperability, migration, intelligent documents,
benchmarking, more
Approximately 250 employees and consultants
based from international locations throughout Europe and in North
America
More than 500 Customers
that are leading companies across most industries
A vendor neutral / independent engineering services and software company since 1993
infocenter@prostep.com / 8-PROSTEP01
4.
5. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
6. The Integration Problem
• Point-to-point
solutions do not
scale
and typically
become
unmanageable
• Full
centralization…
is neither
feasible nor
desirable
• Data
Duplication?
works for few key
systems only!
Issues with
synchronization More limited ability to respond to change
Constrained by exhausted IT budget and lower productivity
Integrations consume more of the IT budget:
integration failures are the top 2 causes
of software project delays*
Point-to-point
Integrations
don’t scale
Monocultures
lock you in
Maintenance, management,
and change costs go up over time
Creating new
integrations is
unpredictable
Ongoing and unexpected
costs drain resources
Past choices
restrict present
action and
future vision
End-user productivity suffers:
Either stuck with the wrong tool,
stuck doing manual integration;
often stuck doing both
* Commissioned study conducted by
Forrester Consulting on behalf of IBM.
7. But Integration is the Solution!
Business Cases for Integration are Abundant
• Manual integration of data can be quantified by the operation of synchronization
» Speed that the data is available
» Time the manual process takes for the data to be synchronized
» Accuracy of the duplicated data and costs of failures (wrong production revision?)
• Elimination of software licenses for integrated systems
» Data is available in the primary system of that user and additional license not needed
» Duplicate functionality only needs to be utilized in one system
» Integration can enable migration and eliminate other system entirely
• Data Efficiency from modern practices
» Traceability in Systems Engineering
» Model Based Enterprise
» Digital Thread
• Consolidation, Quality, Training, Maintenance, Support and Knowledge
» Less utilization of different systems means less overhead
7
8. Neutral Formats can be Rigid
• STEP 10303 AP 214
• Need to pre-define all
semantics beforehand
• Standards group to review
specification and determine
formats for everybody
• No actual usage defined with
the standard (XML? SOAP?
Where is it?)
• ISO trends Informational Only
(Nothing computational)
• Good for externalized data
because everything is known
ahead of time
9. OSLC - Open collaboration, better
integration
• Open Services for Livecycle
Collaboration
• Open Standard, Open
Community
• Proposed by IBM et. al. in
2008
• Motivated by Rational Team
Concert (RTC)
• Data is stored at single
location and simply linked.
No replication!
• Emerging standard for Tool
integrations in ALM domain
• Loosely Coupled
• Semantic Web Linked Data
• Based on Architecture of
Web – HTTP, RDF
• Slim Data model
» Granular to one
attribute at a time
• Enhanced Data models
available for Change- and
Document Management
• Easy to define your own
data types
• RDF (Resource
Description Framework)
• JSON / XML for transfer
• REST Service for
requests
• OAuth for authorisation
• UI Integration
Identify
Scenarios
Iterate on working
drafts
Call it a
specification
Gain technical
consensus
http://open-services.net
“Just Enough” integration
10. OSLC Specification
OSLC Core Specification
http://open-services.net/bin/view/Main/OslcCoreSpecification
OSLC Change Mgt
Specification
OSLC Requirements Mgt
Specification
OSLC Domain X
Specification
Core: Standard rules and patterns for
using HTTP and RDF that all the domain
workgroups must adopt in their domain-
specific specifications
Current Version: 3.0 Draft status, 2.0
Final 2013
Domain: Defines integration scenarios for
a given lifecycle topic and specifies a
common vocabulary for the lifecycle
artifacts needed to support the scenarios.
Domain resources and services
Define Semantics (Machine
Understanding)
Resource types, properties, relationships
Does not add new protocols
How
What
12. Organizations
Create OSLC-enabled software, contribute to specifications or workgroups, complete members
agreement…
Accenture
Advanced Computational Research
Agosense
Airbus
Alcatel-Lucent
APG
Aras
Atego
Bank of America
BigLever
Black Duck
Boeing
BSD Group
CESAR
Cisco
Citigroup
ClearBlade
CloudOne
CM-Logic
CONTACT Software
Corso
Creative Intellect Consulting
dSPACE
Eclipse Foundation
Emphasys
Empulsys
Ericsson
fluid Operations
Fujitsu Limited
Galorath
General Dynamics C4 Systems
General Motors
IBM
Icaro Technologies
iFEST
Imperial College London
Institut TELECOM
Integrate Systems Engineering
InterCAX
IRIS
JP Morgan Chase
Koneksys
Kovair
KTH
Mentor Graphics
Method Park
MITRE
MobileSmith
ModelBus
Nanzan University
NASA Jet Propulsion Laboratory
National Institute of Standards and
Technology
National Instruments
NEC
Northrop Grumman
OFFIS
Oracle
Orb Data
Panel Sistemas
Perforce
Persistent Systems
Phunware
PointSource
Price Systems
PROSTEP AG
PTC
QSM
Ravenflow
Red Hat
SBE Vision
SCM Solution
Shell
Siemens
Sodius
Software AG
Sogeti
SourceGear
Sparx Systems
SPRINT
State Street
Stoneworks Software
Tasktop
Taxal
Thales
Tieto
TOPIC Embedded Systems
Universidad Politecnica de Madrid
Virtual Vehicle
Washington Metropolitan Area
Transit Authority
WebLayers
WSO2
13. OSLC’s Big Picture
Open Services for Lifecycle Collaboration
Lifecycle integration inspired by the web
LINKED DATA PLATFORM WORKING GROUP
The Resource
for OSLC
Implementers
Inspired by the web
Proven
Free to use and share
Open
Changing the industry
InnovativeOSLC:
Tests, Libraries, Samples, Examples,
Reference Implementations
Scenario-driven &
Solution-oriented
Generally applicable: specs available for many domains
covering ALM, DevOps, ISM, and PLM
Leading choice for
strategic integration
technology
14. OSLC’s Simple Solution
Automation
Monitoring
Increased traceability
Architecture of the Web
Linked Data
Increased reuse
Standard Interfaces
Better visibility
“Just Enough” integration
Decreased maintenance costs
OSLC is an open and scalable approach to lifecycle integration.
It simplifies key integration scenarios across heterogeneous tools
15. Data in different silos today...
Requirements Validation Tests Design Implementation
Tool A Tool B Tool D
R1
R2
T1
T2
D1
D2
I1
I2
Tool C
16. Can become enriched with details by OSLC
validates
satisfy
validates
satisfy
validates
validates
implements
implements
Requirements Validation Tests Design Implementation
Tool A Tool B Tool D
R1
R2
T1
T2
D1
D2
I1
I2
Tool C
Which requirements for
the UI are related to test
cases that failed on their
last run?
Does every requirement
have a test to validate it?
18. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
19. OSLC uses a URI-based vocabulary
•When there is a need to identify anything in OSLC,
use a URI (there are a few exceptions).
•Using URIs allows everything to be linked together. It
also allows common agreed-upon meaning for
relationships and for resource types
<http://...Test Case 1> <http://...validates> <http://...Requirement 1>
OSLC Core URI Naming Guidance:
http://open-services.net/wiki/core/OSLC-Core-URI-Naming-Guidance/
20. OSLC uses an RDF graph data model
Adapted from:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-data-model
The predicate provides the property or relationship
between the subject and object.
Subject Object
Predicate
Test Case 1 Requirement 1
Amanda Car
owns
validates
21. RDF triple (subject-predicate-object)
validated by
Triple
Requirement
28465 Improve
Remote Steering
Test Case
35645: Test
Steering
priority
High
Subject = Resource
= always a URI
Predicate =
Relationship or
property = Always a
URI
Object = Could be a
URI (which could refer
to a resource) or a
literal value (value to
work with and show
users)
23. OSLC allows different RDF formats
•The RDF model provides for describing RDF triples. There
are various supported formats. Some are specialized for
RDF (Turtle) and others are derived from existing formats
(XML, JSON). These formats can be exchanged between
different applications (tools).
•OSLC allows different types of format:
» RDF/XML
» Turtle
» JSON
OSLC Core Specification:
http://open-services.net/bin/view/Main/OslcCoreSpecification
25. Example Relationship Graph
Bob
High
Implemented
owner
priority
state
created on
November 24,
2015
Requirement 28465
Improve Remote Steering
Lunar Rover 3.1
release
September
20, 2016
release to
orbit date
owner
Iris
Janet
High
Executed
pass
owner
priority
state
result
created on
December
7, 2015
Test Case 35645: Test
Steering
release
validated by
Work Item
38759
implements
26. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
27. OSLC defines the following technical areas:
1. Discovery of
capabilities
5. Delegated UI for
Create and Select
2. HTTP C.R.U.D. for
resources
4. Querying for
resources
6. UI Previews for
Resource Links
3. Standard resource
representations
28. 1. Discovery of capabilities
example: IBM Rational Team
Concert
example: IBM Rational Team
Concert project area
example: Change Management
capability
example:
work item
(bug, defect,
enhancement
request)
29. 2. HTTP C.R.U.D
•OSLC allows manipulation of resources using
standard HTTP C.R.U.D
Create = POST
Request = GET
Update = PUT
Delete = DELETE
31. 4. Query
• Example: Find high severity bugs created after April fools day
http://example.com/bugs?oslc.where=
cm:severity="high" and dcterms:created>"2017-04-01"
• Query capability has base URI
• Clients form query URI and HTTP GET the results
• OSLC services MAY support OSLC Query Syntax
» http://open-
services.net/bin/view/Main/OSLCCoreSpecQuery
32. 2. iframe's src
set to delegated
UI's URL
1. Click to
launch
delegated UI
3. Selection
made
4. Click OK. Sends
message (link+label) to
parent window
A delegated UI renders the source application UI in the
target application. This example shows the
contributed/delegated Rational Team Concert Work Item
search dialog being rendered in an OSLC Quality
Management application.
5. Delegated UI
33. 6. UI Preview
▪Scenario supported: hover over link to get in context preview of
resource
▪Simple resource format defined and retrieved using HTTP content
negotiation
Hover over link
34. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
35. Selling Trains
More then two parties involved
Customer BOMBARDIER
Order a train
Operate the train
The authorization process reflects the legal
framework of the European Union (EU) it has to
be consulted for projects applying for
authorization within the EU, in Candidate
Countries, which already apply EU law, or other
countries that have committed to it. The process
describes all steps that have to be carried out by
BT to obtain an Authorization to Place vehicles in
Service (APS) valid in those countries.
Notified Body
Judge
Evidences
Create
Statement
of Compliancy
Authority
Deliver an
authorised train
36. Motivation for an Integrated Solution
Project specific
authorization
requirements
Regulations
Law
Standards
PBS
Item
Item
Item
Item
evidence
evidence
WBS
Task(a)
Task (b)
Task (n)
…Product
Requirement 1
…
…
Requirement n
Requirement 2
WHY
DOORS
What?
Teamcenter
Enterprise
Who & When
RTC
38. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
39. Background
• Automotive OEM product development process requires extensive simulation
and physical testing.
• Simulation used in design process and physical test used to validate the
product.
• Knowing how well simulation captured the physical test is useful for refining
current design and improve future simulations.
• Data driven CAE correlation metrics can help making decisions on replacing
physical tests by simulations.
• Proposal for a CAE Correlation Application that supports traceability to
individual tests and simulations to combine the data needed to compute the
correlation and present the results.
40. Problem Statement
Database(Oracle) containing the
Design Verification Plan organized
by Program, milestone,
requirement reference,
requirement assessment, virtual
test reference, physical test
reference, etc.
Design
Verification
Database
Test Data Stored in Hierarchical File
System on NAS Drives
Excel, PDF, Images, video, csv,
Some typeof naming convention on
folders or in test reports
Test Data
Test Data
Test Data Test Data
ManualTest / Simulation
Correlation Process
Simulation Applications
Structural
Flow
Thermal
User findscorrespondingtest and
simulation records, extracts files and
opens in simulation application to
obtain data forcorrelation
...
Contains artifacts for Simulation
Application and test reports.
Objects must be manually
attributed
Teamcenter for
Simulation
(TC4Sim)
Database(Oracle) containing the
catalog of requirements, and
verification methods (both test
methods and CAE methods)
Requirements
Repository
Huge volumes of data across diverse applications, multiple search tools, manual linkage of datasets …
41. Big Picture
Test Data Files
Test Data Files
Test Data Files
Teamcenter for
Simulation
(TC4SIM)
Simulation Application
Simulation Application
Test Meta-Data
OSLC Compliant
Datastore
Requirements
Repository
Simulation Application
Design and
Validation Plans
Simulation / Test
Correlation Application
Simulation/Test Correlation Application implemented using OSLC as the communication method for
integrating various data stores and the applications.
42. POC Scope
• Demonstrate OSLC standard based interface between a Correlation
application and Teamcenter SIM and SQL Database
• Develop a Correlation Web application (OSLC UI)
• Prove that certain objects from TC SIM and SQL can be meaningfully
exposed as OSLC resources
• Prove that file attachments from TCSIM and SQL can be downloaded
using OSLC links using basic authentication
• Connect systems that do not natively support OSLC with OpenPDM
43. OpenPDM OSLC Adapter
• The OpenPDM OSLC Adapter
enables OSLC access for none-OSLC systems
» Authentication against backend
» Query UI / Properties Display UI
» REST Resources and resource links
» Local Document Download from the
backend system via OpenPDM
» Query Service maps OSLC queries onto
backend
• Supports Change Management 2.0 + custom
attributes
• Support for other schema planned for Q2 2017
«PROSTEP»
OpenPDM
«Dassault Systèmes»
Enovia er
OSLC Client
OSLC
Native
«PTC»
Windchill«SIEMENS»
Teamcenter
OSLC CM
Teamcenter
ALM
48. Understanding Data Models,
Mapping, and Lookup
▪ OpenPDM enables mapping between various backend models and the chosen OSLC application model:
«PROSTEP»
OpenPDM
OSLC Client
«SIEMENS»
Teamcenter
«SIEMENS»
Teamcenter
Backend-specific
domain models, e.g.,
TC CAE structure
Common
OSLC Ontology/
Application Model
Internal, generic model of
business objects and relations
as well as mapping information,
structure transformation, etc.
Mapping Mapping
QueryQueryTC SOA-API
Capabilities
Internal, generic Query
Language
OSLC generic Query
Language
Specifically designed
Query Capabilities
and Lookup Services
QueryQuery
Advertised Query
Capabilities
49. OSLC Case Study (POC Results)
• OSLC Background
• Linked Data
• OSLC Features
• Case Study – Bombardier Transport
• POC Description – Automotive OEM
• POC Results / Best Practices
50. POC Findings - Best Practices
• Having a fully generic query language sounds good, but…
» needs non-automatic reverse-mapping to backend and is hard
when structure transformation is involved
» is limited by backend capabilities (API, pre-defined queries,
access rights)
» may put unwanted load on backend systems, if not used carefully
• use designed query capabilities where possible
• combine with Data Warehouse approach when
„unlimited“ generic search and analysis capabilities are
needed
51. Is OSLC always the right choice?
• Is there a real need for a common application model
and a neutral resource description?
» or could you work with the backend model directly?
» how many applications need to be integrated
(providers vs. consumers)?
» what lookup query and analysis capabilities are needed?
» Do you need to transform or merge data before publishing to
OSLC?
• Can you live with linked data or is it necessary to
duplicate data?
» this is a paradigm shift
» is there a need for synchronization?
• How does this fit-in with other strategies?
» Enterprise Architecture & ALM
» Master Data Management
» Business Intel/ Analytics
52. What do I have to do to make it work?
• Choose an existing or invent your own OSLC application model /
ontology
» tailor model to your needs, e.g., in the CAE domain
» involve more of your backend systems, as useful / needed
» launch new workgroup, develop use-cases, draft common requirements
• Choose business and/or research use cases to collect feedback from
key users
» in the business to learn about needs, practical applicability, expectations, and
acceptance
» in IT regarding technical complexity / elegance of the solution
▪ Evaluate OSLC-technology in more detail
» Investigate vendor support for OSLC for other tools in use
» Close gaps by using integration technologies like OpenPDM
» Iterate and develop more OSLC services!
• Formalize an OSLC vision
» Investigate pain points for integration, Domains to cover, Start with simple
scenario based use-cases
53. Finally (TLDR)
• OSLC is a light weight mechanism to integrate enterprise data
• It enables access to underlying system without exporting/ importing, i.e.,
duplicating data
• Caveat: there are only a few detailed published data models
• No published domain specification for CAE /Physical Test data
• OSLC makes loose integrations very simple
• Need adapters if backend natively doesn’t support OSLC
» Tools like OpenPDM OSLC-Adapter enables publishing existing data from all kinds of
systems as OSLC
• Focus on and High Potential for ALM-PLM integration
• Simplified development. No new tools/protocols needed
» HTTP, XML/JSON, RESTful WebServices
• Tools like OpenPDM also shines when it comes to data transformation and
filtering; could even merge data from more than one backend system before
publishing as OSLC resource