**1. Introduction**

The title refers to modelling, implying the generation of what is often referred to as a digital twin, namely, a digital reproduction of a process' behaviour. The term "model" is used in very different contexts and, correspondingly, has many facets. However, people always model processes for a specific purpose, and most often, the main objective is to generate a simulation with given inputs and a specified process characteristic. Many applications use simulation as an inner loop, with the outer loop defining the main objective, such as optimisation. For example, process design seeks optimal process parameters and optimising control finds an input that optimises an objective. From this perspective, modelling naturally sits at the very front end of the overall process, associated with solving a simulation-related problem, which makes modelling a core activity; therefore, errors in the model are the most costly ones. Thus, it is a natural request to have a systematic approach to modelling that is safe in terms of generating structurally sound models.

We claim that chemical engineering lacks such a systematic model-building process. The closest we have is flowsheeting software which uses customised unit-operation building blocks as its base entities. Readers interested in the historical aspects are referred to [1]. These traditional modelling environments suffer from a couple of problems, which provides the motivation for seeking an alternative, new approach. Let us give a couple of observation-based reasons.

**Citation:** Preisig, H.A. Ontology-Based Process Modelling-with Examples of Physical Topologies. *Processes* **2021**, *9*, 592. https://doi.org/10.3390/pr9040592

Academic Editor: Luis Puigjaner

Received: 1 February 2021 Accepted: 22 March 2021 Published: 29 March 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

#### *1.1. Why We Need a Systematic Modelling Approach*

**Incompleteness:** Published models tend to be incomplete, in the sense that, usually, the authors do not provide all relevant information leading to the given input/output behaviour. As an example, the publication [2] describes a non-trivial decanting two-liquidphase reactor. On page two is a simple figure that shows the process schematically. On page three, one finds the mathematical model, which consists of eleven equations. It is left to the knowledgable reader to interpret these equations and determine which one describes which element in the process. If the exercise is used to analyse these equations, close to one hundred equations are obtained, which explain the nature of the description and assumptions in detail. The number of equations is somewhat puzzling, considering the low structural complexity, and a strong indication that the modeller hid many details or is not aware of them. The model is not particularly complex. It describes the reactor's contents as two lumped systems, each with component balances for five species, an energy balance for the two lumps together and a description of the reactor's holdup.

**Flowsheeting-balance closure:** Above, we mentioned flowsheeting. The typical supplier provides libraries, often designed for particular users, and thus subdiscipline-specific process units or component models. A model builder or composer then utilises the library to construct process models. Next, a solver kernel is attached, providing the implementation of the appropriate solution methods. Examples are gPROMS®, ASPEN® and UNISYM®. Within parts of the user community, it seems to be well known that these simulators do not guarantee the conserved quantities' closure, which represents a fundamental problem for most applications.

**Documentation:** Process-unit-oriented libraries document the unit's behaviour on the unit level. The details of the models are, therefore, mostly hidden. There is little detail on the actual implementation, as it is considered unnecessary information for the typical user. This information is seen as only relevant for the expert implementing the software module. The result of this is that the individual models are black boxes that provide input/output behaviour. Consequently, the software users must work on the corresponding level of insight; they do not have access to the lower modelling level, through either the code or the documentation.

#### *1.2. An Alternative*

The author's process modelling project ProMo takes an alternative route. While we also build the models using a set of building blocks, our basic model entities are below the unit-operation level. They are in the context of the model application on the smallest granularity level; we call them "basic entities". It is essential to acknowledge that these entity blocks are basic on a particular granularity level, with the granularity level depending on the intended application.

While macroscopic physics was the starting point, the concept has been expanded to other disciplines, including control and lower-scale physics, like molecular dynamics. The project constructs its building blocks only from the fundamental concepts defining discipline-basic entities. These entities form the foundation for the discipline-mechanistic construction of the models. The underlying philosophy is therefore reductionism. Since they are deductive, mechanistic models cannot necessarily adequately capture real-world behaviours; a practical modelling system must allow for both glass-box (white-box) models and holistic surrogates (black-box models).

**State-space representation:** The approach is state-space based. For macroscopic physical systems, the conserved quantities serve as the state. Consequently, any numerical method, primarily integration, closes the respective balance to the defined accuracy. We can thus always guarantee the closure of the fundamental quantities once the algorithm has converged.

**Implementation:** The definition space, namely, the part associated with defining the basic building blocks, is ontology-driven. Using ontologies at the front end of the definition process imposes a structure onto the process and yields overall consistency. On a more technical level, the equations are in the "pure" form, meaning neither the user nor the software performs any transformations or substitutions. Each equation appears only once in the code, in contrast to unit-operation-based modelling, where each module typically represents the complete model for the mimicked unit. All model-related code is centralised and appears only once. Any composite model uses indexing to refer to the block representations, which renders modelling a bookkeeping problem.

**Project Process Modelling ProMo's main objective:** The project, which we named ProMo, aims to construct an environment that steers the modelling process as tightly as possible, without imposing constraints, which we achieve by using an ontology. The domain-specific ontology defines the structure of the information underlying the models which will be constructed in the domain captured by the ontology. The construction of the ontology is thus essential for the project's software. The following section is devoted to defining the elements of the ontology.

**This paper:** The goal of the paper is to define the basis for the graphical representation of process models. In the first step, we discuss the reductionism-based approach, seeking a minimal set of entities that enable us to construct the models for a class of modelling domains. Next, we discuss an abstraction that allows us to extend the modelling beyond physical systems. An ontology tailored to specific application domains provides the fundamental structures for the behaviour description and represents the construction codes for complex models. Defining the entity behaviour in terms of mathematical equations, namely as input/output functions, and linking them to the graphical objects sets the stage for the graphical representation. The latter forms the basis of a graphical language, which we demonstrate the use of in a set of applications. The visual language is handy when discussing a paper-and-pencil model design, and it is also directly used in the ProMo model design tool.

We will leave out two main parts from ProMo. The first is the definition of the behaviour equations, which we will have to present on another occasion. The core is the definition of a formal language and the ability to compile it into different target codes [3]. The second is the generation of the actual simulation code, which is similarly technical in terms of computer science issues, including the realisation of the automatic generation of application interfaces and the semantic network for interoperability. Both sections are full of technical details, which are not relevant to the current exposition.
