KNOWLEDGE-BASED ENGINEERING IN THE CONTEXT OF RAILWAY DESIGN BY INTEGRATING BIM, BPMN, DMN AND THE METHODOLOGY FOR KNOWLEDGE-BASED ENGINEERING APPLICATIONS (MOKA)

SUMMARY: Designing railway infrastructure is a knowledge-intensive task. Although there are a number of mature design authoring systems available, their support for dynamically incorporating domain-specific engineering knowledge is very limited. At the same time, a standardized digital representation of railway engineering knowledge (such as building codes and best practice) does not exists. To overcome this deficiency, this paper proposes the use of Knowledge Based Engineering (KBE) to automate routine design tasks by considering multiple knowledge sources. In this scenario, KBE is used to support a Railway design authoring system. To ensure maximum transparency in the design of the developed KBE application, graphical ‘Business Process Model and Notation’ (BPMN) has been used in combination with ‘Decision Model and Notation’ (DMN) to formalize the underlying engineering knowledge. The KBE application has been developed according to the Methodology for Knowledge-Based Engineering Applications (MOKA). An evaluation of the BPMN/DMN approach shows that it meets up to 58% of the acceptance criteria found in the literature. In addition, BPMN and DMN can already be used in the early capture phase of MOKA and its workflows can be developed into an executable KBE application in the subsequent phases. The results of the test example discussed here show that time savings of up to 97.5% can be achieved in the execution of the KBE application.


INTRODUCTION
'Digital methods like building information modeling (BIM) offer considerable advantages in the construction industry over the conventional methods that still largely prevail in current practice' (Häußler et al., 2021). With conventional methods, we refer to workflows based on 2D drawings for design, handover to clients and production on site. This applies both to compliance checking, as shown by Häußler et al., as well as to the design of buildings and the associated model creation. Design authoring systems which support object-oriented workflows combined with an parametric modeling approach (also referred to as BIM modelers) are used widely for the design of built structures, see (Amadori et al., 2012;Camba et al., 2016;Rempling et al., 2019;Zou and Feng, 2020) . The systems on the market already support design engineers by providing component libraries that also define a certain building logic or interdependencies between components in the software, see also (AKG Software Consulting GmbH, 2021;Autodesk Inc., 2021;Bentley Systems Inc., 2021;CGS Labs, 2021;IB&T Software GmbH, 2021;ProVI GmbH, 2020). In the design of infrastructure, there are numerous such dependencies. The most important element is typically the alignment as nearly all other infrastructure facilities are aligned to it (Reifenhäuser et al., 2018). Railway design authoring systems therefore already provide a framework within which the designer or specialist engineer can work in the course of the design process.
The individual calculation and design steps are often based on knowledge that is already set out in standards and guidelines in the form of rules, see (Häußler et al., 2021). At present, however, the construction industry lacks standardized methods for digitally mapping existing knowledge in such a way that it is machine-readable, so that it can be evaluated and reused, compare (İlal and Günaydın, 2017). The extension of the standardized data model Industry Foundation Classes (IFC) by railway infrastructure objects (IFC rail) recently reached the candidate status (Jaud et al., 2020). While this standardized object-oriented description will provide a good basis for representing and exchanging railway facilities with rich semantics, it does not provide capabilities for representing and applying the knowledge required for designing them.
Especially the digital integration of different knowledge sources is where knowledge-based engineering (KBE) comes in (Stokes, 2001). KBE stands at the intersection of diverse fundamental disciplines, such as artificial intelligence (AI), CAD and computer programming (La Rocca, 2012). KBE systems can be applied to achieve a variety of goals, the most important of which is to increase efficiency by using automated systems for routine tasks, as described, for example, in (Stokes, 2001). 'Although various research approaches have been developed in the area of KBE since the 1980s, there is no uniform and universally applicable description for the industrial environment, with which a KBE application can be implemented and operated' (Verein Deutscher Ingenieure e.V., 2017). Häußler et al. present a promising approach to mapping guideline contents in a machine-readable form with the help of 'Business Process Model and Notation' (BPMN) in connection with 'Decision Model and Notation' (DMN) and demonstrate its use for code compliance checking. In this paper the extent to which BPMN and DMN can be used as basis for a KBE application is investigated.
The paper is structured as follows: Section 2 gives an overview of the state of the art with regard to the terms "knowledge" and "engineering", and proceeds to discuss KBE as a technological symbiosis of these two domains. Following on from this, the Methodology for Knowledge-Based Engineering Applications (MOKA), as well as BPMN and DMN are presented. Section 3 describes the methodology used in the present study and the separate MOKA phases: Identify, Justify, Capture, Formalize and Package. Finally, Section 4 presents its use in a case study.

STATE OF THE ART
KBE synthesizes aspects from the domains of "knowledge" and "engineering". Both are first discussed independently and KBE is presented afterwards.

Knowledge and knowledge management
ISO 30401:2018 defines knowledge as a 'human or organizational asset enabling effective decisions and action in context' (ISO 30401:2018(ISO 30401: , 2018. A common means of representing how knowledge arises is the DIKW hierarchy (Data, Information, Knowledge, Wisdom) as described in (Rowley, 2007) and depicted in the pyramid in Fig. 1. Information is created by processing and interpreting data. The processing and combination of information creates knowledge, which in turn results in wisdom (Rowley, 2007). Bellinger et al. define the terms as follows: 'Data represents a fact or statement of event without relation to other things. Information embodies the understanding of a relationship of some sort, possibly cause and effect. Knowledge represents a pattern that connects and generally provides a high level of predictability as to what is described or what will happen next.
Wisdom embodies more of an understanding of fundamental principles embodied within the knowledge that are essentially the basis for the knowledge being what it is. Wisdom is essentially systemic ' (Bellinger et al., 2004). (Data, Information, Knowledge, Wisdom) as described in (Rowley, 2007) According to Schreiber et al. (2018) the definitions of data, information and knowledge are widespread, as can be seen for example in Rezgui et al. (2010), Premkumar et al. (2014), Girodon et al. (2015) and Roth et al. (2010). From a philosophical point of view, the term "knowledge" is not as simple or clear-cut to define as Bolisani & Bratianu (2018), among others, have shown, but an epistemological study of the philosophical basis of knowledge is not relevant in the context of this paper. Rather, the observations made here are based on the interplay of data, information and knowledge, since there is consensus on this in the literature (Schreiber et al., 2018). In the literature there is only 'limited discussion of the nature of wisdom, and even less discussion of the organizational processes that contribute to the cultivation of wisdom' (Rowley, 2007), as also confirmed by Liew (2013).

FIG. 1: DIKW hierarchy
Aside from their terminological definition, Roth et al. describe knowledge in terms of type, character, form, location and knowledge quality. Fig. 2 shows relationship between the types of knowledge identified by Roth et al. and lists the different types of knowledge (explicit/implicit, structured/unstructured, etc.). (Roth et al., 2010) Storing knowledge and making it available is the subject of many studies. The works of Haller (2011), Premkumar et al. (2014, Girodon et al. (2015), Cheng et al. (2012), Wu et al. (2012) as well as research on the topic of "Design Structure Matrices" (DSM) (Bhaskara, 2010;Tang et al., 2010) are examples of this. A DSM can help clarify dependencies, connections and interfaces of system elements. The integration of knowledge management and BIM is the subject of the investigations of Liu et al. (2013). Chassiakos et al. describe an approach of using a knowledgebased system (KBS) for the maintenance of bridge structures (Chassiakos et al., 2005).

Engineering design process
Alongside the concept of knowledge, it is important to understand how engineering and the associated design process works. According to Ertas, design can be investigative, creative, rational (logic-based) or decisionoriented (value-based) (Ertas, 2018). According to Calkins et al. the design of a product is 'an ordered set of steps that are performed to accomplish a task. The design of a product traditionally proceeds through a series of welldefined stages or phases including:' (Calkins et al., 2000).
conceptual design (concept exploration and development) preliminary design detail design (production design) The design process of products is a gradual and iterative process within which different participants solve different tasks and design individual components of the product (Obergriesser and Borrmann, 2012).

KBE
The preceding sections discussed knowledge and the engineering design process independently of one another and placed them in the context of this study. KBE links the two domains and can be used to automate the routine parts of the work steps. 'A prevalent definition of KBE emphasizes "the capture and systematic reuse of the product and process engineering knowledge" to automate "repetitive and non-creative design tasks" and to support "multidisciplinary design optimization in all phases of the design process"' (La Rocca, 2012;Zhao et al., 2015). La Rocca states that 'Knowledge-based engineering (KBE) is a technology based on the use of dedicated software tools called KBE systems, which are able to capture and systematically reuse product and process engineering knowledge, with the final goal of reducing the time and costs of product development', see also (Stokes, 2001). In contrast to KBS, as used in the context of KM, KBE applications have the capacity to influence the geometries of a design, see also (La Rocca, 2012;Stokes, 2001). 'The basic objectives that have to be supported by KBE are: solve a particular design problem using a KBE application (short-term), and retain the domain knowledge required for solving design problems in the same domain (long-term)' (Bermell-García and Fan, 2002).
According to La Rocca and Cooper et al. KBE systems have "generative" and "integrated" modelling capabilities (see Fig. 3), which means that 'a set of input values is assigned to the parameters that are used in the product model, the KBE system applies the rules to process the input values and, finally, the engineered design is generated, with little or no human intervention' (La Rocca, 2012). 'A generative model differs from a geometric model, which is a typical output of advanced CAD systems. Where a geometric model is a model of a designed product with fixed features (dimensions and configuration), a generative model is a generic representation of the product. The generative model […] is built on the basis of a geometric model and is enhanced by the engineering rules that determine its design' (Skarka, 2007). KBE systems can either be integrated directly into a design authoring system or be kept separate from the design authoring system and coupled via interfaces, as shown in Fig. 4. There are numerous practical examples of the development of KBE applications. These range from KBE systems in the field of aerospace (Bermell-Garcia et al., 2012;Corallo et al., 2009;Steenhuizen and Van Tooren, 2012) or aerodynamics (Bermell-García and Fan, 2002;Chiciudean et al., 2008), for cost estimation (Yildiz et al., 2014;Zhao et al., 2015), building design (Singhaputtangkul et al., 2013), building operation (Dibley et al., 2011;Motamedi et al., 2014;Motawa and Almarshad, 2013), building analysis (Kim et al., 2013;Wang and Leite, 2016), sustainability (König et al., 2013), safety planning (Zhang et al., 2015), structural design (Cavieres et al., 2011;Rempling et al., 2019) and bridge modelling (Flurl et al., 2015;Sandberg et al., 2016;Singer, 2014;Singer et al., 2016;Singer and Borrmann, 2015). Johansson et al. present an approach to representing the knowledge contained in a KBE application using graph theory (Johansson et al., 2018;Vilgertshofer and Borrmann, 2017 According to Sainter et al., many of these long-term problems can be mitigated using standardized development and management methods, languages and frameworks (Phillip Sainter et al., 2000).
According to La Rocca (2012) and Tripathi (2011) KBE systems are also referred to as expert systems. Tripathi defines the components of a KBE system as follows (see also Fig. 5): 'A rule-based expert system contains a knowledge base, inference engine, knowledge acquisition, explanation facility and user interface' (Tripathi, 2011).

MOKA
MOKA was developed to reduce the risks and investment costs associated with the development of KBE systems (Stokes, 2001). The method is a modular system consisting of six steps, as shown in Fig. 6. (Stokes, 2001) The contents of the individual steps are described in detail by Stokes. In this paper the focus lies on "Identify", "Justify", "Capture", "Formalize" and "Package".

FIG. 6: The KBE lifecycle
MOKA provides a method for collecting and structuring knowledge from different sources (Capture) and transferring it step by step into a formal representation (Formalize), so that a KBE application can be developed from it (Package), as illustrated in Fig. 7. The methodology also indirectly supports communications between the active participants (e.g. expert, knowledge engineer, software developer). Through its generic approach, the modules of the MOKA process, such as notations or forms of presentation, can be exchanged or supplemented by equivalent elements if necessary. (Stokes, 2001) MOKA is used in numerous studies as a method for the development of KBE applications. There are examples in aerospace (Emberey et al., 2007), mechanical engineering (Hunter et al., 2006) and architecture (Montali et al., 2019(Montali et al., , 2017, and MOKA is also used in connection with inspection and manufacturing (Álvarez et al., 2010;Barreiro et al., 2009;Martínez et al., 2012). In certain fields of application, MOKA has gaps, which have been identified in various investigations and closed by domain-specific extensions, for example for the automated planning of processes as MOKA understands a product model as a physical object (Ammar-Khodja et al., 2008;Helgoson and Kalhori, 2012). Chan has extended the method to develop simulation workflows automatically with the help of KBE mechanisms (Chan, 2013). Skarka has used Protégé to develop knowledge ontologies based on MOKA, see (Skarka, 2007(Skarka, , 2006. Due to the use of MOKA in aerospace and mechanical engineering, Dassault CATIA is often used as a software package for developing KBE applications using MOKA, see (Lohith et al., 2013;Skarka, 2007;Zheng et al., 2012).

FIG. 7: Assessment of the informal and formal model of human readability and computer processability
Sandberg has examined literature in the field of KBE, MOKA and construction and concluded that while individual MOKA phases are adopted, concrete details on their implementation are usually lacking: "[…] Design automation research focuses too much on the application itself rather than describing the way the application was developed" (Sandberg, 2015). Among other things, the definition of acceptance criteria for the successful implementation of a KBE application is criticized. With the help of acceptance criteria the success or failure of the KBE application shall be judged (Stokes, 2001).
The literature research revealed that the MOKA method is often used to develop KBE applications, but the examples were predominantly hard-coded "black box" solutions. MOKA aims to minimize the language barriers between Experts, Knowledge Engineers and Software Developers, but MOKA focusses only up to the formal model and describes these steps detailed. The package and activation step is not in focus of MOKA (Stokes, 2001).
For the present study, the advantages of the basic principles (collecting and structuring knowledge) of MOKA outweigh the disadvantages (need for domain-specific extensions). The literature research shows that MOKA is generic and extensible, which means that the disadvantages of pure MOKA are manageable. MOKA is therefore elected to be used but instead of developing a "black box" solution, an approach based on a graphical notation is employed, as described in the next section.

BPMN and DMN
A primary objective of the MOKA method is the creation of the formal model, consisting of a product and activity model. Stokes recommends the Unified Modeling Language (UML) for the development of product models and the corresponding UML activity diagrams for the design process model (Stokes, 2001). The focus of this research lies on the presentation of the design process model. MOKA does not detail the transfer of the formal model into an executable KBE application in any detail and only recommends converting the formal model into a neutral data format such as Extensible Markup Language (XML) to standardize the transformation process. In contrast to the MOKA recommendation, this study instead looks at how BPMN can be used in place of UML activity diagrams.
'An activity diagram is a UML behavior diagram which shows flow of control or object flow with emphasis on the sequence and conditions of the flow. The actions coordinated by activity models can be initiated by other actions finishing execution, by objects and data becoming available, or by the occurrence of some event external to the flow' (UML Activity Diagrams, 2020).
Alongside the UML activity diagrams, workflows can also be formally represented with the help of the BPMN. BPMN is an international standard (ISO/IEC 19510) that is maintained by the Object Management Group (ISO/IEC 19510:2013. Recker et al. describe BPMN as a '[…] structured, coherent and consistent way of understanding, documenting, modeling, analyzing, simulating, executing, and continuously changing end-to-end business processes and all involved resources in light of their contribution to business performance' (Recker et al., 2006). 'BPMN gained popularity because it is a standardized graphical notation, adopted by the Object Management Group (OMG), and it is easy to understand, also for non-IT experts. Since version 2.0, BPMN also includes execution semantics and a standardized XML-based syntax' (Chan, 2013).
Chan compares various process modelling languages and evaluates them in the categories 'graphical notation', 'designed for execution', 'standardized', 'widely adopted' and 'easy to use' (see also Table 1). Chan's results show that BPMN is better suited than UML activity diagrams due to the ability to make workflows executable with the help of a corresponding workflow engine. A workflow engine 'performs the process step by step in accordance with the modelled logic and can react to events during runtime as well as trigger events itself. Such an event might be a data input by the user, the calculation of mathematical formulae, a decision resulting from an if-then condition, or the execution of text-based source code. By virtue of its ability to automate the developed processes by means of a workflow engine, BPMN can be classified as belonging to the category of visual programming languages' (Häußler et al., 2021). In practice, however, Chan only uses BPMN for visualizing the workflow but does not make it executable.
BPMN can be used in many ways. Recker states that '"classical" process management applications such as documentation, redesign, continuous improvement and knowledge management dominate the application areas of BPMN, while more technical application areas such as software development, workflow management or process simulation are not (yet) widespread' (Recker, 2010). In the AEC industry, BPMN is used for the development of IDMs (Aram and Eastman, 2010; Obergriesser and Borrmann, 2012;Weise et al., 2008), which is also recommended by (ISO 29481-1:2016(ISO 29481-1: , 2016. Alreshidi combined UML diagrams with BPMN workflows to develop a cloud platform (Alreshidi et al., 2016). Dimyadi et al. and Häußler et al. used BPMN with corresponding workflow engines to verify building data models in the context of code compliance checking (Dimyadi et al., 2016(Dimyadi et al., , 2014Dimyadi and Amor, 2017;Häußler et al., 2021).
It is specifically the executability of BPNM workflows that set them apart from other methods, as Borrmann et al. confirm: 'In particular, the option to use BPMN in the context of workflow management systems as an implementation language […] is an important criterion for use in construction projects' (Borrmann et al., 2017a). 'The most frequently used BPMN elements for representing business processes in the AEC industry were sequence flow, pool, lane, task/activity (exclusive), gateway, and message flow, which are all basic BPMN modelling elements' (Park et al., 2011). A graphical representation of the individual elements is shown in Fig. 8. As discussed in Section 2.3, KBE applications must have the capacity to support decisions or even make decisions independently. To this end, DMN augments BPMN. 'The primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes, and finally, to the business people who will manage and monitor those decisions. DMN creates a standardized bridge for the gap between the business decision design and decision implementation. DMN notation is designed to be usable alongside the standard BPMN business process notation' (Object Management Group, 2019). With the help of Decision Engines (comparable with Workflow Engines) DMN decision tables can be made executable. Through the integration of DMN decision tables in BPMN workflows, decision paths can be incorporated directly into the workflow engine, see also (Häußler et al., 2021).
With the help of BPMN and DMN, knowledge, processes and associated decision paths can be represented graphically and thus made more readily understandable than in text-based languages. The special feature of both notations compared to UML is their executability. Compared to MOKA, where the formal model, once complete, has to be manually translated into a specific KBE language by a software engineer, BPMN and DMN do not require any further translation or transformation into text-based code. Instead, the graphical notation can be used directly to develop the informal model in order to visualize process sequences. In the course of developing the formal model, and ultimately also the KBE application itself, the first draft can be developed further without having to switch between different forms of presentation.

Designing in track construction
The aim of this study is to automate design steps in the field of rail infrastructure design with the help of KBE. The focus lies on design of new buildings. According to Borrmann et al., a fundamental distinction must be made between explicit and implicit modelling when creating three-dimensional models. 'Explicit modelling, […] describes a volume in terms of its surface […]. Implicit modelling by contrast employs a sequence of construction steps to describe a volumetric body, and is therefore commonly termed a procedural approach' (Borrmann et al., 2017b). Of particular relevance for this study is parametric modelling, which Borrmann et al. describes as a possible implicit approach. 'Feature-based parametric CAD is currently the industry standard technology to create geometric models and assemblies, and is widely used across many engineering fields' (Camba et al., 2016). The importance of parametric modelling is also described by Tang et al. (2020), Brown et al. (2020) and Zou & Feng (2020).
For this research the term "design authoring system" is used as a synonym for software which provides capabilities for the object-oriented and parametric design of geometric models in context of railway infrastructure facilities.
The term BIM is used as a synonym for the object-oriented workflow during the building lifecycle, it is not considered as a specific software product. The tools used for this research are presented in Section 3.5.
The definition of the parametric 3D-model in software products like Civil 3D (Autodesk Inc., 2021), OpenRail Designer (Bentley Systems Inc., 2021), card_1 (IB&T Software GmbH, 2021), Vestra Rail (AKG Software Consulting GmbH, 2021), ProVI (ProVI GmbH, 2020) or Ferrovia (CGS Labs, 2021) is managed with the help of a 'drawing-oriented viewsplit into site plan, cross-section and elevation [see also Fig. 9]. This type of model is referred to as an implicit geometry description. With implicit models, the governing design parameters become significantly more accessible than with explicit models' (Häußler and Borrmann, 2020). The description of the design of railway infrastructure in the underlying guidelines is predominantly parameter-oriented (Häußler et al., 2021).
FIG. 9: Comparison of implicit and volumetric 3D models: while implicit models (drawing-oriented view) are used during the design process (parametric modeling), explicit models are used in the context of BIM-based analysis (Häußler and Borrmann, 2020).
'The procedural approach provides the user of the system with the possibility to easily modify an existing model by going back in the construction history and adapting the corresponding parameter […]' (Borrmann et al., 2014). This is a particular advantage in the context of KBE. For the automation of design steps, the use of a design authoring system which supports the parametric modeling approach is indispensable, as this offers the greatest degree of freedom compared to other modelling philosophies, especially explicit modelling.

METHODOLOGY
In this paper, a KBE application is developed based on the BPMN and DMN notations standardized by the OMG. The intention is to minimize the break that arises when developing an informal model into a finished KBE application using the MOKA method. BPMN and DMN are used not just to represent technical knowledge but also process flows graphically, making them transparent for those involved in development as well as for later users. The ability to make BPMN and DMN executable using a workflow engine makes this approach interesting for the development of KBE applications.
This section describes the following steps of the MOKA method: Identify, Justify, Capture, Formalize and Package.

Identify
This paper focuses on the development of a KBE application to support the design of new buildings along railway infrastructure. The suitability of BPMN and DMN for representing guidelines in the railway design section was discussed in earlier work by Häußler et al. which concluded that up to 68 % of the examined rules can be digitally mapped using BPMN and DMN. A commercially available Design authoring system was used, and the KBE application aims to support the work steps of an engineer using this specialist software.
The following key sources of knowledge can be identified: • Expert knowledge (human sources) • Contents of guidelines (documents) • Requirements and modes of operation of the computer application (computer files) The classified objectives for the development of a KBE system are as follows: • The structure of a KBE system is fulfilled (very important) • Use of a graphical notation to provide transparency (very important) • Use of a standardized development language (very important) • Combination of different knowledge sources is possible (important) • Combination with commercially available Design authoring systems, the KBE system generates parameters for the Design authoring system which is done usually by users (important) • The KBE system decreases design time and ensures design quality (important)

Justify
The lack of universal definitions for acceptance criteria has been criticized in the literature, most notably by Sandberg. Stokes recommends the definition of (acceptance) criteria to verify the success or failure of KBE systems. As a result, criteria are compiled and clustered for the successful implementation of KBE applications in the course of literature research. These were then used to evaluate the approach of a BPMN and DMN-based KBE system developed in this study. Taking the objectives of this work into account not all criteria are necessarily equally important, the criteria were additionally weighted. The criteria which meet the very important objectives are weighted three times, the important ones two times and the one which are non-important compared to the objectives are weighted with one.
The criteria, their weighting, the corresponding sources, comments and evaluation result are shown in Table 2.
The evaluation was carried out as follows: • Requirement not fulfilled "--" (2 minus points) • Requirement is not sufficiently met "-" (1 minus point) • Requirement is largely met "+" (1 plus point) • Requirement is fully met "++" (2 plus points) Provides user interface (Singer, 2014;Tripathi, 2011) Graphical representation and possibility to interact with webpages via interfaces ++ 3 Provides explanation facility (Singer, 2014;Tripathi, 2011) Graphical notation and reporting of process steps is possible A total of 31 evaluation criteria were identified in the course of literature research and have been applied to evaluate the approach tested in this paper. Comparing the evaluated score of 36 points against the maximum achievable score of 62 points, the approach discussed in this paper fulfils 58% of the requirements that are not weighted against each other. Taking into account the weighting of the criteria applied for this study, the BPMN/DMN approach in this study fulfils 73 % of the requirements, which can be considered a good value due to the large number of different requirements.

Capture
'The capture step involves the collection of raw knowledge and transforms it into the first level of MOKA representationthe Informal Model' (Stokes, 2001). After the sources of knowledge have been identified (see Section 3.1), the knowledge they contain must be compiled, analyzed and put into context. According to Roth et al. there are different types of knowledge. As described by Tripathi (2011) knowledge can be collected using various methods, for example using interview techniques, through text analyses, observation techniques and review techniques.
The types of knowledge were systematically examined with the help of interviews. Table 3 shows the structure of the interviews conducted on the respective knowledge types. Open, unstructured interviews were conducted with domain experts, but also with the software developers of the selected design authoring system. The suitability criteria of the domain experts are described in Section 4.2.
In addition to the results of the interviews, the interviewees provided additional documents that can be considered as further sources of knowledge.
The objective of the interviews with experts was to gather existing technical knowledge for the proposed KBE application. This includes methodological, normative and fact-based knowledge, but also knowledge from experience gained. No pre-existing documents could be provided for methodological knowledge as well as knowledge from experience. In order to make existing knowledge usable for the present study, a scenario for a designing task was developed and the experts were asked to explain the processing and solution path of this step by step. This explanation served as the basis for a first version of a BPMN diagram. The interviews with the software developers served to understand the software used. They provided insights into the methodical procedure during modelling, but also into the interfacing requirements for connecting the design authoring system to the proposed KBE application (operational knowledge).
The documents made available were then screened and analyzed, and the designing tasks to be solved with the help of KBE were extracted and grouped into knowledge types. Most of the guidelines examined describe the "know-why" and "know-what" while the documents for the Design authoring system describe the operational knowledge.
Based on the steps performed, one can state that the design of railway infrastructure and its associated structures is very strongly parameter-oriented and that numerous geometric dependencies (vertical distance, horizontal distance, height, length, etc.) exist between the individual component and/structures, see also (Häußler et al., 2021). The most important basis for the design is the alignment, which serves as the defining element for all associated structures. To determine the dependencies between components and assemblies, DSM were developed in conjunction with the experts.
An essential aspect for structuring the collected knowledge is the so-called ICARE forms (Illustrations, Constraints, Activities, Rules and Entities) in MOKA (see Fig. 10). These can be used to represent the informal model. All the information for proceeding forward towards the KBE application is thus available. In the study, special attention is paid to how the Design authoring system and the KBE system can be connected and which inputs and outputs are understood or will be generated.

Formalize
MOKA distinguishes in the formal model between "Product Model" and "Design Process Model". These are derived from the ICARE forms and both are intended to be represented with the help of UML diagrams. This means, however, that in the next "Package" step, the newly created formal model has to be translated into a KBE language because UML is not developed for direct execution. The Design authoring system used is already a domain-specific specialist application. The UML diagrams serves to visualize the underlying product model and as a basis from which to develop the KBE application. This study, however, focuses on automating the design steps, which can be represented by a "Design Process Model". This is created by the expert in the "Capture" phase and used and developed to support the transformation process from the informal to the formal model as well as to be transparent for the experts involved. To develop the process model, the contents of the ICARE forms are systematically transferred into BPMN and DMN. In a first step, the Activity forms are evaluated in combination with the created workflow diagrams. These contain links to the Rule and Entity forms. This procedure has been corroborated by Stokes (2001).
In the course of the expert interviews, numerous references to directives in the railway design sector were communicated. The requirements were documented and recorded in the ICARE forms. For the most part, these guidelines are only available in human-readable form and the requirements are presented in various forms, e.g. continuous text, graphics, tables and formulae, see also (Häußler et al., 2021;Preidel and Borrmann, 2015). To translate them into a machine-readable language, the RASE syntax (Requirement, Applies, Select, Exception) was used. This has been described comprehensively by Hjelseth & Nisbet (2011) and Häußler et al. also used it to translate the corresponding guidelines. This process has been adapted in the present study using the BPMN elements script task, parallel and exclusive gateway, sequence flows and DMN tasks. Sub-processes are used to visually summarize related activities. As far as multiple but similar activities are included, the sub-processes are designed so that they can be executed several times with the help of loop criteria.
Since the focus is the automation of the design process, it is important to depict not just the technical content of the knowledge sources, but also the methodical approach of the experts and the necessary procedure within the Design authoring system through the BPMN diagrams. An example BPMN diagram is shown in Fig. 11. (Häußler et al., 2021) The A (Activities) and R (Rules) forms contain appropriate information. The main objective of the KBE application is to process data from upstream processes in such a way that new data is generated through the execution of the KBE application which can then made available to subsequent processes (see Fig. 3). As the aim is to support the user, the interface of the KBE application has been kept to a minimum so that only native data of the Design authoring system is used. Although the interfaces are defined during the formalization process, they are not developed. This is the content of the "Package" step.

FIG. 11: BPMN-Process in the context of code compliance checking
The resulting "Design Process Model" was then shown to the experts for joint verification of correctness (see Section 4.3).
The advantage here is that no further steps are required to translate the created workflows and decision tables into a neutral data format such as XML, as these are already saved as XML data. As such, this step from MOKA is not required.

Package
In the "Package" step, the formal model is usually translated by a software developer into the programming language of the target platform. Ideally, the formal model saved as XML is used as a basis. Since BPMN and DMN are already designed as executable languages and are stored in XML format, no further translation is required. The package step is therefore used to test the functionality and interaction of the applications used. In particular, the definition of variables is validated and adjusted if necessary.
In addition, a web-based user interface was developed as a direct connection to the KBE system along with the necessary interfaces to the Design authoring system.
The individual components of a KBE application were described earlier in Section 2.3. In our case, the following software components were used (see also User interface: ProVI 6.2 (ProVI GmbH, 2020) and webpage (interface to KBE system)

FIG. 12: Software configuration
The communication between the user interface and the KBE system running on a server is facilitated by a Rest API.

Identify and Justify
A key aspect in the design of railway facilities is to reduce the noise produced by rail traffic (Beier et al., n.d.; Deutsche Bahn AG, 2020), for example by erecting noise barriers alongside railway lines. The construction and the individual components of noise barriers are highly standardized, which lends itself towards automation of the design process. The KBE application proposed here as a case study is intended to support the geometric design of a noise barrier by automating the steps that are carried out manually. Existing automation steps already available in specialist applications do not need to be replicated. For example, the specialist app already models the noise barrier as a parametric model so that the KBE application only needs to determine the required input parameters. The KBE applications should nevertheless be generic enough so that different variants of the same noise barrier can be generated, but also different noise barriers for different projects and project areas.
The software configuration has already been described in Section 3.5, and the acceptance criteria for this study were evaluated in Section 3.2. The evaluation discussed there applies unchanged for the specific task at hand.

Capture
For knowledge acquisition, five domain experts from different companies were consulted in order to ensure a cross-company approach. The domain experts have more than 5 years of professional experience and are classified as senior engineers in their companies. In addition, a software developer of the Design authoring system employed was interviewed for the capture phase.
The interviews took between two and three hours per domain expert (only one expert per interview). The experts were asked to explain their design workflow without any interposed question first to get an unaffected description. The experts described the constraints in design, used input data and desired outcome. All of the experts use the same Design authoring system and expressed that no comparable system for the design of noise barriers is known to them. The parametric logic of a noise barrier was described as well as the interdependency to other facilities along railway tracks. In a second step, the idea of a KBE system was introduced by the knowledge engineer and the experts were asked which part of the design process is worth to automate. The experts provided different documents concerning the design of noise barriers. For this study the same Design authoring system was used as the one indicated by the domain experts. The interview with the software developer focused on the operation of the Design authoring system, provided interfaces were discussed as well as possible extensions for the software.
Based on the interviews, the relevant guidelines were reviewed.
Various disciplines are involved in the design of a noise barrier, such as sound calculations, structural analysis and geometric design. The interviews showed that the result of noise calculations is a key input variable for the geometric design of noise barriers. The calculation is carried out by environmental engineers using specialized software and essentially provides information on the height and length of a noise barrier. The structural analysis is a downstream process for the geometric design of the noise barrier and is carried out by structural engineers.
The aim of the test case outlined here is to support the design engineers in the routine tasks of geometric design.
The main results of the knowledge acquisition are summarized below. A noise barrier consists of four main components: post (1), wall element (2), base (3) and foundation (4), as shown in Fig. 13. In addition, the noise barrier is dependent on various input variables. The distance from the front edge of the noise barrier relates to the alignment of the track as set out in Deutsche Bahn guideline 800.0130 (DB Netz AG, 2018). An explanation is given in Section 4.3.2.

FIG. 13: Design of a noise barrier
Various structures exist along railway tracks that influence the design of noise barriers. These include drainage, underground cable conduits, overhead line systems and components for signaling and safety technology, as shown in Fig. 14 situation 1. These can obstruct the continuous construction of a noise barrier parallel to the track (Fig. 14 situation 2). Table 4 shows the interdependencies at the level of the installation in the form of a DSM. For all the subsections considered, the alignment therefore serves as an input variable, and for the noise barrier in particular, the subsections listed are likewise input variables. The design of a noise barrier must therefore be able to respond flexibly to other subsections by means of so-called by-passes that avoid collisions with installations from other subsections. Fig. 14 situation 3 shows how that noise barrier steps back to avoid colliding with a catenary mast and manhole.  The Design authoring system can work with parametric model data in software-specific formats for alignment as well as for the installation of overhead line and drainage systems. For formalizing the informal model, the approach discussed here is limited to the consideration of catenary masts and manholes.
A methodical description of the procedure was developed in cooperation with the experts as a draft BPMN workflow shown in Fig. 15. The design engineer begins by evaluating the route alignment, checking the constraint points and the distance of the noise barrier from the parallel track lines. In a second step, the engineer checks the structural data of the influencing subsections (here: overhead line and drainage), determines the positions of the overhead line masts and manholes, and plans any necessary by-passes at these points. Since these work steps have to be carried out repeatedly for numerous instances of these objects, the tasks must be conceived as a loop.

FIG. 15: BPMN workflow of the design process of a noise barrier, created by an expert
This workflow serves as a basis for the Activity forms, of which the "distance of a noise barrier" is shown in Table  5 by way of example. In this study, the combination of standardized forms and the process-related representation using BPMN proved to be helpful as a means of facilitating communication between the participants.

Output
List of parameters with noise barrier distance at each alignment element

Potential failure modes
Needed data is incomplete

Objective
Designing the distance of a noise barrier

Input requirements
Input data from design authoring system must include information about: station, radius, cant, pace, number of tracks, side of noise barrier

Context, information, validity Description
This activity aims to describe the import data for alignment.

Formalize
The ICARE forms created above, along with the outline workflow are developed in greater detail in the MOKA "Formalize" step. First, the product model is designed as a UML diagram. Two sub-processes are derived from the workflow, both of which are based on the alignment data of the project, but can also be viewed one after the other, as per the methodical procedure of the experts as well as within the Design authoring system. The subprocesses "Determining the distance" and "Defining the by-passes" are described in the following sections.

Product model
The product model of a noise barrier was developed as a UML diagram, shown in Fig. 16. The UML diagram shows the structural design of a noise barrier and its individual components (as per Fig. 13) and assigns attributes to the classes that need to be considered when designing a noise barrier. To clarify the origin of the data, the attributes are given a color. In this paper, the focus lies on the components relevant for the geometric design and their parameters, which are shown in red.

Design process model: Definition of distance to track
The most important input variable for determining the distance of a noise barrier to the track is the track alignment. The relevant reference object for determining the position is the axis which is comprised of straight line, circular arc and transition curve segments as shown in Fig. 17. Directive 800.0130 Annex 07 defines the necessary distance between noise barriers and track alignment axes, and this has already been recorded as a Rule form in the informal model. The table contained in the directive is evaluated as a decision table based on its structure and the clear definition of input and output variables, which makes it possible to formalize it as a DMN decision table shown in Table 6. This was used as basis for checking the design input data, e.g. to determine if the necessary input variables have been provided. The alignment data includes information on the cant and speed of the axis elements, but the number of tracks can only be specified by the user as there are no other data sources for this. A corresponding input interface was developed as part of the subsequent "Package" step. By using the Activity and Rule forms as well as the decision table, it became clear that a further key variable for automating the execution of the decision table was the position of the noise barrier in relation to the axis, e.g. on which side of the arc the noise barrier lies (left or right of the track). This, too, must be defined by the user. Fig. 18 shows the possible situations. A special case in this context are straight sections of track: these have no curvature and are thus not explicitly detailed in the guidelines. The interviews with experts revealed that these are typically treated as "inside arcs". As the route alignment data also contains information on the direction of curvature, the following distinction can be made: • Radius < 0 → left curved • Radius > 0 → right curved • Radius = 0 → not curved

FIG. 18: Relation of noise barrier (red, broken line) to arc element (black, continuous line)
These decision processes can be mapped using BPMN as shown in Fig. 19, where the numbers correspond to the different situations shown in Fig. 18. The DMN task "Define necessary distance" represents the decision table shown in Table 6 as a BPMN node.

Design process model: Definition of by-pass parameters
Alongside determining the distance between the noise barrier and the track alignment axis, the "Capture" phase and the DSM also made it clear that design of noise barriers is subordinate to other subsections such as the design of overhead lines or drainage. These must therefore also serve as input variables for the design of the noise barrier. The next step in the design of noise barriers is therefore to ensure it does not collide with existing installations along the railway line.
The logic of drainage systems means that the data provided by the Design authoring system includes the entire sewer network. Manholes do not necessarily have to collide with the noise barrier. The same also applies to catenary masts for overhead line design. The masts and drainage elements can be positioned on either side of the track and in some cases may not clash with the noise barrier at all. The first step is, therefore, to filter out only those objects that may influence the course of the noise barrier, i.e. those elements located on the same side of the tracks as the noise barrier (see Fig. 20).

FIG. 20: Sketch of a noise barrier with by-passes. Four situations are shown: 1) without obstacle, 2) collision with a manhole, 3) collision with a mast, 4) by-pass around several obstructions.
The next step is to check which of the filtered objects actually influence the design of the noise barrier and to what extent. The Design authoring system can provide the following parameters on manholes and catenary mast objects: • Object type • Station on the track • Distance of the center of the object to the track • Dimensions of the object (height, length, width, diameter etc.) The objects are initially considered independently of each other and it is assumed that each of the objects will result in a single by-pass segment in the noise barrier. The aim of the automation is to determine the length of the respective by-pass around the objects encountered. Catenary masts restrict the space available next to the tracks. The interviews with experts revealed that space must be left for the safe passage of maintenance personnel next to the tracks. The process must therefore determine whether the space between the mast and tracks is sufficient or whether service staff will need to pass behind the mast (see Fig. 20 situation 3). This can be determined with the help of a simple decision table (see Table 7) and requires only the "distance between track and the front edge of the catenary mast" as an input value. If this value is less than 3.3 m, the distance between the rear edge of the mast and the noise barrier must be at least 0.8 m, otherwise 0.5 m (the dimension "x" in Fig. 20 situation 3). In the case of the manhole, this is not relevant for the staff maintenance route as the manhole cover is at ground level and does not obstruct the path passing over it (see Fig. 20 situation 2). Section 4.3.2 describes how the distance of the noise barrier to the track axis is determined ( Fig. 20 situation 1). This is in relation to the main elements of the underlying track alignment. In addition to the determined position of the individual relevant objects and the regulatory information on the space to be kept free, the distances from the axis to the front edge of the noise barrier is calculated at each catenary mast or manhole using the same logic as described in Section 4.3.2. With this information, the necessary offset of the noise barrier around manholes and catenary masts can be determined. The corresponding section of the BPMN workflow is shown in Fig. 21.  Using the steps described, the data available from the implicit model was used to generate information and knowledge for the course of the noise barrier. The assumption up to now has been that each manhole or mast will result in an independent bypass. The next step is to determine whether several small by-passes can be combined to form a single larger by-pass (Fig. 20 situation 4), for example because geometrically expedient or for cost reasons. To this end, an additional script task was integrated into the process to identify the spatial proximity of different objects. This script task checks the distance between objects based on a maximum distance specified by the user. By varying this input variable, different variants of the same noise barrier can be generated. The requisite operators for this were combined in a single task to avoid a complex and incomprehensible BPMN diagram.
Preidel calls this form of representation the "atomic method" (Preidel, 2020). Once close-by objectsi.e. objects that can be combined in a single by-passhave been identified, the actual parameters of the by-pass can be determined in an independent sub-process. First, the mid-point of the by-pass is determined from the minimum and maximum station of the objects to be considered. Based on whether closed or open by-passes are to be designed (a user-specified input), additional parameters are determined for "length front" and "length rear". This enables the user to consider further variants. The corresponding section of the BPMN workflow is shown in Fig. 22.

FIG. 22: BPMN diagram for by-pass design Part II: Filter "close-by" objects, parameters of by-pass
The result of this process provides the parameters necessary for the design of by-passes. For this purpose, input data was processed, and new data, information and knowledge was generated. Data required for the Design authoring system can also be passed to it via corresponding interfaces.
Although in MOKA, the "Capture" and "Formalize" phases follow each other, the authors found that questions arising in the course of formalization can make it necessary to repeat individual steps of the capture phase. The authors therefore see these phases as being iterative.

Package
With the help of BPMN and DMN, the knowledge identified in the "Capture" phase could be digitally mapped in the "Formalize" phase. In this final step, automated systems need to be developed to extract relevant data from the underlying design input data, which is available as tabular data in text files. Since both the Design authoring system and the KBE system have a web interface, the programming language JavaScript can be used for data extraction.
As the workflow engine can also interpret JavaScript, the entire KBE application has a consistent programming language. The web-based user interface is shown in Fig. 23.
The user must first select the data sets to be evaluated and then define boundary conditions applicable to the process, such as the number of tracks, and on which side of the tracks the noise barrier is needed, as described earlier. The website allows the user to choose using simple select dropdowns. The BPMN process is also shown.

FIG. 23: Web-based user interface for choosing the data to submit to the KBE system (server-side) and setting additional user inputs via dropdowns (red). The BPNM process diagram is also displayed to the user (blue).
In addition, the generated process diagrams are extended in the "Package" step so that they can be executed by the workflow engine used. The variable definitions made need to be checked and adapted if necessary, and the generated data for passing back to the Design authoring system must be converted into the required Commaseparated values format (CSV). For each station (one line per axis element or by-pass) the corresponding parameters are arranged in a pre-defined column sequence. This data can be downloaded from the server by the user and imported back into the Design authoring system. Due to the lack of an API, it is not possible to connect the Design authoring system directly to the KBE application.
Over the course of developing the executable KBE application, one can also see that the "Formalize" and "Package" phases are also closely related and influence each other. This is primarily because using BPMN and DMN makes it possible to produce a consistent logic with an executable language so that the conditions for successful execution can already by determined during the "Formalize" phase. The interaction between the different phases is a positive characteristic in the authors' view. Fig. 24 shows the interrelationships of the "Capture", "Formalize" and "Package" phases of the MOKA method in the case study project.

Results
In this study, the aim was to use a uniform presentation form for the activity diagrams from the "Capture" to "Package" phases. As BPMN workflows in combination with DMN decision tables can be made executable by means of a workflow engine, this approach could be used for these phases of this study. The acceptance criteria outlined for this study in Section 3.2 were evaluated for the method used. One of the most important challenges in connection with KBE is that the automation of routine tasks should reduce the processing time and, in turn, production costs. To quantify these results, the processing times for the semi-automated (by using functionalities of the Design authoring system) design of a noise barrier were compared with the KBE-based approach. To determine the time required for semi-automated design, we assumed the user would use the same Design authoring system used in the KBE-based approach. The initial steps for generating input data are the same in both approaches and were therefore not compared. The following data was used as a basis for the design: -Route axis with a length of 2,700 m -Sewer system with 102 manholes -Catenary data with 21 catenary masts The noise barrier should extend the length of the railway track, i.e. also have a length of 2,700 m. Table 8 compares the times required to design a noise barrier semi-automated and with the help of the automated KBE approach. The processing steps compared correspond to the procedure described above and the semiautomated processing time are empirical values estimated by five domain experts. The experts came up with closeby estimates independently of each other. According to their estimates, the semi-automated design of the noise barrier takes about 145 min on average. These times are based on routine tasks only; special situations such as designing noise barrier that pass over a bridge structure, are not considered here. By comparison, the KBE-based approach is significantly faster, taking only 3 minutes 40 seconds, which corresponds to a ratio of 2.5 % of the time. Variants are correspondingly quicker to produce: the user can, for example, decide at the beginning of the process whether the noise barrier should be designed with open or closed by-passes. With the KBE-based approach, the "type of by-pass" selection can be adjusted accordingly, and the system determines the configuration within 3 minutes 20 seconds. A design engineer would require a further 40 minutes to adapt the previously created design. This corresponds to an approx. 92 % improvement in efficiency when developing variants or adjustments to the design.
The entire process of designing the executable KBE application from the "Capture" to the "Package" phase took about 4 weeks in the described example.

CONCLUSION
This paper has presented a study for a KBE system based on the graphical notation BPMN in combination with DMN. The development of the application followed the general principles of MOKA which is already well established in practice. MOKA aims to collect knowledge in different ways in successive phases and to transfer it from an initially unstructured form to a KBE system. A disadvantage of MOKA in the opinion of the authors is that there is no uniform notation. The results of each individual phase always need to be converted into a different data format for the next, i.e. from ICARE forms to UML diagrams and from UML diagrams to a KBE language.
The aim of this study was to use a consistently uniform presentation form for the activity diagrams. To this end, BPMN and DMN were used as two notations that can be used for the graphical representation of knowledge and are also executable with the help of an associated workflow and decision engine. The case study examined an application in the field of railway infrastructure design for new buildings. As part of the "Justify" phase, 31 acceptance criteria were compiled from the literature and the approach presented here was evaluated against them: the results show that the approach fulfils 58 % (unweighted) and 73 % (weighted) of the criteria. During the "Capture" phase, the available sources of knowledge (expert knowledge, guidelines, functionality of the applications used) were collected and structured with the help of ICARE forms, DSM and BPMN diagrams. In the next step, the informal model was formalized using methods described in earlier work by Häußler et al. to formalize the knowledge contained in guidelines with the help of BPMN and DMN. The methodical knowledge of the experts and the requirements of the specialized applications can likewise be formalized with the help of BPMN and DMN.
The case study examined the automation of the geometric design of a new noise barrier along railway tracks and demonstrates that BPMN and DMN can be applied consistently from the "Capture" phase to the actual KBE application. By automating the processing steps, the time required for the design of noise barriers under the given boundary conditions can be reduced many times over: in the case study, the KBE approach requires only 2.5 % of the time required for semi-automated design. The creation of different variants is also significantly faster when using automated processes. In the example shown, 8 % of the semi-automated processing time was required to develop an additional variant of an existing noise barrier design.
In addition to significantly shortening the required generation time, the approach developed here also demonstrates the graphical representation of different types of knowledge in connection with the process-based approach to the design of railway infrastructure facilities. The process is transparent, meaning that the KBE system is not a "black box" solution, which can in turn benefit user acceptance. In addition, the system can be adapted to meet different requirements.
Apart from these advantages, however, there are also some aspects that the approach presented here cannot solve, or only insufficiently address. The KBE application is developed as a system decoupled from the Design authoring system. This makes it necessary to develop appropriate interfaces for importing and exporting data, which may need to be updated as the Design authoring system is developed. Currently, the data must be actively transferred to the KBE solution by the user, which introduces a potential point of error. With the help of an API, the KBE system could in future be directly linked to the Design authoring system. This would also eliminate a further disadvantage: the user would not have to leave the Design authoring system and the result would be displayed in the Design authoring system without further action. In the current prototype, the approach is limited to the knowledge provided by the engineer and the routines devised by the developer. The system is not able to learn independently from the tasks set and find new solutions to problems. For highly standardized structuressuch as the example of the noise barrier -this approach is, in the authors' opinion, quite sufficient. But if more complex, highly specific solutions need to be developed, e.g. escape routes and emergency services access in dense innercity environments, or the fitting of railway platforms, this approach may currently be too limited.
The case study presented here is limited to the geometric design of new noise barriers. Future investigations should aim to develop cross-domain solutions. Using the noise barrier as an example, this would entail linking together sound calculations, structural analysis and geometric design. This could be achieved, for example, by triggering sophisticated calculation and simulation applications from a workflow or by modelling the calculations and decision paths using BPMN and DMN.
As the field of railway infrastructure design is particularly well defined by standards and regulations, the approach shown here offers very good and valuable support for routine tasks. Further fields of application could be the automated design of superstructures, underground cable routing, platforms and engineering structures such as bridges and tunnels. Applications are also conceivable in road construction, e.g. in the design of road cross sections (road superstructure, road widths). BPMN and DMN methods could also be used for the design of road junctions, though here stronger interaction with Design authoring system would be necessary.