d3.4 definition and development of kbe- · pdf filed3.4 – definition and development of...

Copyright Manutelligence Consortium 2015-2018 Manutelligence N°636951

Horizon 2020

Acronym: Manutelligence

Project No: 636951

Call: H2020-FoF-2014

Topic: FoF-05- Innovative product-service design using manufacturing intelligence

Type of action: RIA

Duration: 01.02.2015 - 31.01.2018

D3.4 – Definition and Development of KBE-systems

Type Deliverable

Document ID: D3.4

Workpackage: 3

Leading partner: BIBA

Author(s): Patrick Klein

Dissemination level: Public

Status: Released

Date: 25.01.2017

Version: 1.0

Public

Copyright Manutelligence Consortium 2015-2018 / 34

Versioning and contribution history

Version Description Contributors

0.1 Initial draft and Structure BIBA

0.2 – 0.6 Draft in progress filled with content BIBA

0.7 Final draft before internal review BIBA

0.8 Draft including review comments and improvements SUPSI

0.9 Updated draft BIBA

1.0 Final version – to be submitted to EC BIBA

Reviewers

Name Affiliation

Donatella Corti SUPSI

Deliverable Peer Review Summary

ID Comments Addressed ()

Answered (A)

1

Some minor comments and typos,

two pictures (5 & 7) not visible for

reviewer (all notifications have been

placed in v0.8 of document)

All addressed in v1.0 ()

Public


Table of Contents

1 Introduction and scope of this deliverable ................................................................. 5

1.1 Research approach ........................................................................................................ 6

2 Introduction to Knowledge Based Engineering (KBE) .................................................. 7

2.1 Analysis of the 3DS embedded KBE approach provided by CATIA .................................... 9

3 SysML extension to define KbeML ........................................................................... 14

3.1 Enhancement to Product Service Life-Cycles ................................................................. 17

3.2 Adaption and Enhancement to Services/ Product configurators .................................... 19

4 Relation to LifeCycle modelling & LML ..................................................................... 20

4.1 Sample Case - Thermal insulation ................................................................................. 23

5 Enhancement of the Semantic Facilitator Domain ontology ..................................... 27

6 Interfaces to current knowledge bases .................................................................... 29

7 Summary and conclusions ....................................................................................... 32

8 References .............................................................................................................. 33

Public


Figures

Figure 1: Lead-time reduction of KBE solutions in industry (Vermeulen, 2007) ................................................... 7

Figure 2: The Knowledgeware workbench (of CATIA V5) embedding KBE capabilities into CAD .................... 9

Figure 3: Relation between UML, SysML and KbeML........................................................................................ 14

Figure 4: From UML to SysML to a KbeML extension ....................................................................................... 15

Figure 5: Graphical representation in Life-Cycle Modelling Language ............................................................... 20

Figure 6: Newton formula applied to Car ............................................................................................................. 22

Figure 7 Representation of the insulation in LML ................................................................................................ 23

Figure 8: Prefab wall with structural and non-structural sections (Lindbäcks) ..................................................... 24

Figure 9: Thermal insulation in conjunction with structural components ............................................................. 25

Figure 10: Prefab-Wall U_Value Calculation ....................................................................................................... 26

Figure 11: Enhancement of Semantic Facilitator Domain ontology with KbeML elements ................................ 28

Figure 12: Parameter mapping between KbeML model and commercial CAx application (shema) .................... 31

Tables

Table 1: Samples KBE using Knowledgeware workbench of CATIA (3DS component) .................................... 10

Table 2: KbeML Elements defined as an extension of SysML Metaclasses ......................................................... 15

Table 3: Addditional KbeML elements referent to information from the product usage phase ............................ 18

Table 4: KbeML Enhancement to Services/ Product configurators ...................................................................... 19

Table 5: Interdependecies between LML SysML & KbeML................................................................................ 21

Table 6: Relations between concepts of Domain ontology and concepts representing KbeML .......................... 28

Table 7: XMI-file of a KbeML model with highlighted element identifiers ......................................................... 30

Public


1 Introduction and scope of this deliverable

This deliverable summarizes all activities, which are performed in context of T3.4 of work

package WP3. In reference to description of activities (DoA – T3.4) of Manutelligence these

are outlined in the following:

1. Development and support of a “rule interchange format” in terms of standardized

representation of such codified knowledge. This way rules, algorithms etc. will become

applicable in different CAx-Systems.

As outlined in section 3 the modelling language KbeML, which has been specified by BIBA

and enhanced and refined in context of the Manutelligence research, approaches to become

a standard for the representation of codified engineering knowledge. The modelling

language, which has been defined as an extension of SysML/UML, is capable to represent

rules, algorithms etc. in visual diagrams, which can be stored as XMI files. This way, rules,

algorithms etc. are decoupled from proprietary frameworks (such as the KBE modules of

commercial CAD systems) and knowledge can be accessed easily.

2. Definition of interfaces to current knowledge bases in order to encode knowledge from such

repositories in the standardized format.

The incorporation into the established UML/SysML eco-system enables to parse captured

and codified information and this way to exchange the knowledge among different CAx

systems (section 6). In addition, the definition of KbeML elements as (additional) concepts

related to the facilitator domain ontology allows to create wrappers, which enable semantic

based data federation. Finally, libraries of “common” engineering knowledge “predefined”

as KbeML elements may become a knowledge base itself (section 6).

3. Development of the connection and semantic searches to enable retrieval of codified

engineering knowledge from the P-S engineering and manufacturing ubiquitous search

Tools.

As being described in more detail in section 5, semantic search approaches rely on a

semantic description usually defined in form of ontologies (or at least taxonomies) of the

corresponding domain. Accordingly, research activities have been conducted for the

definition of additional concepts related to the facilitator domain ontology, which represent

KbeML elements (as defined in section 3). Main relations and concepts are documented in

section 5.

In advance to these task-related objectives the deliverable provides a short rationale related to

Knowledge Based Engineering (section 2). In reference to an analysis of the 3DS platform from

Public


DASSAULT and its components (namely CATIA), current short-comings of commercial KBE

applications are indicated in order to discuss the KbeML approach in context of the

Manutelligence objectives. Further, the openness of KbeML in terms of compatibility and

extensibility to LML (and related activities as being described in D2.1 & D2.2), as well as the

capabilities to handle the Life-Cycle related information are described in section 4.

1.1 Research approach

The process, that has been adopted for T3.4 can be perceived as the continuation of research

activities conducted in predecessor projects: a combination of exploratory studies, literature

research to identify and enhance appropriate concepts and a validation on lab-level afterwards.

The last step will become part of the activities in context of the business demonstrators either.

After the definition and scope of the task objectives, the research group elaborated on the

underlying approach for the Rule Interchange Format aiming to provide a concept, which is

capable to represent/support the process for setting up KBE projects for Product Service

Systems. In this context the KbeML approach has been analysed and discussed. Since the

KbeML approach is grounded in the UML/SyML eco system, the specification itself can be

(and have been) formally extended. It turned out that some of the requirements of the envisaged

incorporation of Life-Cycle related aspects can be sufficiently addressed by KbeML, while

others can be addressed linking the models to the LML standard for management and

representation of lifecycle related knowledge. Thus, an analysis of the two modelling standards

and its relation to each other was conducted as part of the activities. In order to address the

semantic search related aspects (to enable retrieval of codified engineering knowledge), an

ontology has been set-up and this task has been accompanied with basic research upon the

capabilities of description logics (ontologies) in context of KBE.

While using ontologies and semantic web has been already explored in context of KBE (Curran

et al., 2010; Franke et al., 2011), the researchers identified advantages and disadvantages using

ontologies (section 5). These can be perceived as a kind of validation for the approach of using

KbeML and in addition the ontological representation of corresponding knowledge in an

ontology.

Public


2 Introduction to Knowledge Based Engineering

(KBE)

Knowledge Based Engineering can be defined as the process of gathering, managing, and using

engineering knowledge to automate the design process by usage of a so-called KBE system

(Kulon et al., 2006; Prasad, 2005). Typically, KBE-systems provide an interface to capture and

codify the knowledge in terms of logical rules, algorithms, or constraints, and in addition an

output module to trigger (control) adjacent CAx-functions (Milton, 2008). The codified

knowledge can be used for the automated creation of geometry, but may cover analysis tasks

in terms of validation or quality checking, such as compliance to required safety parameters, or

ISO standards. Further, a KBE solution can enable a broader variety of detailed design studies

of a given master-concept by usage of a rule-based approach for an automated detailing and

examination of design variants and in consequence extensively support the optimization of a

given (mechanical) design against defined constraints and requirements. KBE can be an enabler

for easy and fast examination of design variants, providing users and developers with different

kinds of virtual or physical mock-ups (e.g. La Rocca and Van Tooren, 2007).

KBE allows to reduce time and cost required for the development of products and systems,

thanks to captured and re-used product and process-related engineering knowledge as well as

to the possibility to (partially) automate the belonging repetitive design tasks (Skarka, 2007;

Verhagen et al., 2012). The enormous potential of KBE implementations in industrial context

has already been outlined in literature. As provided by (Stokes, 2001) timesaving – ranging

from several hours to several days – can be achieved by KBE solutions (Figure 1):

Figure 1: Lead-time reduction of KBE solutions in industry (Vermeulen, 2007)

Accordingly, the main outcome of a KBE project is the generation of automated design

applications, which are software modules, which support the designer in generating product

model configurations and adoptions automatically, through the execution of a set of rules and

Public


procedures, which are translated into source code. The outcomes of these applications are

typically new CAD files of products and parts, which inherit properties from an underlying

master product, if not designed from scratch by the IT-system.

In reference to the analysis of modelling frameworks, CAD systems, etc. existing KBE

approaches can be clustered into at least three main groups (Colombo et al., 2014):

- Geometry Based Approach (GBA): the product structure is represented by CAD tool,

whereas the design process is represented by scripts embedded in the CAD tree or

external tools (i.e. spreadsheets), or through internal formula expressions. Due to the

expansion of CAD capabilities in late ’90s, many software vendors included KBE

modules in their CAD/PDM portfolio. In the underlying software architecture,

algorithms, rules and equations, which drive the behaviour of the geometrical model,

are directly embedded into the objects trees. Eminent examples are CATIA (as detailed

in section 2.1) and SiemensNX (in particular its workbench Knowledge-Fusion)

provided by Siemens PLM (formerly Unigraphics).

- Pure Object Oriented programming approach (OOP): both product and process are

represented by objects, properties and methods; the geometry is generated at run time

during the execution of the code; thus, the geometry is not persistent. This group of KBE

solutions is represented by software, that enables users to create automated design

applications using pure object-oriented programming languages (e.g. Lisp), which are

processed with framework internal geometry engines. Known examples are the AML

(Adaptive Modelling Language) framework to represent domain knowledge in complex

products, whereas Genworks has proposed GDL (General-purpose Declarative

Language) for the same purpose.

- Combination of an Object Oriented programming language and a Process

manager module or tool (OPM): the product structure is represented by O-O structure,

but the geometry is generated using an external CAD tool; the design process is

represented by specific modules or tools (i.e. a process manager) that interact with the

O-O model. Amongst others, Rulestream ETO (Siemens PLM), RuleDesigner by

Engineering S.p.A., Tacton by the homonymous company, KBMax by Citius and

VariProd by Variantum Oy can be assigned to this group.

Public


2.1 Analysis of the 3DS embedded KBE approach provided

by CATIA

As outlined in more detail in the DoA one of the main pillars of the Manutelligence platform is

the 3DExperience platform, which is provided by DASSAULT systems. The platform itself

incorporates a comprehensive set of commercial solutions ranging from the CAD modelling

application CATIA & simulation (SIMULIA), to PLM (ENOVIA) & generic business modules,

such as the data-analysis module EXALEAD or the “marketing-related” module 3D EXCITE

(3DS Dassault, 2016). Within this comprehensive portfolio Knowledge Based Engineering and

design automation are not covered into a separate component but are provided under the

umbrella of the CAD module CATIA (Dassault, 2016). Accordingly, DASSAULT Systems

follows a Geometry Based Approach (GBA) by binding KBE features to the geometrical

models (Colombo et al., 2014). In the underlying software architecture, algorithms, rules and

equations, which drive the behaviour of the geometrical model, are directly embedded into the

objects trees of the CAD models. In particular, CATIA comprises a specific workbench called

Knowledgeware, which is related to KBE and consists of four different modules (Figure 2).

Figure 2: The Knowledgeware workbench (of CATIA V5) embedding KBE capabilities into CAD

The Knowledgeware approach allows the definition of the “parameter behaviour” for all

instances. The product structure is represented by the CAD tool, whereas the design process is

represented by scripts embedded directly in the CAD tree or external tools (i.e. spreadsheets),

or through internal formula expressions. The corresponding design information of specific parts

can be accessed directly by selecting the specific CAD part (or feature) in the CAD tree. Also,

the management of the geometry results can be done immediately, through the direct modelling

of the parts. The features can be rule-driven or manual (Colombo et al., 2014).

The embedded engineering knowledge can vary from “simple” deterministic equations, which

can be directly embedded into the model instead of parameter values (Table 1 – row 1), to more

complex rules, which can relate to all instances of a specific feature (or component) within a

model (Table 1 – Row 2). Global parameters can be defined and used as input to control the

rules and the geometrical “behaviour” of the model. Next to rules and equations the GBA

Public


approach of CATIA enables to create User-Defined Features (“Powercopies” in CATIA),

which can be perceived as a recorded design sequence, which can be recalled in an easy and

interactive way. Users can model the design modification on an instance first and save the

“design steps” afterwards to be transferred to new components: for example, a feather key

groove can be stored as a Powercopy to be used on different sections of a shaft.

In the following, some examples are provided in order to demonstrate the capabilities. (The

examples have been implemented in simple CAD models by BIBA to support the analysis of

KBE capabilities in reference to Manutelligence):

Table 1: Samples KBE using Knowledgeware workbench of CATIA (3DS component)

Decscription Screenshots

The sample (right side) is referring to CATIA core

functions. Instead of values, links to other

parameters can be inserted into the CAD model, In

addition simple equations can be placed using

other parameters and math. operators.

Since referred parameters can be defined by

equations as well, the model can become very

adaptive just using equations. But, at the same

time, handling becomes confusing, since

dependencies are hidden behind the product tree

and nesting of equations into each other tasks

place, if parameters (which are based on equations)

are used in other equations.

The sample (right side) is referring to the CATIA

Knowledge Advisor module. A Rule is directly

incorporated into a CAD model of a crank-shaft in

order to “control” the bearings, in concrete to

choose between ball bearings and tapered roller

bearings. The “IF-ELSE” notation refers to a

global parameter representing the force (as an

input). The rule is not just switching between the

components but in addition adapts the shape of the

crank-shaft by inserting a groove in order to enable

the correct placement of the self-locking ring. (In

case of the tapered roller bearing the groove

disappears, since it is fixed by a shoulder on the

shaft).

Public



Knowledge expert module. As indicated in the

dialog-box the module allows to create and

manage generic rules and checks. For this purpose,

a so-called Knowledge Expert Language provides

elements defining “generic” CAD objects, such as

Hole, Threaded, etc. The rules are operated on

these entities. In the sample all threads of a

component can be marked in green colour, to

distinguish them from simple holes. The rule can

be applied without being restricted to concrete

parameters, components or assemblies.


user-defined features, so-called Powercopies. A

crimp is placed on a free-form surface, which has

been designed in advance on a different surface.

The process can be perceived as an intelligent

copy: a copy of the design steps, which are needed

to create the geometry manipulation.

User-defined features (Powercopies) always

expect input geometry from end-users (in the given

sample, the selection of a sketch is requested,

which builds the basis for the upper case of the

crimp as well as the selection of the surface).

Since programming skills are reduced to minimum, the GBA based approach (in terms of

embedding KBE knowledge directly into the CAD model) provides its advantages mainly in its

intuitive access for engineers & the domain experts. As there is no necessity to transfer design

knowledge into software scripts or modules the users can directly start e.g. by binding an excel-

sheet with own calculations to dimensional parameters, or putting simple rules ensuring

rounded corners in a CAD model of a casting.

But the approach is inheriting several disadvantages and risks, especially (i) when the models

get more complex (in terms of embedded engineering), (ii) the development process is linked

to 3rd party applications, or (iii) the product is extended in sense of hardware & software

components or Product Service Systems (PSS).

Since the CAD models are stored in a proprietary format (in terms of CATIA *.’CATPart;

*.CATProduct are the native file-formats), rules and equations are encapsulated and cannot be

Public


accessed by other applications. Even if it would be possible to break up this encapsulation,

which is given by the proprietary structure of such files, an utilisation of the already

implemented design knowledge by other applications would fail, due to a lack of

standardization of items, such as Namespaces, Relations or Operators & Rules. CAD related

exchange formats, such as STEP or IGES are not able to handle KBE enriched models properly.

Challenges related to this encapsulation can be observed if companies switch from one CAD

vendor to another (e.g. migration from CATIA to NX (Siemens NX, 2016)).

The placement and shape of a button (of a User Interface) may serve as an example for the

problems occurring with encapsulation. While physical parameters such as shape & size can be

formalized in form of equations to geometrical parameters (in ref. to the capabilities mentioned

in Table 1), a design dependency between the size of a device and the physical or virtual

appearance of a button cannot be embedded into the CAD model. Of course, the absence of a

component can be controlled by an equation embedded in the CAD model, but the link to the

software user interface is missing (the software interface is not triggered accordingly).

A systematic transfer of usage information (such as sensor data or user feedback) into

mechanical design requires the setup of related analysis capabilities, such as filters on the one

hand and the identification of dependencies between usage-related parameters and design

parameters or component attributes on the other (not only in context of KBE, but in context of

design in general). Since the core approach behind PDM systems such as ENOVIA (the PDM

component of DASSAULT Systems 3DExperience Platform) is relying on database

technologies, they can be adapted to access and manage all kind of data and this way even data

related to the usage phase. Nevertheless, for a successful exploitation of usage related data a

structured analysis is even more important than an access to usage-related data. A mapping is

required between different product generations, which could mean that data & information may

be relevant to components, which are different from the ones where the information is acquired.

In addition, data on the instance level of a product has to be aggregated to the class level. To

illustrate these dependencies a sensor-enhanced engine may serve as a sample: the engine of

product-line X includes three temperature sensors (in the development phase each can treated

as a component by the PDM system). If hundred instances are produced and sold, the usage-

related data repository comprises about 100 data-sets for each of the three sensors (300 data-

sets in total). If these datasets are offered to support the development of product-line X+1, it

has to be defined somewhere:

- to what extent the data is reliable (e.g. broken sensor) and relevant (e.g. the engine has

been used in an environment, which is not applicable anymore).

Public


- how is the data-set can be transferred into an input parameter (e.g. maximum or

median)?

- to what extent the sensors will be (a) included into product-line X+1 again (b) have to

be adapted and (c) have to be enhanced by additional ones.

- in which way the data-sets are handled semantically (e.g. properties of the sensor-

components of product-line X or as properties of the 100 orders, etc.)

- which components are based on calculations or rules, which rely on one or more of the

three temperature parameters.

- how it can be tracked if the data-sets (or sub-sets) are used for/within a KBE enhanced

model.

In relation to the above mentioned short-comings, designers should be supported with a

systematic modelling approach, which enables to address the above mentioned points and can

be perceived as a complementary add-on to the existing capabilities, which are currently

provided by the 3DS platform (and comparable solutions of competitors):

- a standardized representation of codified engineering knowledge to make rules

algorithms applicable for different CAx Systems;

- a formal machine-readable representation of knowledge to enable interfaces to current

knowledge bases;

- the capability to represent product usage information and data in both ways (in terms of

sensors&sources belonging to a product-class and sensor&usage data belonging to

product instances);

- elements enabling to document the analysis methods, which are used to transfer usage

data is as input for the product-development phase;

- modelling capabilities, which reflect not only products, but can represent extended

products & PSS as well.

Against this background, the modelling language KbeML has been specified and enhanced,

which is introduced in the following section. The approach was initiated in the Predecessor EC

project LinkedDesign and has been developed further in context of the Manutelligence

objectives in order to become a new standard, which completes (and complements) the

capabilities of the commercial CAx and PLM application, such as 3Ds.

Public


3 SysML extension to define KbeML

One focus of the research activities in context of T3.4 is the “rule interchange format”, which

can be perceived as the idea of a standardized representation of equations, rules and algorithms

needed to codify engineering and development knowledge. This way, rules, algorithms etc.

shall be decoupled from proprietary frameworks (e.g. the DASSAULT Knowledgeware

workbench – analysed above) and can become applicable in different CAx applications. As

outlined in the following the approach for the modelling language KbeML has been enhanced

and refined in context of the Manutelligence.

The approach of KbeML is grounded on the established modelling languages UML and SysML,

which have been developed under the umbrella of the Object Management Group (OMG,

2016). To visualize the relationship between the UML and SysML languages and KbeML, a

Venn diagram is provided in Figure 3. The sets of language constructs that comprise UML,

SysML and KbeML are shown there as boxes marked “UML”, “SysML,” and “KbeML”

respectively. The intersection of the two boxes, shown by the region marked “UML reused by

SysML & KbeML” indicates the UML modelling constructs, that SysML reuses, called the

UML4SysML subset (ref to (OMG, 2012)). The region marked “Extensions to SysML (KbeML

Profile)” in Figure 3 indicates the new modelling constructs defined for KbeML that have no

counterparts in SysML or UML.

Figure 3: Relation between UML, SysML and KbeML

SysML reuses a subset of UML 2 and provides additional extensions to satisfy the requirements

of the language. SysML is defined as a formal extension of the OMG UML 2 Superstructure

specification. It is intended to be supported by two evolving interoperability standards including

the OMG XMI 2.1 model interchange standard for UML 2 modelling tools and the ISO 10303

STEP AP233 data interchange standard for systems engineering tools (ref to (OMG, 2012)).

Public


Figure 4: From UML to SysML to a KbeML extension

The extension to SysML has been realized by establishing so-called stereotypes. Stereotypes

are representing pre-defined information types (OMG, 2012). As outlined in Figure 4, the UML

2 meta-classes are connected to stereotypes with the extension connector (graphical

representation is a filled triangle). New stereotypes can be based upon existing ones via

generalization. This way all KbeML elements have been formally defined as outlined in Table

2. Along the development phase of KbeML the purpose and expressiveness have been enhanced

resulting in capabilities to represent design variants and to represent product usage information.

As illustrated in Table 4 for UIElements the extensions can refer to predefined KbeML elements

constraining its characteristics to the required needs.

In order to align KbeML with the specific objective of Manutelligence to support the design of

Product-Service-Systems, the amount of KbeML elements has been further enhanced (ref. to

section 3.2). However, as indicated in column 3 of Table 2 & Table 3 all element definitions

subordinate to the formal extension mechanism.

Table 2: KbeML Elements defined as an extension of SysML Metaclasses

Vizualization Description Formal Definition

CADModel provides a mechanism for representing a spatial model

as being typically defined by model files in CAD. A CADModel is

associated to the package element of SysML. In SysML/UML

packages partition the model elements into logical groupings that

minimize circular dependencies among them (OMG, 2012). A

CADModel may contain the elements CADComponents,

CADAssemblies, etc. and in addition a block diagram for visualising

the product structure by using those elements.

CADAssembly provides a mechanism for representing a product

assembly as typically defined by components in CAD. The

CADAssembly, which is defined as a stereotype of a block intends to

represent the structural perspective of a product geometry.

According to the proposed approach a CADAssembly can consist of

CADComponents and/or CADAssemblies.

Public


CADComponent provides a mechanism for representing a

component as being typically defined by its shape and geometry in

CAD. The CADComponent, which is defined as a stereotype of a

block intends to represent the structural perspective of a product

geometry. CADComponents can be represented in Block Definition

Diagrams, e.g. to visualize the structural dependency to

CADAssemblies or SysML blocks.

A CADParameter represents always a geometry related parameter,

which means that this type of parameter can be processed by a CAD

application. A CADParameter is instantiated by a CADComponent,

CADAssembly, CADEquation, or CADRule (always as stereotype of

property), but can also be used by other elements for non-CAD

related modelling or calculations. It is visualized as a property in a

component or as a box in a parametric diagram.

CADEquation provides a mechanism for representing dependencies

between CAD related parameters. A CADEquation, which is based

upon a constraint block can be used to specify a network of

constraints that represent mathematical expressions such as

{height=2*width}, which constrain the geometrical properties of a

CAD object.

CADRule provides a mechanism for representing more complex

dependencies between CAD related parameters such as geometrical

dependencies based upon conditions (e.g. height > 10). Formally, a

CADRule is a set of instructions, which conditionally executes a

group of statements depending on the values of some

CADParameters.

CADVariationPoint represents a decision point for alternative

components (CADVariants). The CADVariationPoint

“ClosureSystem” may allow to decide between two different

CADComponents (CADComponent “Door” and CADComponent

“Window”) by pointing to a CADVariant.

The underlying rules to choose between design variants, the list of

selectable CADComponents etc. are defined in the CADVariant

element. A CADVariationPoint is associated to the property element

of UML. A CADVariationPoint is instantiated by a CADAssembly.

Public


A CADVariant provides a mechanism for representing design

variants. A CADVariant is associated to a ConstraintBlock element

of SysML. Using the property CADVariationPoint CADAssemblies

can point to a CADVariant. For example, a CADAssembly

“Bookshelf” can point to a CADVariant “ClosureSystem” allowing

to choose between the components “Door” and “Window”.

A CADVariant contains specific properties to define the valid mutual

excluding components, rules to select, rules to define the no. of

components, etc. on runtime. This results in calculating at runtime

the final composition of assemblies, their relations (composition) and

their parameter values. The specific properties are defined in the

following sub-sections.

The property CADVariationRule provides a mechanism for

representing the rules to identify which components are created. The

rule returns the name of the Compent(s) to be used among the ones

listed in CADValidComponentList. The control can be archieved by

the corresponding Ruleterm, such as: if [….]then CADComponent =

door, elseif[…]then CADComponent = window.

The rule itself can contain the quantity information in terms of the

quantity of each design variant. For example, in case of the doors:

“if[….]then CADComponent = door1-4, elseif[ …] then

CADComponent = window1-3. The execution of the rule leads to a

product tree with window1, window2, window3.

A CADValidComponentList provides an array with all components,

which can become design variants. For example, the components

“Legs” and “Wall_Mounting” are the mutual excluding aggregated

parts that belong to the parent CADAssembly “Table”. In addition,

the composite association can be used to illustrate the belongings of

components to a specific design variant. In case of the

ClosureSystem the CADValidComponent list would contain Door

and Window.

Thus, the property CADVariationRule returns the name of the

CADComponent to be used among the ones listed in

CADValidComponentList.

3.1 Enhancement to Product Service Life-Cycles

Not only in context of KBE, but in context of design in general, there has been a lack of research

for a systematic transfer of usage information (such as sensor data or user feedback) into

Public


mechanical design. An efficient use of such knowledge requires the setup of related analysis

capabilities, such as filters on the one hand and the identification of dependencies between

usage-related parameters and design parameters or component attributes on the other.

In consequence, the systematic approach of KbeML has been enhanced in order to enable the

representation of the linkages between usage-related parameters and design parameters

allowing to model feedback loops between the Usage Phase (MOL) and design phase (BOL).

Table 3: Addditional KbeML elements referent to information from the product usage phase


A PUIBlock is representing the element were usage information

emerges; it directly relates to a SyML block definition. Blocks are

modular units of system description. Each block defines a collection

of features to describe a system or other element of interest. These

may include both structural and behavioural features, such as

properties and operations, to represent the state of the system and

behaviour, that the system may exhibit.

PUIQuality aims to provide a property for representing the maturity

of data; e.g. a temperature measurement often has a measuring

inaccuracy, or a data stream could have interruptions in frequency.

The property is referring to research in the area of information

quality. According to (Wellsandt et al., 2015) information quality is

defined as a degree of fulfilling its requirements in usage context,

which leads to several dimensions of information quality. In

consequence the property should be replaced by a bunch of

attributes, such as consistency, error freeness, ease of manipulation,

maturity etc. However, to keep modelling simple in this initial phase

it is proposed to make use of simple maturity definition e.g. “high”-

“medium”-; “low”- quality definition.

A PUIParameter always represents a geometry related parameter,

which means that this type of parameter can be processed by a CAD

application. A CADParameter is instantiated by a CADComponent,

CADAssembly, CADEquation, or CADRule (always as stereotype

of property), but can also be used by other elements for non-CAD

related modeling or calculations. It is visualized as a property in a

component or as a box in a parametric diagram.

Public


A StatisticalElement provides a mechanism for representing

dependencies between CAD related parameters. A

StatisticalElement, which is based upon a constraint block can be

used to specify the mathematical expressions, which constrain the

filtering of PUIParameters. Established statistical functions, can be

used for such a filtering (e.g. (Wonnacott and Wonnacott, 1972)).

StatisticalElements can be used for different contexts and vice versa,

different StatisticalElements can be used for a given context. Thus,

they can be provided as predefined objects in modelling

environments allowing to reduce modelling effort and increase

usability.

3.2 Adaption and Enhancement to Services/ Product

configurators

An analysis on the development Product-Service-Systems it turned out, that one element was

missing in order to cope with the fully complexity of PSS. The smart house demonstrator may

serve as a sample. While the As-Is parameters, which are typically provided by sensors, such

as humidity or temperature can be perfectly represented using PUIBlocks, elements being

capable to represent the To-Be parameters have been neglected in KbeMLb so far (before

Manutelligence activities). Thus, so-called UIElements have been specified enabling to

represent the settings of an air condition, temperature control, etc.

In alignment to PUI-related elements an UIElement has become an extension of a PUIBlock,

which covers one or a number of control parameters.

Table 4: KbeML Enhancement to Services/ Product configurators


A UIElement is representing the element, where user input is

captured, it directly relates to a PUIBlock definition. A

PUIBlock is representing the element were usage information

emerges, it directly relates to a SyML block definition.

UIelements are defined by PUIParameters, which are directly

related to the User-Interface. An UIElement may include

Parameters from a control panel, or a thermostatic valve. Each

information snippet has in common that it will represent a “To-

Be” situation, e.g. a comfort temperature or a choosen follow

of a water tap.

Public


4 Relation to LifeCycle modelling & LML

As outlined in section 3 KbeML has been specified as an extension of the UML/SysML

language family and thus could be used in conjunction with both established standards

(UML/SysML). A mix of elements is still logically consistent and not in conflict with the

specifications. In the following the openness of KbeML in terms of compatibility and

extensibility to another Manutelligence related approach is analysed, which can be perceived

as a major component to handle Life-Cycle related information: LML.

In the context of WP2 Manutelligence performed an in depth analysis on Lifecycle Modeling

approaches to find a formal method for the description of lifecycles including all related and

relevant elements required to represent the Manutelligence demonstrators. For this purpose, the

Lifecycle Modeling Language (LML) has been identified and is currently applied to provide

more comprehensive life-cycle models for each of the use-cases (LML, 2015). As outlined in

Figure 5 LML models allow a graphical representation of diagrams, showing connections and

dependencies in a hierarchical network of elements.

Figure 5: Graphical representation in Life-Cycle Modelling Language

With respect to its formal specification, the basis for LML is a classic entity, relationship, and

attribute (ERA) meta-meta model. LML just modified this approach by including attributes on

relationships. Further the Modelling Language has been designed to be translatable into object

Public


languages, such as UML/SysML (LML, 2015). Accordingly, the defined language elements

correspond to classes (entity), relations (relationship), and properties (attribute). This way,

LML diagrams can be at least to some extend transferred into SysML Elements. In Table 5 the

overview for LML (LML, 2015, p. 61) is enhanced by the KbeML perspective (provided as

additional columns):

Table 5: Interdependecies between LML SysML & KbeML

SysML Diagram LML Diagram LML Entities KbeML Entities

Activity Action Diagram Action, Input/Output (n.a. ref. to SysML)

Sequence Sequence Action, Asset (n.a. ref. to SysML)

State Machine State Machine Characteristic (State),

Action (Event)

(n.a. ref. to SysML)

Use Case Asset Diagram Asset, Connection (n.a. ref. to SysML)

Block Definition Class Diagram,

Hierarchy Chart

Input/Output (Data

Class), Action (Method),

Characteristic (Property)

CADAssembly, CADComponent,

CADParameter; PUIParameter,

CADEquation; CADRule;

Internal Block Asset Diagram Asset, Connection (n.a. ref. to SysML)

Package Asset Diagram Asset, Connection CADModell,

Parametric Hierarchy, Spider,

Radar

Characteristic CADParameter;

CADEquationTherm;

CADRuleTherm;

CADOutputPameter, PUIParemeter,

Requirement Hierarchy, Spider Requirement and related

entities

(n.a. ref. to SysML)

However, as outlined in the LML specification an unofficial addition to LML is required to

complete the SysML compatibility (LML, 2015 - Apendix A). According to this appendix the

“equation class” is defined to represent mathematical or logical equations and dependencies in

LML models. Next to capabilities to refer an equation to other LML entities (such as Cost,

Time, or Risk using an equation for relation) the equation can refer to a characteristic element,

which can be perceived as a sibling to the SysML element property.

Public


In SysML syntax an equation is represented by a Constraintblock with a constraint property

having an equation-term as its value. The parameters of the equation itself are defined as

parameters of the constraint-block. Using the parametric diagram (of SysML), equations, which

are defined as constraint properties, can be linked to parameters of blocks as being defined as

part of block Diagrams in advance. This way a SysML model splits between the “equation

related” parameters and the object related parameters. In Figure 6 a sample is provided with a

block representing a car, which has the parameters TotalMass and AverageVelocity (with a

value and unit). A belonging constraint block contains the Equation {F = M * A}. Accordingly,

the equation-related parameters M and A can be linked to the Car in order to define the car

related forces. Since KbeML doubles and extends this kind of SysML syntax, it builds a direct

bridge to LML models as being defined in WP2. The representation of Insulation Calculation

in the smart house case may serve as a sample.

Figure 6: Newton formula applied to Car

Figure 7 shows the LML representation for the calculation of the insulation. The combination

of the simple structure with the graphical visualization for the equation facilitates the

understanding of the dependencies for all stakeholders throughout the product lifecycle. The

Equation entity provides relations to Room geometry and indicates the dependencies to the

Select Wall Insulation process, etc, but Engineering knowledge in terms of the thermal heat

transfer equations or CAD related parameters is neglected (with intention). In other words, by

default the LML models are not foreseen to be parsed by applications and trigger automated

calculations. Rather the dependencies should become explicit for the stakeholders from the

different domains.

Public


Figure 7 Representation of the insulation in LML

In the following, this information is picked up by KbeML in order to relate the dependency to

a (simplified) CAD-model indicating the exploitation of information by development teams in

corresponding CAx applications.

4.1 Sample Case - Thermal insulation

Modern walls can be perceived as components with multilayers, e.g. a gypsum plaster board, a

rock wool layer, PVC foil, Styrofoam, etc. In addition, the walls consist of different sections,

e.g. construction elements (e.g. wooden beams) and nonstructural sections (Figure 8).

Accordingly, the thermal insulation of buildings refers to the different materials for the different

sections and layers and their characteristics.

Public


Figure 8: Prefab wall with structural and non-structural sections (Lindbäcks)

An important variable in context of thermal insulation is thermal conductivity λ. It is defined

as a thickness-independent material property, and should not be mixed up with the U-value.

The thermal conductivity of a substance indicates the amount of heat (in kWh) being transported

in one hour through a surface of 100 m² and 1 meter thickness, when there is a temperature

difference of 10 degrees between the inside and the outside.

Accordingly, the insulation of a material is better if the thermal conductivity is smaller (in direct

comparison to the thermal conductivity of a competing material).

In order to be able to calculate the thermal transmittance, the so-called U-value of a component,

one also needs the insulation value (also called heat transfer resistance) of the individual layers.

The thermal resistance indicates the resistance of a layer to the flow of heat. For its

determination, the thickness of the relevant layer (in meters) is to be divided by the above

defined thermal conductivity, which is only a material-related parameter as outlined above.

𝑅_𝑉𝑎𝑙𝑢𝑒 = 𝑡ℎ𝑖𝑐𝑘𝑛𝑒𝑠𝑠 𝑙

𝑡ℎ𝑒𝑟𝑚𝑎𝑙 𝑐𝑜𝑛𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦 λ

In case of a multilayer component (e.g. a wall of a building), the individual insulation value can

be processed for each layer separately and summarized afterwards. The sum of all individual

thermal resistance values then gives the thermal resistance value for the entire component. The

higher a resistance value becomes, the better the thermal insulation gets.

𝑅_𝑉𝑎𝑙𝑢𝑒𝑇𝑜𝑡𝑎𝑙 = 𝑅_𝑉𝑎𝑙𝑢𝑒𝐿𝑎𝑦𝑒𝑟1 + 𝑅_𝑉𝑎𝑙𝑢𝑒𝐿𝑎𝑦𝑒𝑟2 + ⋯ + 𝑅_𝑉𝑎𝑙𝑢𝑒𝐿𝑎𝑦𝑒𝑟 𝑛

As illustrated below, the U-value of a component (defining the thermal permeability) is the

reciprocal value of the thermal resistance value (insulation value) for the entire component

Public


𝑈_𝑉𝑎𝑙𝑢𝑒 =1

𝑅_𝑉𝑎𝑙𝑢𝑒 𝑇𝑜𝑡𝑎𝑙

Of-course, an inhomogeneous structure of a wall (or ceiling) influences the overall U-value

(and in consequence the heat loss of the building).

Figure 9: Thermal insulation in conjunction with structural components

The calculation of the U-value becomes a bit more complicated, when the thermal insulation is

interrupted by structural components Figure 9. In this case, two areas have to be examined. On

the one hand the compartment, where the thermal insulation lies and on the other hand the

beams, which interrupt the thermal insulation. The beams are only taken into account in the

thickness of the thermal insulation, which is applied laterally. (Usually, steam barriers and

sealing strips are not taken into account during estimated heat protection calculation.)

Accordingly, the following equations can be used to calculate the U-Value:

𝑈𝑉𝑎𝑙𝑢𝑒 𝑇𝑜𝑡𝑎𝑙=

𝑈𝑉𝑎𝑙𝑢𝑒𝐶𝑜𝑚𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡∗ 𝑤𝑖𝑑𝑡ℎ𝐶𝑜𝑚𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡 + 𝑈𝑉𝑎𝑙𝑢𝑒𝐵𝑒𝑎𝑚

∗ 𝑤𝑖𝑑𝑡ℎ𝐵𝑒𝑎𝑚

𝑤𝑖𝑑𝑡ℎ𝐵𝑒𝑎𝑚 + 𝑤𝑖𝑑𝑡ℎ𝐶𝑜𝑚𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡

In the following the above-mentioned equations describing a wall as illustrated in Figure 9 are

captured using the KbeML approach.

The equations related to Layers of the compartment (each layer with a specific U-Value) can

be nested into one resulting equation, which is covering in addition the distinction between

compartments and beams as illustrated below (Figure 10). The CAD related parameters width

of the beams and width of the compartment can be linked to this resulting U-value equation.

Public


The U_Value parameters are modelled as CADParameters as well, since they can be provided

by material libraries, which are typically provided by CAD and/or PDM systems.

Figure 10: Prefab-Wall U_Value Calculation

As indicated in Figure 10 the U_Value Layer Calculation and U_Value Section Calculation are

captured in a generic format and nested into the Prefab-Wall U-Value calculation. The

CADEquation is completed first and mapped to the product model (“red blocks”) afterwards.

This notation provides the advantage to reuse the captured knowledge in different ways:

1. Use of basic equation for other company specific calculations, such as U-Value

Calculation of windows, which consists of frames (section1) and glasses (section2)

while the glasses section consists of different layers (Inner glass, filling, outer glass).

2. Use of the Prefab-Wall Calculation with different components, such as outer and inner

walls of a prefab, which have the same composition, but different geometries (e.g.

thicker beams).

3. A switch between input and output parameters remains possible. If a total U-Value is

perceived as an input parameter, the dependencies can be used to examine (or control)

if a given beam-width (e.g. provided by a structural analysis) exceeds the overall

insulation requirements.

The given sample indicates that KbeML and LML are complementing each other in purpose,

granularity and capabilities. While life-cycle related information is usually captured on high-

level it may have an impact on the “concrete” development level on a specific product.

Public


Accordingly, methods and tools for knowledge capturing should be aligned and as indicated

above this is indeed feasible, if methods and tools are aligned to each other.

5 Enhancement of the Semantic Facilitator

Domain ontology

One research focus of T3.4 is addressing semantic searches and knowledge retrieval of the

codified engineering knowledge. As outlined in Section 6 one pillar to access formalized

knowledge, once captured by a KbeML, is the XML-basement of the standard itself, which

enables software interpretation. The elements (e.g. a CADComponent or a CADEquation) can

be retrieved by parsing KbeML files and the knowledge (e.g. a parameter value) can be

extracted. Next to this technical access, the T3.4 related research activities focused on the

alignment between the Manutelligence approach and the semantic representation of knowledge.

As described in more detail in D3.1 a semantic representation of the Manutelligence domain

has been set-up in order to enable the integration of the Product Lifecycle and Service Lifecycle

(which are today still separated) for PSS. The major result of this activity is a domain ontology

covering lifecycle related concepts such as Actor, Product, etc. Compared to information

storage in databases, ontologies provide specific advantages, which are relevant for an overall

knowledge retrieval and knowledge management approach (as envisaged in context of

Manutelligence). One significant advantage of ontologies is the ability to perform conclusions

(so-called semantic reasoning), which enable the system to establish causality and thus to detect

inconsistencies or inherent knowledge (Gómez-Pérez et al., 2006). Further, ontologies offer the

advantage that objects can be described fully by attributes and this is independent from

existence or non-existence of instances (e.g. a sensor can have a “provides” relation to

“temperature values” even if it is not providing values yet). Ontologies are characterized by the

fact that they are able to reflect progress (Gómez-Pérez et al., 2006). Different stages of an

object can be directly combined semantically with one single object, which is of high value if

the life-cycle related changes have to be captured (as this is the case for Manutelligence). On

the contrary, databases can only realize this by version numbers, which only represent a

progress by their increasing version numbers. In addition, an adaption of the generally described

methods to a specific problem can be easily realized (e.g. an author knowledge-artefact relation

can be specified to a developer CAD model relation). On the contrary, databases need a tailored

solution to a specific problem and thus are not as comfortable for a generic approach to enable

retrieval of codified engineering knowledge as ontologies. Accordingly, T3.4 has copied the

approach of T3.1 and suggests an ontology to support semantic searches and knowledge

retrieval. The ontology, as proposed by D3.1, has been analysed and enhanced by concepts and

Public


relations representing the KbeML entities. In Figure 11 this approach is visualized

schematically:

Figure 11: Enhancement of Semantic Facilitator Domain ontology with KbeML elements

In Table 6 the relations between concepts of the Semantic Facilitator Domain ontology and the

concepts representing KbeML elements have been captured. The relations between the

concepts, which represent KbeML elements, have been aligned to SysML syntax (OMG, 2012).

Even though the OMG does not officially provide an underlying ontology, the integration and

alignment between both has been already examined and research already validated the

applicability of this approach (Graves, 2009).

Table 6: Relations between concepts of Domain ontology and concepts representing KbeML

KbeML

Extension

Relation Manutelligence

Ontology

Description

KbeML File IsSubClassOf File KbeML Files are the “Information Realisation” of

KbeML models, they provide a specific File-

Format and contain Information objects

CADModel;

CADAssembly;

CADComponent;

IsSubClassOf ProductInfo-

rmationObject

The KbeML Elements can be perceived as

ProductInformationObjects. They contain

information related to a product (e.g. the

CADParameters).

CADModel;

CADAssembly;

CADComponent;

ISDefinedIn BOL (SubClass

of ProductLife-

CyclePhase)

The product development related information can

be assigned to BOL, where the product is defined.

PUIBlock IsSubClassOf ProductInformati

on-Object Since PUIBlocks are seen as sata sources and not

as separate “intelligent units” they have not been

assigned to ITSystem but to Product-

InformationObject. They contain information

Public


related to a product (e.g. the PUIParameters), but

related to the usage phase.

PUIBlock ISDefinedIn MOL (SubClass

of ProductLife-

CyclePhase)

The usage related information can be assigned to

MOL, where the product is used.

CADEquation

CADRule

IsSubClassOf InformationObje

ct

The KbeML Elements can be perceived as

independent Information Objects since they

contain information, but not strictly related to the

product. For example, the Newton equation

(Figure 6) is not restricted to a car, but can be

assigned to many products. Accordingly, these are

generic information objects. For this reason the

information is not a assigned to a life-cycle phase

as well (newton equation is valid in BOL,MOL and

EOL …)

CADEquation

CADRule

belongsTo

InformationItem-

Type

The type of information is defined by KbeML.

CADEquation

CADRule

describedBy

DataSchema The type data schema is defined by KbeML.

The enhanced ontology will be provided to the “ubiquitous search Tools” (T4.3). It should help

to create wrappers for semantic based data federation. In this way, it should become feasible to

access the rules and equations (incl. the inheriting knowledge) by a search process. The U-

Value equation for walls may serve as a sample: if captured in KbeML, a query result may turn

out all required input (and output) parameters instead of a non-machine readable description of

the equation in a document. This way a company-internal library of “common” engineering

knowledge “predefined” by KbeML may become a knowledge base itself.

6 Interfaces to current knowledge bases

The following section is focussing on interfaces to current knowledge bases in order to encode

knowledge from such repositories in the standardized format, as being proposed in context of

T4.3.

Public


By default, KbeML models can be used to exchange codified engineering knowledge due to the

openness of SysML (and the SysML extension), which is guaranteed by the XMI standard. As

shown in Table 7, each expression within the XMI-file is dedicated to a unique ID; this way

expressions can be re-used within the file or mapped with other expression. For example, the

equation for the U-Value Section Calculation is dedicated to a specific ID and this way also

mapped to the KBE-Profile CADEquationTerm. The parameter U-ValueTotal is marked as a

CADOutputParameter analogue to this mapping.

Table 7: XMI-file of a KbeML model with highlighted element identifiers

KbeML File (extract) Meaning

...

<ownedAttribute xmi:type="sysML:ConstraintProperty"

xmi:id="_tjOqIw2tEeSOiLl9u1smzQ" name="U_Value SECTION

Calculation" type="_vmWkIAwbEeSuFZ_bSRZnLA">

<defaultValue xmi:type="uml:LiteralString"

xmi:id="_tjOqJA2tEeSOiLl9u1smzQ"

value="(U_Value)_Total = ((U-Value)_Section1 *

width_section1 + (U-Value)_Section2 *

width_section2")/( width_section1 +

width_section2)/>

</ownedAttribute>

...

<ownedAttribute xmi:type="uml:Property"

xmi:id="_tjOqJQ2tEeSOiLl9u1smzQ" name="(U_Value)_Total "

type="_vmWkIAwbEeSuFZ_bSRZnLA">

<defaultValue xmi:type="uml:LiteralString"

xmi:id="_tjOqJg2tEeSOiLl9u1smzQ" value=""/>

...

<KBEProfile:CADEquationTerm

xmi:id="_SfFR4A2uEeSOiLl9u1smzQ"

base_ConstraintProperty="_tjOqIw2tEeSOiLl9u1smzQ"/>

...

<KBEProfile:CADOutputParameter

xmi:id="_Mqv7wA2uEeSOiLl9u1smzQ"

base_Property="_tjOqJQ2tEeSOiLl9u1smzQ"/>

...

U-Value Section Calculation

is defined as a

CADEquationTerm with the

equation as being provided

by Figure 10.

U-ValueTotal is defined as a

CADOutputparameter

with its Value “”

Type CADEquationTerm is

identified by the

corresponding internal ID

Type CADOutputParameter

is identified by the

corresponding internal ID

Public


If parsed, this information can be used to create interfaces to knowledge bases to capture this

knowledge in the standardized format. The XMI elements can be mapped to other applications

such as e.g. parameters, which are defined in the 3DS platform or in CAD. For example, the

CADParameter BeamWidth (of the XMI) can be related to a parameter of a CATIA CADPart

file with its (cumbersome) internal name “Hauptkörper/Block.2/ Skizze.2/Länge.12”. This way

the information can be exchanged between KbeML models and models in CAx-applications

and internally applied. In principle formalized knowledge of the XMI can be used in KBE

related CAD applications directly, since equations can be transferred either. The only limitation

comes along with the CADEquationtherm, which has to be restricted to use the syntax of the

corresponding CAD Application, such as the CATIA KnowledgeAdvisor and its syntax (ref to

Section 2.1).

In Figure 12 the knowledge exchange between a CAD application and a modelling environment

(where a K-Model is managed) is presented schematically. The proposed exchange process

relies on the openness of KbeML, which is guaranteed by the XMI standard.

Figure 12: Parameter mapping between KbeML model and commercial CAx application (schematic)

Of-course a mapping may also be used for a knowledge transfer into KbeML: user information

sources can be defined as KbeML elements and values can be imported into a corresponding

model and reused afterwards in the models (section 3.1).

Even specific Elements such as the predefined StatisticalElements can be mapped to

applications (such as Rapidminer (Rapidminer, 2016)) enabling to create semi-automated

workflows directly from the KbeML models.

Public


7 Summary and conclusions

As outlined in section 3 the deliverable summarizes the T3.4 related activities. In reference to

an analysis of the 3DS platform and its main component (namely CATIA), current

shortcomings of commercial KBE applications have been identified with a special focus on

Life-Cycle and usage information (such as sensor data or user feedback), which have to be

provided for design. The modelling language KbeML, which has been specified by BIBA and

enhanced and refined in context of the Manutelligence research, approaches to become a

standardized representation for codified engineering knowledge. It inherits the capability to

represent product usage information and data in terms of sensors & sources belonging to a

product-class (e.g. Ferrari FF) as well as related to usage data belonging to the instances (e.g.

my Ferrari FF, your Ferrari FF). Specific elements, called StatisticalElements, enabling to

document the statistical analysis methods, are used to transfer usage data as input for the

product-development phase (e.g. median of the engine temperatures of your Ferrari, & my

Ferrari).

As outlined exemplarily for the insulation of prefab walls KbeML is complementing the life-

cycle modelling language LML and allows to detail the identified actions, such as insulation

calculation. It enables to codify required rules and equations needed to represent aspects of

interest, such as heat-loss or vice versa required thicknesses of wall layers. Since it is based

upon a formal machine-readable representation of knowledge, KbeML enables to make

development-related rules & algorithms accessible for different CAx Systems. In principle,

such codified information can be used on different levels. Equations or parameters can be

exchanged among systems and/or the models can be used as blue prints for automated design

solutions of both types (the object oriented programming approach or geometry based

approach).

Finally, the research activities focussed on the alignment of KbeML to the facilitator domain

ontology, to enable retrieval of codified engineering knowledge from the “P-S engineering and

manufacturing ubiquitous search tools”. The enhancement of the ontology with additional

elements related to KbeML will support semantic search as envisaged in Manutelligence as

well.

All T3.4 related results will be provided to parallel and subsequent Manutelligence activities,

particularly to T4.3 for the development of “ubiquitous search Tools”, to T3.1 for the semantic

facilitator ontology and to WP6 for setting up the smart house demonstrator.

Public


8 References

Colombo, G., Pugliese, D., Klein, P., Lutzenberger, J., 2014. A study for neutral format to

exchange and reuse engineering knowledge in KBE applications, in: Engineering,

Technology and Innovation (ICE), 2014 International ICE Conference on. IEEE, pp. 1–

10.

Curran, R., Verhagen, W.J.C., van Tooren, M.J.L., van der Laan, T.H., 2010. A

multidisciplinary implementation methodology for knowledge based engineering:

KNOMAD. Expert Syst. Appl., Advances in Aligning Knowledge Systems, Improving

Business Logistics, Driving Innovation and Adapting Customer Centric Services 37,

7336–7350. doi:10.1016/j.eswa.2010.04.027

Dassault, 2016. 3D CAD CATIA Solutions by Dassault Systèmes [WWW Document]. URL

http://www.3ds.com/products-services/catia/ (accessed 12.19.16).

Dassault, 3DS, 2016. Products & Services [WWW Document]. URL http://www.3ds.com/en-

uk/products-services/ (accessed 12.19.16).

Franke, M., Klein, P., Schröder, L., Thoben, K.-D., 2011. Ontological Semantics of Standards

and PLM Repositories in the Product Development Phase, in: Bernard, A. (Ed.), Global

Product Development. Springer Berlin Heidelberg, pp. 473–482. doi:10.1007/978-3-

642-15973-2_48

Gómez-Pérez, A., Fernandez-Lopez, M., Corcho, O., 2006. Ontological Engineering: with

examples from the areas of Knowledge Management, e-Commerce and the Semantic

Web. First Edition. Springer Science & Business Media.

Graves, H., 2009. Integrating SysML and OWL, in: Proceedings of the 6th International

Conference on OWL: Experiences and Directions-Volume 529. CEUR-WS. org, pp.

117–124.

Kulon, J., Broomhead, P., Mynors, D.J., 2006. Applying knowledge-based engineering to

traditional manufacturing design. Int. J. Adv. Manuf. Technol. 30, 945–951.

doi:10.1007/s00170-005-0067-0

La Rocca, G., Van Tooren, M.J.L., 2007. Enabling distributed multi-disciplinary design of

complex products: a knowledge based engineering approach. J. Des. Res. 5, 333–352.

LML, 2015. Specification | Lifecycle Modeling Language [WWW Document]. URL

http://www.lifecyclemodeling.org/specification/ (accessed 12.21.16).

Milton, N.R., 2008. Knowledge technologies. Polimetrica.

OMG, 2016. Object Management Group [WWW Document]. URL http://www.omg.org/

(accessed 12.22.16).

Public


OMG, 2012. SysML 1.3 [WWW Document]. URL http://www.omg.org/spec/SysML/

(accessed 3.18.16).

Prasad, B., 2005. What distinguishes KBE from automation. COE NewsNet.

Rapidminer, 2016. Data Science | Machine Learning [WWW Document]. RapidMiner. URL

https://rapidminer.com/ (accessed 1.10.17).

Siemens NX, 2016. NX: Siemens PLM Software [WWW Document]. URL

https://www.plm.automation.siemens.com/de_de/products/nx/ (accessed 12.22.16).

Skarka, W., 2007. Application of MOKA methodology in generative model creation using

CATIA. Eng. Appl. Artif. Intell. 20, 677–690. doi:10.1016/j.engappai.2006.11.019

Stokes, M., 2001. Managing engineering knowledge: MOKA: methodology for knowledge

based engineering applications. Professional Engineering Publishing London.

Verhagen, W.J., Bermell-Garcia, P., van Dijk, R.E., Curran, R., 2012. A critical review of

Knowledge-Based Engineering: An identification of research challenges. Adv. Eng.

Inform. 26, 5–15.

Vermeulen, B., 2007. Knowledge based method for solving complexity in design problems.

Wellsandt, S., Wuest, T., Hribernik, K., Thoben, K.-D., 2015. Information Quality in PLM: A

Product Design Perspective, in: Advances in Production Management Systems:

Innovative Production Management Towards Sustainable Growth. Springer, pp. 515–

523.

Wonnacott, T.H., Wonnacott, R.J., 1972. Introductory statistics. Wiley New York.

d3.4 definition and development of kbe- · pdf filed3.4 – definition and development of...

Documents