Page 1

RFI on PLM and MBSE

interoperability and integrationMichael Pfenning, XPLM

Uwe Kaufmann, ModelAlchemy Consulting

Christian Muggeo, Technical University Kaiserslautern

December 10th 2015, La Jolla, CA

© XPLM

Page 2

› Description of the problem

› Thoughts about Functions in SysML

› Questions for the RFI

› RFI Roadmap

Summary

© XPLM

Page 3© XPLM

Changing Engineering Tools

DRAWING BOARD

2D CAD

3D CAD

MBSE

PDM/PLM

?

Page 4© XPLM

Models along the V

Extended V-Model (derived from (VPE) of TU Kaiserslautern)

Software

E/E

Mechanics

Modeling and Analysis

Service

System Lifecycle

Verification and Validation

IdeasRequirements

DefintionProductPlanning

DevelopmentProcessPlanning

Production Operation Recycling

Modeling and Specification

Modeling and first steps of Simulation

Discipline-specificModeling and Simulation

Hybrid Tests / Visualization

Physical Tests / Prototyping

Page 5© XPLM

PLM as it is

PLM System

Product Model Process Model

Work Order History Validation by Users

Change Specialist I

Technical Review

By CRB

By CREATOR

Document Upgrade by Creators

CIB

Work Copies

Change Specialist II

ECRs Reports

Hig

h Ri

sk

Low

Ri

sk Bus iness Decision

ECN

Change Specialist III

Repository of Released

Information

WA

Physical Items

Results

Must Conform

Item

ItemItem Item

Item Item

Item

Item ItemItem

Doc

Doc Doc

Doc Doc

Source: CM-II change standard

Page 6© XPLM

PLM as it is

› PLM evolved from PDM (and therefor the mechanical domain)

› PLM started to include E/E and Software to some extent. At least results are

stored for configuration control.

› PLM for an engineer is the database where he puts his work results in, but for

the CTO it is the log of what happend in the development

› Therefor PLM is essential for documenting decisions (product liability!)

Page 7© XPLM

PLM as it is

› PLM consists of product model

› Models from authoring systems are mainly treated as documents

› Item structure (BoM) is setting up a „physical structure of the system“

› The item is referencing the models necessary to define itself.

› Properties of e.g. CAD models can be part of the PLM datamodel and

synchronized with the properties in CAD (so called property update)

› PLM is more than just document management, but not (yet) capable of (high

granular) model management

› „mechatronics BoM“ can be referencing ECAD, EDA, MCAD models.

› PLM consists of process model

› Most important process is the change process

› There have been change processes defined, for example in CM-II

Page 8© XPLM

PLM as it wanted to be

Source: Prof.Martin Eigner (VPE)

Page 9© XPLM

PLM as it wanted to be

› Some PLM-systems introduced REQM-modules

› PLM had non-physical structures in it, but they haven‘t really been used so much

› Functional BOM / functional breakdown on a discipline-neutral level

› Generic product structure for certain domains („auto BoM“ in automotive)

› The aim has been to set up vertical and horicontal traceability (V-model)

› Vertical: Req -> functions -> generic product structure -> BoM

› Horicontal: Req -> test cases / verification methods

Page 11© XPLM

Integrated/Total System Model

V2

V2 V1

V2 V2

V1 V3

V2

V2

BOM

The futureThe past

Page 12© XPLM

System Model as the glue over the lifecycle

Source: Sanford Friedenthaltime

Page 13© XPLM

SysML/PLM – Integration / 3 possibilities

SysML PLM

SysML PLM

Check IN

Check OUT

Check IN

Check OUT

SysML PLM

Check IN

Check OUT

› Save to PLM as a document

› No representation of any artifact from SysML in the PLM

datamodel

› Save to PLM as the whole model

› Full representation of all artifacts from SysML in the PLM

datamodel

› All Model Management is done within PLM

› Save to PLM only the necessary artifacts

› Only the necessary artifacts for the usage in PLM as

objects

› High granularity of Model Management is done in ALM

Contradicting a model-based approach

Page 14

Model Configuration Items

© XPLM

administrative view on the

system model

Model Configuration Items

* The concept of MCIs has been introduced in the Model

Lifecycle Management paper by the Model Management

working group at INCOSE

* › MCI is a logical part of the model

that is maintained in a controlled

fashion […]. MCIs can be defined

in different granularities, from an

individual fine grained Model

Element, a set of model elements,

to the entire model.

Page 15

Architecture Choice 1: Direct Integration (no ALM/MLM)

© XPLM

PLM

REQM SysML Simulink ECAD MCAD

Model Management

Page 16

Architecture Choice 2 : Federated Integration (1 layer)

© XPLM

PLMALM

REQM SysML Simulink ECAD MCAD

Model Management

Page 17

Architecture Choice 2 : Federated Integration (1 layer)

© XPLM

i.e. SysML

ALM

PLM

Page 18

Architecture Choice 3 : Federated Integration (2 layers)

© XPLM

PLM

ALM

REQM SysML Simulink ECAD MCAD

Model Management

Model

Management

Page 19

Architecture Choice 2 : Federated Integration (1 layer)

© XPLM

i.e. SysML

ALM

PLM

Page 20

Questions for RFI

© XPLM

Page 21

1. What artefacts in MBSE and PLM have the same meaning?

2. Which information in the system model can be used in other models (MCAD,

ECAD, Analysis…)?

3. What information from other models (MCAD, ECAD, Analysis,…) can be used

in the system model?

4. What issues occur when trying to set up multidisciplinary engineering

processes?

5. How does a MBSE change process look like today?

6. What is needed to better support reuse of (partial) system models?

7. What is needed to better support collaboration inside SE and between SE and

other disciplines?

8. What benefit is provided when using the system model over the whole lifecycle?

Questions for RFI

© XPLM

Page 22

9. Can the system model provide context information for operating the instance of a system (as-

built) (digital twin…)?

10.What is the meta data associated with an MCI?

11.How important is a system model as a single point of reference over the whole lifecycle of a

product?

12.Is there a need to freeze certain baselines of the system model at certain stages of the

engineering process? If yes, which concepts need baselining?

13.Which constructs of the system model need versioning on which level of granularity?

14.What is the benefit of managing models as objects instead of managing the system models

textual representation (XML snippets)?

15.What specific use cases do you have for the MBSE / PLM Integration?

16.How do your needs of formal change control evolve over the system‘s lifecycle (early program

control vs. Design/engineering vs. Production vs. Operation/Maintenance vs. Disposal)?

17.The RFI should contain questions about the respondend. (role, industry, vendor/user)

18.Definitions, definitions, definitions…

Questions for RFI

© XPLM

Page 23

› Next draft to be sent to ManTIS/Roadmap beginning of January

› 90% of RFI should be ready for Reston meeting

› Issue the RFI at June Meeting (Orlando)

› Response until October

› Survey (Online questionaire ?)

RFI Roadmap

© XPLM

Page 24

Thank you

© XPLM