=Paper=
{{Paper
|id=Vol-2945/11-ER-ConfWS21_paper_14
|storemode=property
|title=Facilitating Configuration Model Formalization based on Systems Engineering
|pdfUrl=https://ceur-ws.org/Vol-2945/11-ER-ConfWS21_paper_14.pdf
|volume=Vol-2945
|authors=Eugen Rigger,Tino Stankovic,Ruth Fleisch
|dblpUrl=https://dblp.org/rec/conf/confws/RiggerSF21
}}
==Facilitating Configuration Model Formalization based on Systems Engineering==
https://ceur-ws.org/Vol-2945/11-ER-ConfWS21_paper_14.pdf
Facilitating Configuration Model Formalization based on
Systems Engineering
Eugen Rigger1 and Ruth Fleisch1 and Tino Stankovic2
Abstract.1 Dynamic markets that call for customized products and the software engineering domain and features object-oriented
shorter lead time in product development urge companies to apply modelling of multidisciplinary systems.
technologies such as product configuration systems to leverage Product configuration is applied to support the decision-making
performance in product development and its related processes. process in sales and engineering phases [7] based on reasoning
Product configuration can be referred as a knowledge intensive
among a set of predefined components and their relations, referred
technology that relies on the application of formalized product
knowledge to enable automated reasoning. However, the related to as the configuration model [8]. Product configuration systems
knowledge formalization is still considered a major obstacle for the support the product configuration by automated reasoning based on
integration of configuration technologies since often being customer requirements and the configuration model. However, a
conducted by non-domain experts. In this work, we present a major obstacle in the application of product configuration systems
method for the formalization of product configuration related is the knowledge acquisition that is required to enable
knowledge as early as during development of an engineering formalization of the configuration model [9]. Reason for this is the
system using the systems modelling language SysML. Based on a current knowledge acquisition practice where knowledge engineers
reference example from literature, it is shown how the required acquire and formalize the knowledge gained from domain experts
configuration knowledge can be formalized by the systems [2] which is a costly process that is also considered critical since it
engineer to avoid costly and error prone knowledge acquisition in
is founded upon knowledge sharing and trust [10]. Regarding
later stages of the product lifecycle. The yielded SysML model
relies on graphical modelling, only, and can be directly integrated knowledge formalization, the application of object-oriented
in existing system models. Thereby, the proposed method modelling supports the formalization of configuration models [11].
facilitates formalization of configuration knowledge for engineers Hence, there is potential to integrate MBSE and product
and enables reuse of existing models so to save time and reduce configuration so that knowledge that is defined in product
errors when formalizing configuration models. development can be reused in later stages of the lifecycle to
establish a product configuration system. This reuse of knowledge
can facilitate the process of knowledge acquisition or even make it
1 INTRODUCTION obsolete. However, currently the topics MBSE and product
Currently, engineering companies are facing two challenges that configuration are not linked [12]. Hence, there is a gap that
call for the application of new methods in the engineering and sales integrates systems modelling and knowledge formalization for
of their products: first, the complexity of engineering systems is configuration models.
growing with respect to the number of components and functions In this paper we propose a method that closes this gap by
of a system as well as the involved disciplines [1]. Second, product linking MBSE and product configuration using SysML. The
development cycles tend to get shorter and customers ask for method demonstrates how standard modelling language syntax can
highly customized products with reduced engineering lead time [2]. be applied to formalize dependencies in the systems model to
In response to these needs, model-based systems engineering establish a configuration model. A systems model that already
(MBSE) and product configuration can be considered as enabling captures the constraints and dependencies regarding the product
methods that will allow industry to reconcile and meet the two architecture can be adapted and extended so to reuse already
conflicting challenges. MBSE is defined as “the formalized formalized knowledge and ensure consistency among models. The
application of modelling to support system requirements, design, resulting configuration model can then be applied in product
analysis, verification and validation activities beginning in the configuration systems via model transformations [13].
conceptual design phase and continuing throughout development Consequently, the focus and motivation of this work is to enable
and later life cycle phases” [3]. In this respect, the Systems system engineers/domain experts to contribute to the definition of
Modelling Language (SysML)[4] has been established as the configuration model, enable reuse of knowledge for
modelling standard for MBSE and can be considered the most configuration modelling and thereby ensure consistency of models
commonly applied language in MBSE [5]. SysML extends the and knowledge among different stages of the product lifecycle.
unified modelling language (UML) [6] that is primarily applied in Thus, the knowledge acquisition bottleneck is tackled, in particular
for companies applying MBSE. The method presented in this paper
is validated based on a case study of a configuration example for
1
Digital Engineering, V-Research GmbH, Austria, eugen.rigger@v- personal computers according to [8,11].
research.at The remainder of the paper is structured as follows: Section 2
2
Engineering Design and Computing Laboratory, ETH Zurich, introduces the related background of MBSE and knowledge
Switzerland, tinos@ethz.ch
Copyright 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0)
formalization in the context of product configuration and SysML. 2.2 SysML-based Knowledge Formalization
Section 3 then introduces the method for modelling configuration
knowledge during product development. Section 4 shows the Regarding the usage of a standardized language for formalization
validation of the proposed method based on a case study and of engineering knowledge, SysML has recently been addressed by
discusses attained results. The paper closes by presenting multiple approaches identified in literature. SysML has evolved
concluding remarks in Section 5. since 2007 as a standardized model language to support model-
based systems engineering (MBSE) [21,22]. SysML as an object-
oriented modelling language aims to support communication and
2 BACKGROUND understanding of formalized knowledge [22]. The language
provides the full semantic foundation for documentation of system
In this section, first the terminology of data, information and requirements, behavior, structure, and parametric relations. As a
knowledge is clarified and ways to differentiate the types of standardized language, SysML features reuse of models to avoid
knowledge are reviewed and put into context with product loss of knowledge between projects and reduce cost and risk in
configuration. Next, basics of MBSE are introduced and existing design [1]. In the context of formalization of a configuration
efforts for application of the SysML modelling language as a model, the definition of hierarchical structures and relations among
standardized language for knowledge formalization are introduced these are of relevance. Figure 1 depicts the diagrams that are
and reviewed. Based thereon, the research gaps addressed in this considered relevant for the formalization of configuration models.
work are presented.
2.1 Types of Engineering Knowledge
Knowledge can be classified as tacit and formal knowledge [14]
whereas the first refers to expert knowledge and intuition, formal
engineering knowledge corresponds to information embedded in
data, such as design guidelines, SysML and CAD models etc. To
further distinguish the terms “knowledge”, “information”, and
“data” in this work, the definition by the VDI 5610 [15] which is
aligned with other definitions found in literature, e.g. [16,17] is
applied:
• “Data are objective facts, they cannot be interpreted
without context and further backgrounds. They are to be Figure 1. Excerpt of SysML diagram taxonomy [4]
taken as “raw material”.
• Information are structured data with relevance and First, package diagrams (PKG) can be used to organize the model
purpose, which can be put into a context, categorized, in containers referred to as packages. Packages aggregate other
calculated and corrected. model elements and are described by a name and URL (Uniform
• Knowledge is linked information, which enables to draw Resource Locator) making them uniquely identifiable and
comparisons, to establish links and to make decisions. “ accessible so to foster reuse of models. For instance, model
In the context of computational support to automate tasks of libraries or distinct parts of a system model such as its functional or
product development which is referred to as design automation, logical architecture are organized within separate packages. The
various ways of structuring engineering knowledge are presented block definition diagram (BDD) enables the definition of
in literature. The work from [18] differentiates process, task and hierarchical relations among the entities of a system called blocks.
product knowledge. Product knowledge refers to the knowledge Blocks are used to describe types of physical entities such as
about the specifics of the product, such as its architecture, its components but also conceptual entities such as the functions of a
components, and the related dependencies. Process knowledge system. Blocks are described based on part, value and constraint
captures the knowledge on how to apply information in the context properties. Value properties account for quantifiable characteristics
of the product. The task knowledge considers knowledge on of a block such as weight, speed, etc. and can be typed by primitive
algorithms and rules to update the product model. Similarly, [19] types such as integers, reals or strings. Default values or default
distinguish between procedural and declarative knowledge, where range of values can be assigned to value properties upon definition
procedural refers to design process knowledge and declarative to of a block. Part-of associations are used within block definition
product knowledge. In the context of product configuration diagrams among blocks to define the part properties describing the
systems that feature strict separation of the configuration model composition of a block. In this context, multiplicities can be used to
and the related reasoning [20], product knowledge can be indicate the total amount of child blocks of a specific type, e.g. a
considered the basis for the configuration model. A configuration car consist of four wheels. To model variance in a system,
model captures all information about a product so that a constraint generalizations can be used. For example, “SUV” or “Van” refer to
satisfaction problem (CSP) can be formalized. The CSP forms the two different variants of the block “car” that both inherit the
basis of a product configuration systems which then deduces properties of the more general parent block. For the case that a
configurations based on user input [8]. A basic CSP is described by block is used as a blueprint so to be reused by its specialized
a set of variables, the related domains (ranges) and constraints that variants, blocks can be typed as abstract. This is particularly useful
limit the combination of variables. for definition of model libraries so that its elements can be reused
among various models [23]. The internal block diagram (IBD) is
used to detail the internal structure of a specific block, to for
example define interfaces and connections among nested blocks. account for the specifics of configuration modelling. Thus, the
However, in the context of configuration modelling, the parametric formalization of a configuration model can take place early in
diagram (PAR) is more applicable since it enables the product development, and integrated to a (MBSE) process and the
formalization of constraints among properties of blocks. For this related models. Thereby, a system model corresponding to the
purpose, SysML provides constraint blocks for the formalization of “single source of truth” can be established integrating all relevant
equations and rules. Constraint blocks can be assigned as information about the system for later processing during the
constraint properties to blocks. Using a PAR, the constraint product lifecycle [1]
property can be linked to the block’s properties using binding In the following, first, means to organize the configuration
connection. Figure 7 shows an example of a parametric diagram model within a system model are introduced. Next, the semantics
representing a constraint property of type CalculatePrice with for the formalization of a configuration model are introduced.
rounded edges. The constraint property belongs to the owning
block HDUnit denoting the boundary of the PAR. Using binding
connections, the PAR puts into context the constraint property, 3.1 Organize the Configuration Model
HDUnit’s value property price and the value properties price that To organize and structure the knowledge for establishing a
belong to hdcontroller and hdisk. To customize SysML for specific configuration model, the following packages are defined: the
domains, stereotypes can be introduced to define new modelling package “product architecture” captures the information related to
elements. This can be used to define a domain specific language the hierarchy of the system and used blocks. The package
for parametric CAD [24]. “interconnections” is used to aggregate the definitions of
Relevant approaches in the context of design automation feature constraints among the blocks’ properties. Within the package
systematics for definition of model-libraries for reuse [23,25], “model libraries”, model libraries can be defined or integrated to
formalization of parameter synthesis tasks [26], formalization of foster the reuse of model elements. Further, the usage of abstract
CAD configuration tasks [24], formalization of simulation-based blocks for instantiation of model libraries enables formalization of
design tasks [27] [28], or neutral modelling of simulation models constraints among abstract blocks rather than the specific children
that can be then translated to the format of the desired simulation blocks. Thereby, the formalization of generic CSPs [8] is rendered
tool [29]. Reason for the interest in SysML for design automation feasible. Figure 2 shows the package diagram as a starting point for
task formalization is the aspect of integration of formalizations to formalizing the configuration model. It is shown how the package
MBSE processes, and its means to support communication and “Configuration” aggregates the three packages used to define the
understanding of formalized knowledge. However, presented configuration model and how the package itself is integrated to the
approaches rely on customizations of SysML based on newly system model. Therefore, the information about the system can be
introduced stereotypes hindering the integration to industrial captured within one model comprehensively. The organization of
environments where models are defined following the SysML the system model depicted in Figure 2 follows the structure
standard. Further, focus is put on technological aspects of the proposed in [22] enriched by the package “Configuration”.
customization of the language rather than the possibility for
integration to workflows of engineers. For example, in [26]
stereotypes reflecting the characteristics of a mathematical
optimization problems are introduced. Hence, for successful
application, engineers require fundamental knowledge about
mathematical modelling.
Regarding the domain of product configuration, [12] show that
MBSE and product configuration are currently not linked an
suggest the usage of SysML models reflecting the modular product
architecture as a basis for development of the configuration model.
However, the suggested approach by [12] lacks details regarding
the integration of the system model and the configuration model,
such as consistency management.
Consequently, means to enable engineers to formalize product
knowledge in a reusable, intuitive manner that also ensures
consistency of models among the product lifecycle are missing. In
Figure 2. PKG depicting the structure of a configuration model within
a literature review on knowledge levels required for the
a systems model.
formalization of design automation tasks, [30] proposed to use
SysML as a standardized language providing the full semantics
required for design automation task definition. Thus, in this work, a 3.2 Define the Configuration Model
method is proposed that facilitates knowledge formalization for
usage in product configurators following the SysML standard. In the following it is shown how the packages depicted in Figure 2
can be enriched to fully define a configuration model by using
existing SysML syntax, only. First, the concept of model libraries
3 CONFIGURATION MODEL is briefly introduced so that the definition of generic components is
FORMALIZATION USING SysML enabled (3.2.1). Afterwards, the instantiation of product
architectures is shown including the formalization of related
In this section the method combining MBSE and product variables and constraints directly within the product architecture
configuration is presented. SysML semantics are overloaded to using relations on a block definition diagram (3.2.2) and by
defining parametric relations using constraint blocks and constraints can be defined using these variables. For example, a
parametric diagrams (3.2.3). customer might want to specify a maximum price when
configuring a car. The block ConfigurationModel is then linked to
the block “System” using a part-of association.
3.2.1 Model Libraries Variables and dedicated types of constraints can be declared
A model library can be defined using a block definition diagram. directly within the product architecture using the modelling
Once a model library is instantiated, it can be reused among elements listed in table 2: Abstract blocks are used to indicate
different projects. In this work, the systematics of model library selection of components, multiplicities to define variability in the
definition as proposed in [23,25] are applied as illustrated in Figure number of a specific block and value properties to specify
3. In particular, the concepts of inheritance are applied to define (discrete) variables and the corresponding solution domain by
abstraction hierarchies [31]. With this respect, SysML provides specifying the default value. Value properties of SysML blocks
generalization relationships between blocks as well as the that are not assigned any value or a specific value, respectively, are
definition of abstract elements. This enables the definition of considered as parameters and are not subject to the CSP. Within
abstract components where generic constraints can be defined Figure 4, the block LibraryElement refers to a component that
upon. The information regarding variance of a product can be needs to be selected from the component library according to
already captured within the system model for description of requirements. The DiscreteVariable of Child1 refers to a variable
product families [32] and therefore can be directly reused within with indicated domain by assigning a value range to the value
the configuration model. property. The multiplicity of Child2 shows that this block needs to
be in the system at least once but can also be prevalent in a larger
Table 1. Model elements used for definition of component libraries. amount within the final configuration, depending on customer
Model Model type Symbol Meaning requirements. It must be noted that variable declaration can be
elements combined, e.g., a library element possibly contains a variable
Block Block Modular unit of a which is to be determined when configuring the product.
system
Table 2. Key model elements used on BDD for definition of product
Abstract Block The block cannot be architectures including constraints.
Block instantiated and is used Model Model type Symbol Meaning
for inheriting elements
properties, only. Abstract Block Indication of a discrete
Specializ Specialization Inheritance of parent Block variable for component
ation Relation block’s properties to selection. Works in
child block conjunction with model
libraries, only.
Multiplicity Part-of Indication of parts as
association discrete variables with
multiplicity as lower
and upper bound of
variable
Variable Value a,b,c,d,… Indication of (discrete)
range property variable domain.
Figure 3. Generic example of component library illustrating the
modelling concepts shown in Table 1.
3.2.2 Product Architecture
The product architecture in MBSE is defined using a block
definition diagram and captures all aspects regarding the
hierarchical organization of a system. Hence, the product
architecture can be directly reused for defining the configuration
model. According to the object-oriented paradigm of SysML [22],
the hierarchical structure of a system (the product architecture)
requires a main block that aggregates the parts (i.e. subsystems / - Figure 4. Generic example of product architecture as well as possible
assemblies / - components). In the context of the configuration constraints using concepts shown in Table 2.
model, a main block ConfigurationModel is introduced so to
separate the configuration model from the remaining system model
and serve as a starting point. Further, characteristic input variables
are assigned to the ConfigurationModel itself, so that subsequently
3.2.3 Interconnections 4.2 Defining the PC Configuration Model
To define constraints related to interconnection of value and part Figure 5 shows the model library that is used for defining the
properties of the blocks, parametric diagrams can be used. components of the PC that need to be selected based on customers’
Thereby, constraints for the configuration model can be defined requirements. It shows that different variants for the hard disk
based on linking constraint blocks to specific value and part (HDisk), the related controller (HDController), the central
properties, e.g. if each block contains a value property indicating processing unit (CPU), the operating system (OS), the motherboard
the cost, a constraint can be defined stating the cost of all active (MB) and screens exist.
components needs to be below a specific threshold. For each Figure 6 shows the product architecture of the PC. Multiplicities
interconnection, first a constraint block is defined specifying all define the domain of decision variables of the amount of each child
variables used within the constraint by assigning value and part component. The value properties in the configuration model
properties to the constraint as well as a constraint expression. Next, (maxPrice, usage, efficiency) denote customer requirements which
a parametric diagram depicting the constraint block is instantiated are linked to properties of other blocks via interconnections as
that is then linked to the package “interconnections” to provide the detailed below.
required overview of formalized constraints. Depending on the
type of constraint properties, the main different types of constraints
can be formalized as follows:
1. Parametric relations for two or more value properties.
2. Decision structure matrices [33] are used to define
compatibility among part properties: a .csv table
(comma-separated values) with semicolon as
separator and constraints expressions. Thereby, all
possible instances of the part properties build the
column and row headings. Incompatibilities are
indicated based on “0”, required combinations by “x”.
For the case of no entry, combinations of the part
properties are allowed.
3. Decision tables [34] are applied to formalize if-then
relations among different types of properties. In the
rows, first all conditions are listed followed by the
properties that need to be excluded (“0”) or are
required (“x”).
Examples of the formalization of interconnections are provided
in the following section where a case study for configuration of
personal computers is introduced. With the suggested types of Figure 5. Model library of the PC configuration example.
constraints, the provided case study can be formalized. However,
the list does not claim completeness and additional types will need
to be added for special cases.
4 CASE STUDY
In [8] a configuration model of a personal computer (PC) is
described using UML and for some of the constraints a textual
representation is applied. In the following, the formalization of the
configuration model using SysML syntax, only, is presented.
Similar to Section 3, the model is introduced by first showing the
package structure of the configuration model in relation to the
personal computer system model. Following this, the model
libraries are presented as well as the product architecture. Finally,
representative interconnections are depicted detailing the three
different types of constraints according to Section 3.2.3. All
models were defined using the Papyrus 5.0.0 open-source
modelling environment. Figure 6. Product architecture of the configuration model.
Regarding the definition of interconnections among the blocks’
4.1 Organizing the PC Configuration Model properties, Figure 7 shows an example of a parametric relation:
The defined constraint links several value properties denoting that
In a first step, the PC configuration model is integrated to the the price of the hard disk unit (HDUnit) is defined by the prices of
existing system model of a personal computer as depicted in Figure the hard disks and controllers. It must be noted that multiplicities
2. Since the configuration model is integrated on the same level as are considered implicitly by multiplying the value properties with
the system model, reuse of elements from the system model is the amount defined by the multiplicities of the owning blocks.
enabled.
Similarly, the computation of the price of the PC can be defined as 5 DISCUSSION
the sum of the prices of the hard disk units, the motherboard, the
CPUs, the operating system, the screens, applications, and the The discussion of the proposed method for formalization of
internet connection (InternetConn). Additional interconnections configuration models using SysML is based on the findings from
are: One linking the price limit defined by the customer (maxPrice) the case study presented in Section 4 and split into two parts: First,
with the price of the PC, one ensuring that the capacity of all hard the knowledge representation yielded by application of SysML is
disks in total is larger than the required capacities (value properties reviewed according to the nine criteria introduced in [8]. Second,
hdcapacity) of the operating system and selected applications, and the integration within MBSE is critically reviewed.
two others equating the efficiency of the PC with the efficiency of
the motherboard and of the screens, respectively. Interconnections
among two part properties are used to denote restrictions and
requirements regarding the selection of CPUs, motherboards and
operating systems. Figure 8 shows the definition of the decision
table for CPUs and motherboards. The constraint property
highlights the formalization of the constraint as a .csv table.
Finally, interconnections between a value property and part
properties are applied to link the customer input regarding the
selection of efficiency classes to the respective motherboards and
screens. In this case, the .csv-table lists the instances of the value
properties as column headings and all possible instances of the part
properties. Figure 9 show the respective parametric diagram.
Similarly, internet and multimedia usage are linked to the internet
connection so to define that for these cases an internet connection Figure 9. Interconnection among value and part properties.
must be prevalent. Further, for the case of scientific usage, a CPU
of type CPUD needs to be selected.
5.1 Benchmark of Knowledge Representation
In the following the criteria for assessment of knowledge
representations for configuration models [8] are introduced using
italic letters. Each criterion is then discussed separately:
Standard graphical modelling concepts?
The approach presented in this work builds upon the SysML, an
established standard. Recent reviews show that (1) model-based
systems engineering is gaining popularity [35], and (2) SysML is
the dominating modelling language for MBSE [5]. The case study
shows that a configuration model can be fully formalized using
SysML-based graphical modelling, only. No coding is required for
formalization of additional constraints. Thereby, the presented
approach adds up to existing formalization relying on UML.
Component-oriented modelling?
Being an object-oriented modelling language developed for the
modelling of complex systems, SysML enables the representation
of hierarchical component structures facilitating the
Figure 7. Interconnection among value properties defining the price of communication of configuration models. Additionally, the
the HDUnit. integration of the configuration model directly within the system
model fosters reuse of components mitigating efforts and reducing
errors for formalization of configuration models.
Automated consistency maintenance?
Commercial modelling applications provide basic support for
model validation. However, integration of support for the
formalization of configuration models requires model
transformations to other representations where evaluation of
constraints is rendered feasible. This topic is considered a potential
line of future work.
Modularization concepts available?
The concept of package diagrams allows to organize a model in
modules. Further, the presented approach presents a concept for
organizing the configuration model according to the type of
Figure 8. Interconnection among two part properties defining knowledge that is being formalized: product architecture, model
compatibilities among blocks. libraries and interconnections.
Support of easy knowledge base evolution and maintenance?
SysML is intended to support formalization and communication of
complex knowledge. Therefore, the proposed approach aims to
enable knowledge engineers to reuse essential product knowledge automation methods in general. This will facilitate integration of
from the system model. Preliminary usability studies with computational methods in product development so to enable a
engineers from industry indicate the potential of the approach to vision of digital engineering, where computational methods can be
enable domain experts to formalize essential parts of a rapidly defined and integrated by engineers themselves.
configuration model themselves. Therefore, the proposed approach
fosters collaboration of domain experts and knowledge engineers.
Model-based knowledge representation? 6 CONCLUSION
Using SysML, the configuration model is represented in a
declarative manner that needs to be transformed to a representation In this paper a method to integrate MBSE and configuration
that can be linked to reasoning mechanisms. Hence, the modelling is presented. Based on SysML, the method builds upon a
configuration model and problem-solving logic are strictly standardized language and enables integration of system and
separated as required in a model-based approach [36]. configuration models so to ensure consistency of product
Efficient reasoning? knowledge along the product lifecycle. Thereby, reuse of models is
Using model transformations, the SysML configuration model can enabled to save time when modelling, reduce errors when relying
be transferred to various representations such as CSP models. on already validated models and facilitate collaboration of domain
However, model transformation potentially yields sub-optimal experts and knowledge engineers. Evaluation of the proposed
formalizations leading to losses in performance when compared to method based on a reference example from literature shows that a
formalizations done directly within the solver’s environment. full configuration model can be defined using existing SysML
Able to solve generative problem settings? syntax, only. The application of the method does not require the
No, however, when using nested configuration models, generative
use of coding techniques for formalization of the configuration
problem configuration scenarios where the constraints are added to
model. Future work needs to investigate the broader validation of
the configuration model on demand could be enabled. Future work
needs to elaborate on concepts enabling nested configuration when the approach based on additional use cases as well as the
using SysML modelling. assessment of the usability with domain experts and knowledge
Able to provide explanations? engineers. The focus of these investigations will be on the
Since the configuration model needs to be transformed to a extension of the method towards the formalization of design
representation for solving the configuration problem, explanations automation tasks and debugging of knowledge bases. The vision is
are potentially enabled when using appropriate representations [8]. that facilitated knowledge formalization will foster the application
of design automation in industrial practice.
5.2 Systems Engineering Integration
ACKNOWLEDGEMENTS
The introduced method builds upon SysML syntax without
modifications or extensions of the modelling language. Therefore, We would like to thank the referees for their comments, which
the configuration model can be defined reusing essential parts of helped improve this paper considerably.
the system model. When combining MBSE and product This work has been partially supported and funded by the
configuration, domain experts implicitly formalize parts of the Austrian Research Promotion Agency (FFG) via the “Austrian
configuration model and knowledge engineers can directly build Competence Center for Digital Production” (CDP) no. 881843, the
upon the system model, respectively. The integration of already K2 centre InTribology, no. 872176 as well as ASID, no. 856326.
validated knowledge allows saving time and reducing errors in
modelling. Further, having one representation for different stages
of the product lifecycle ensures consistency of data, such as REFERENCES
propagation of modifications in product families after engineering
change requests. However, in the presented approach the [1] B. Beihoff, C. Oster, S. Friedenthal, Paredis, Christiaan, D. Kemp,
organization of models within packages needs to be strictly H. Stoewer, D. Nichols, J. Wade, A World in Motion – Systems
followed so that reasoning among models is confined to the content Engineering Vision 2025, INCOSE, San Diego, California, 2014.
available within the package. In this respect, future work needs to [2] C. Forza, F. Salvador, Product information management for mass
elaborate on means to assure the correct formalization of customization, Palgrave Macmillan New York, 2007.
configuration models in existing system models. For example,
[3] INCOSE-TP-2004, Systems Engineering Vision 2020, INCOSE,
processes need to be elaborated to define collaboration among
domain experts and knowledge engineers. 2004.
Considering model transformations, a next step corresponds to [4] OMG SysML, (n.d.). http://www.omgsysml.org/.
the elaboration of transformations from the SysML configuration [5] J. Lu, G. Wang, J. Ma, D. Kiritsis, H. Zhang, M. Törngren, General
model to different problem-solving domains such as CSP or Modeling Language to Support Model‐based Systems Engineering
Boolean satisfiability problem [8]. In this context, future work also Formalisms (Part 1), INCOSE Int. Symp. 30 (2020) 323–338.
needs to address the comprehensiveness of the proposed method https://doi.org/10.1002/j.2334-5837.2020.00725.x.
for formalization of configuration models based on additional [6] Object Management Group, UML, UML - Unified Model. Lang.
examples from engineering industry as well as the integration of (n.d.). https://www.omg.org/spec/UML/About-UML/.
means to facilitate knowledge base debugging [37]. Regarding the
[7] L. Hvam, N.H. Mortensen, J. Riis, Product customization, Springer,
latter, a key challenge is to establish a link the two representations,
Berlin, 2008.
so that identified faulty constraints within the computational model
can be correctly modified within the SysML model. Finally, future [8] L. Hotz, A. Felfernig, M. Stumptner, A. Ryabokon, C. Bagley, K.
work should investigate the extension of the proposed modelling Wolter, Configuration Knowledge Representation and Reasoning,
techniques so to enable knowledge formalization for design in: Knowl.-Based Config., Elsevier, 2014: pp. 41–72. (2015).
[9] K. Kristjansdottir, S. Shafiee, L. Hvam, C. Forza, N.H. Mortensen, [23] B. Kruse, A Library-based Concept Design Approach for Multi-
The main challenges for manufacturing companies in implementing Disciplinary Systems in SysML, Dissertation, ETH Zürich, 2016.
and utilizing configurators, Comput. Ind. 100 (2018) 196–211. [24] P. Klein, J. Lützenberger, K.-D. Thoben, A Proposal for
https://doi.org/10.1016/j.compind.2018.05.001. Knowledge Formailization in Product Development Processes, in:
[10] M. Asrar-ul-Haq, S. Anwar, A systematic review of knowledge Proc. Int. Conf. Eng. Des. ICED15, Design Society, Milano, Italy,
management and knowledge sharing: Trends, issues, and 2015: pp. 261–272.
challenges, Cogent Bus. Manag. 3 (2016). [25] S. Wölkl, Model Libraries for Conceptual Design, Dissertation, TU
https://doi.org/10.1080/23311975.2015.1127744. München, (2012).
[11] A. Felfernig, G.E. Friedrich, D. Jannach, UML AS DOMAIN [26] A.A. Shah, C.J.J. Paredis, R. Burkhart, D. Schaefer, Combining
SPECIFIC LANGUAGE FOR THE CONSTRUCTION OF Mathematical Programming and SysML for Automated Component
KNOWLEDGE-BASED CONFIGURATION SYSTEMS, Int. J. Sizing of Hydraulic Systems, J. Comput. Inf. Sci. Eng. 12 (2012)
Softw. Eng. Knowl. Eng. 10 (2000) 449–469. https://doi.org/10.1115/1.4007764.
https://doi.org/10.1142/S0218194000000249. [27] R.S. Peak, R.M. Burkhart, S.A. Friedenthal, M.W. Wilson, M.
[12] S. Florian, S. Lea-Nadine, K. Dieter, MBSE-basierte Bajaj, I. Kim, Simulation-Based Design Using SysML Part 1: A
Produktkonfiguratoren zur Analyse der Modularisierung bei der Parametrics Primer, in: INCOSE Int. Symp., Wiley Online Library,
Entwicklung modularer Baukastensysteme, in: R.H. Stelzer, J. San Diego, California, 2007: pp. 1516–1535.
Krzyzwinski (Eds.), Entwerf. Entwick. Erleb. Produktentwicklung http://onlinelibrary.wiley.com/doi/10.1002/j.2334-
Des. 2019 Band 2, TUDpress, Dresden, 2019: pp. 55–70. 5837.2007.tb02964.x
[13] M. Brambilla, J. Cabot, M. Wimmer, Model-Driven Software [28] R.S. Peak, R.M. Burkhart, S.A. Friedenthal, M.W. Wilson, M.
Engineering in Practice: Second Edition, Synth. Lect. Softw. Eng. 3 Bajaj, I. Kim, Simulation-Based Design Using SysML Part 2:
(2017) 1–207. Celebrating Diversity by Example, in: INCOSE Int. Symp., Wiley
https://doi.org/10.2200/S00751ED2V01Y201701SWE004. Online Library, San Diego, California, 2007: pp. 1536–1557.
[14] S.K. Chandrasegaran, K. Ramani, R.D. Sriram, I. Horváth, A. http://onlinelibrary.wiley.com/doi/10.1002/j.2334-
Bernard, R.F. Harik, W. Gao, The evolution, challenges, and future 5837.2007.tb02965.x
of knowledge representation in product design systems, Comput.- [29] C. Bock, R. Barbau, I. Matei, M. Dadfarnia, An Extension of the
Aided Des. 45 (2013) 204–228. Systems Modeling Language for Physical Interaction and Signal
https://doi.org/10.1016/j.cad.2012.08.006. Flow Simulation, Syst. Eng. 20 (2017) 395–431.
[15] Verein Deutscher Ingenieure, VDI 5610 - Blatt 1 - https://doi.org/10.1002/sys.21380.
Wissensmanagement im Ingenieurswesen - Grundlagen, Konzepte, [30] E. Rigger, T. Stanković, K. Shea, Task Categorization for
Vorgehen, 2009. Identification of Design Automation Opportunities, J. Eng. Des.
[16] B.J. Hicks, S.J. Culley, R.D. Allen, G. Mullineux, A framework for (2018). https://doi.org/10.1080/09544828.2018.1448927.
the requirements of capturing, storing and reusing information and [31] C.L. Dym, R.E. Levitt, Knowledge-based systems in engineering,
knowledge in engineering design, Int. J. Inf. Manag. 22 (2002) McGraw-Hill, New York, (1991).
263–280. https://doi.org/10.1016/S0268-4012(02)00012-9. [32] H.P.L. Bruun, N.H. Mortensen, U. Harlou, M. Wörösch, M.
[17] J. Stjepandić, W.J.C. Verhagen, H. Liese, P. Bermell-Garcia, Proschowsky, PLM system support for modular product
Knowledge-Based Engineering, in: J. Stjepandić, N. Wognum, development, Comput. Ind. 67 (2015) 97–111.
W.J.C. Verhagen (Eds.), Concurr. Eng. 21st Century, Springer https://doi.org/10.1016/j.compind.2014.10.010.
International Publishing, Zürich, 2015: pp. 255–286. 10.1007/978- [33] T.R. Browning, Design Structure Matrix Extensions and
3-319-13776-6_10 (2015). Innovations: A Survey and New Opportunities, IEEE Trans. Eng.
[18] D. Baxter, J. Gao, K. Case, J. Harding, B. Young, S. Cochrane, S. Manag. 63 (2016) 27–52.
Dani, An engineering design knowledge reuse methodology using https://doi.org/10.1109/TEM.2015.2491283.
process modelling, Res. Eng. Des. 18 (2007) 37–48. [34] E. Hering, Entscheidungstabelle nach DIN 66241, in: Softw.-Eng.,
https://doi.org/10.1007/s00163-007-0028-8. Vieweg+Teubner Verlag, Wiesbaden, 1984: pp. 18–25.
[19] J.H. Panchal, M.G. Fernández, C.J.J. Paredis, J.K. Allen, F. https://doi.org/10.1007/978-3-322-86222-8_3.
Mistree, A Modular Decision-centric Approach for Reusable [35] A.M. Madni, M. Sievers, Model-based systems engineering:
Design Processes, Concurr. Eng. Res. Appl. 17 (2009) 5–19. Motivation, current status, and research opportunities, Syst. Eng. 21
https://doi.org/10.1177/1063293X09102251. (2018) 172–190. https://doi.org/10.1002/sys.21438.
[20] J. Tiihonen, A. Felfernig, An introduction to personalization and [36] S. Mittal, F. Frayman, Towards a Generic Model of Configuraton
mass customization, J. Intell. Inf. Syst. 49 (2017) 1–7. Tasks., in: IJCAI, Citeseer, (1989) pp. 1395–1401.
https://doi.org/10.1007/s10844-017-0465-4. [37] L.L. Zhang, Product configuration: a review of the state-of-the-art
[21] S. Friedenthal, R. Griego, M. Sampson, INCOSE model based and future research, Int. J. Prod. Res. 52 (2014) 6381–6398.
systems engineering (MBSE) initiative, in: INCOSE 2007 Symp., https://doi.org/10.1080/00207543.2014.942012.
2007. (2016).
[22] S. Friedenthal, A. Moore, R. Steiner, A practical guide to SysML:
the systems modeling language, Morgan Kaufmann, (2014).