Presentation for NAFEMS Simulation Data Management Working Group, September 13, 2018

1. Enabling the digital thread using open
OSLC standards
Presentation for NAFEMS Simulation Data Management Working Group
Axel Reichwein, Koneksys
September 13, 2018
1

2. Axel Reichwein
● Developer of multiple data integration
solutions based on Open Services for
Lifecycle Collaboration (OSLC)
● Background in aerospace engineering
● Since PhD, focus on data integration
● Since Koneksys, focus on OSLC
● Previously involved in standardization
efforts related to SysML (Systems
Modeling Language)
● Presented OSLC at multiple conferences:
INCOSE, OMG, SAE International
Automotive, North American Modelica
Users Group, IBM InterConnect, IBM
Innovate, NoMagic World Conference,
CIMdata Systems Engineering Workshop
2

3. My simulation background
PhD and postdoc focused on tradeoff
studies
Reconfiguring architecture model to
then automatically sync detailed
discipline-specific models
Applying rule-based design in
engineering
3

4. Overview
● What is complicated in simulation data management?
● What is the digital thread and how can it help?
● OSLC value proposition
● Example OSLC solutions
● Summary: Universal Data Management is needed for the DIGITAL THREAD
4

5. Why is simulation data management complex?
Easy to collect simulation data and
simulation models
But how can simulation engineers
make sense of it, reuse it, query it?
Engineering is multidisciplinary and
involves cross-cutting concerns
Simulation
Mechanical
Project
Mngt
Software
Systems
Eng
5

6. Typical tough questions for simulation engineers
[change management/traceability] If we change the simulation model, which other
models need to be updated (cad, architecture)?
[understanding the context/transparency] Where is this parameter coming from?
Can I change it or is fixed? Why does it have this value?
[reuse] New projects have requirements in common with older projects. Which
simulation models of old projects can be reused in the new project?
6

7. Status Quo
7

8. Goal
Engineers should not waste time trying to find the right information
Engineers should be productive, by focusing their time on engineering, by easily
finding/sharing information and easily collaborating with other engineers.
Organisations should be able to access all the data to perform analytics and offer
new services for additional revenue
8

9. What is the digital thread?
Full
connectivity
9

10. 2 Trends increasing need for Digital Thread
IoT
New feedback loops needed to make
sense of recorded operational data
Autonomy
Explosion of number of test scenarios
Need to link experienced auton.
vehicle behavior (e.g. saved in data
lakes) with test scenarios (e.g. saved in
systems engineering applications) to
assess coverage of test scenarios and
overall vehicle safety
Design
Procurement
Manufacturing
Operation
10

11. Business impact
Less product development time
Less quality control and inspection time
Safer and better products
Additional revenue by offering after sales services
11

12. What does it mean to connect data?
Example: Requirement identifier <- link type -> Simulation parameter identifier
Connection is between IDENTIFIERS of data
Example: Power budget requirement will have identifier Req-PX-123456
Example: Power parameter in simulation model has identifier Par-PX-7890
Analogy: phone call between 2 persons identified by their phone number
12

13. Accessing data identifiers through APIs
Identifiers need to be retrieved from the Application Programming Interface (API)
of the data source
Different data sources have different APIs
Example: REST API, Web API, SQL, Java/Python library etc.
Analogy: Different APIs like different power outlets
13

14. Achieving the digital thread is currently impossible!
Full
connectivity
CAD Software Simulation
API1 API2 API3
Different APIs everywhere!
14

15. Different API = vendor lock-in
Your Data Your Software
Application Vendor
Proprietary APIs
and Data Formats
$ $
15

16. Once Upon a Time - Before the Web
Different protocols to access documents on the internet (Gopher, WAIS, etc...)
No connected documents (hierarchical document structure, no hyperlinks)
Not many persons used the internet
Hypertext existed since 1965, 25 years before the invention of the Web
Lack of standards for Hypertext hindered adoption of Hypertext - no compatibility
between different Hypertext systems
16

17. Lessons learned from the Web
Seeds for innovation: Open standards + open-source
Web not owned by a software vendor
Any document can connect to any other document
Improved knowledge sharing and collaboration
OSLC driven by similar values than World Wide Web
17

18. Key idea of OSLC #1: Standard API
18
Requirements Test cases Simulation
Standard OSLC
API to facilitate
data access
API1 API2 API3
OSLC
API
OSLC
API
OSLC
API

19. Key idea of OSLC #2: URLs as data identifiers
19
Requirements Test cases Simulation
URLs to identify
and connect data
at a global level
URLs serve 2
purposes:
● Identify data at
a global level
● Access data
using HTTP
API1 API2 API3
OSLC
API
OSLC
API
OSLC
API
http://../req1
http://../req2
http://../test1
http://../test2
http://../sim1
http://../sim2

20. Key idea of OSLC #3: Connect data
20
Requirements Test cases Simulation
API1 API2 API3
OSLC
API
OSLC
API
OSLC
API
http://../req1
http://../req2
http://../test1
http://../test2
http://../sim1
http://../sim2
Data can be
accessed as if it were
in the same
database/application
Data can be
identified using a
common scheme
Data can be easily
linked

21. OSLC-based applications decoupled from data
21
Requirements Test cases Simulation
API1 API2 API3
OSLC
API
OSLC
API
OSLC
API
Link
Management
“Google” Search Query Capability Reporting
Modular
architecture
Applications
are decoupled
from data

22. Organizations have full control over their data
22
Requirements Test cases Simulation
API1 API2 API3
OSLC
API
OSLC
API
OSLC
API
Link
Management
“Google” Search Query Capability Reporting
True data ownership
Organizations have the
freedom to choose
where their data resides
and which applications
can access it.

23. New applications can reuse old data
23
Requirements Test cases Simulation
API1 API2 API3
OSLC
API
OSLC
API
OSLC
API
Link
Management
“Google” Search Query Capability Reporting
Reusing existing data
Developers can create
new innovative apps or
improve current apps, all
while reusing existing data
that was created by other
apps

24. OSLC Adoption
By vendors mostly in ALM: IBM Jazz/CLM,
Mentor Graphics
By universities and consultants for MBSE,
simulation: https://github.com/ld4mbse +
https://github.com/oslc
Over 50 OSLC APIs developed for different
applications
New vendors creating OSLC solutions
General Motors in their MBSE
efforts and vision
https://koneksys.com/blog/present
ation-of-oslc-at-purdue-plm-meeti
ng-2018/
24

25. Discipline-specific vs. Universal Data Management
Currently, we have discipline-specific data management: Simulation Data
Management (SDM), Product Lifecycle Management (PLM), Application Lifecycle
Management (ALM) etc., and NO DIGITAL THREAD
Universal Data Management is needed for the DIGITAL THREAD
● Viewing data as a universal asset
● Viewing data as equal
● Viewing data with its context
● Viewing data as a whole
● Using open standards for creating standard APIs
● Creating applications on top of standard APIs
25

26. What now?
Request better APIs from vendors
Request OSLC APIs from vendors
Adopt OSLC in your new integration
projects
Perform POC projects with OSLC
Help build the OSLC community
26

27. 27

28. Importance of data access in a data-driven economy
Electricity played a big role in the Industrial Revolution.
Different devices can connect to electric power through a standard power outlet
Data is the new source of power
We need standard APIs to access data, just like we have standard power outlets to
access electric power
28

29. Thanks and get in touch!
axel.reichwein@koneksys.com