1 Introduction

The Committee on Challenges for the Chemical Sciences in the 21st Century [1] indicates that the development of new and powerful computational methods, applicable from the atomic level to the chemical process and enterprise levels, is a key factor to enable multi-scale optimization. This would broaden the scope of one of the main objectives attained by the Process Systems Engineering (PSE) approach, focused on the systematization of the decision making through modeling and optimization, to a new generalized paradigm. In this line, Harjunkoski et al. [4] address the usage of standards to systematically build models and to be able to create a master model to configure new problems without modifying the algorithmic core, or Hooker [5] uses metaconstraints through the use of a pre-built library, in order to assist model builders in a constraint-programming framework. However, although the practical implementations based on these approaches introduce significant improvements during model building, these constraints are not connected conceptually to problems to be solved in the system and the complete model building for the integration problem is not investigated.

Therefore, this work investigates systematic model building procedures to address optimization problems from a multi-scale perspective and to automatically generate the problem instances according to the problem to be solved.

2 Analysis of Conceptual Constraints

The traditional modeling approach is based on the following steps: (i) analysis of the process, (ii) conceptual model of the process, (iii) mathematical representation of the problem, and (iv) iterative model improvements [8]. Usually, the model of the process is based on mathematical expressions related to fundamental laws such as balances, sequencing and allocation constraints. Then, other constraints according to the details of the problem are added; for instance: in short-term scheduling models, time constraints can be used to describe shifts or maintenance requirements [9]. Afterward, the constraints are detailed according to the model granularity (e.g.: the used time representation), the given data and other presented details of the requirements. Since these formulations are constructed specifically for a problem, they remain static with the given data structure and model construction, and can not be reused at different levels even within the same organization.

Fig. 1
figure 1

Proposed modeling approach

Full size image

In order to overcome these limitations, it is proposed to aggregate the abstract information related to a common concept, to be used at different hierarchical levels to create a Conceptual Constraint (CC) Domain. Then, this CC Domain may be used to create upper level relations and may be connected with different sets of data available in the production system in the PSE Domain. Figure 1 shows the connections between two domains with the CurrentlyAvailableMaterialFootnote 1 example. The CurrentlyAvailableMaterial concept is part of the MaterialBalance CC and it has different instance connections which link the CC Domain to the PSE Domain. An illustrative example of the MaterialBalance CC and these connections are given in Sect. 3 showing these connections.

Based on this idea, the proposed modeling approach exploits the CC to formulate the problem at a higher (more generic) level, which is dynamically connected to the data in the PSE Domain. CCs actually represent the main principles of the technological system (like, for example, the material balances—Fig. 2). Then, to create the problem instance to be solved, the elements used to represent this main principle (following the same example, the CurrentlyAvailableMaterial are connected to ProcessInput and ProcessOutput concepts, which are part of the Identification concept in the PSE Domain. These concepts are gathered as Identification concept since ProcessInput is defined as an identification of materials, energy, or other resources required for a recipe.

There are two main aspects to be emphasized in this new way to approach the model construction. The first one is related to the way how some knowledge is managed to identify where the inputs of the system are loaded into the ontological model [3]. The required systematic approach will typically imply the standardization of the information; in this work, the ISA proposals (ISA88 and ISA95 Standards) have been applied, so the models include the recipe, the procedural model, and the physical model. The resulting ontological model is represented by the PSE Domain in Fig. 1 (interested reader is referred to [2] for a detailed explanation). The second one is the constraint management associated to the connection of the two domains. The CC Domain elements construct the problem formulation considering the PSE Domain, and the suggested methodology simply implements the following steps: (i) ontological representation of the problem in the PSE Domain, (ii) selection from the CCs, (iii) model creation from the CCs and introduced data, and (iv) solution of the model.

Furthermore, the claim is that CCs are not only applicable to a certain hierarchical level (like strategic versus tactical level). The same concept appears at different levels with different information and assumptions. Therefore, this approach uses some generic concept connections in order to identify equivalences in different hierarchical levels. For instance, in the case of a material balance, depending on the available information, it can be constructed around a unit or a site and the process inputs and outputs will change, accordingly (Sect. 3).

Fig. 2
figure 2

Material balance from short-term scheduling formulations [6]

Full size image

3 Application: Material Balance Conceptual Constraint

Because of the space limitations, only the construction of one CC is detailed in this paper. The physical model is limited to units and sites. In order to explain CCs, three material balance equations are taken from the literature [6, 7]. The first constraint is given in Fig. 2, which belongs to a short-term scheduling formulation [6] and the other two equations, depicted in Fig. 3a, b, represent the material balance developed and used in a planning formulation [7].

Fig. 3
figure 3

Material balances from planning formulation

Full size image

In the figures, each element of the constraints is examined semantically and described in the attached text-boxes according to the corresponding nomenclature.Footnote 2

In the planning formulation [7], the material balance constraints for raw materials and products are created, separately. The first observation for the material balances in Fig. 3 is that this separation can be overcome using the recipe concept which is also known as state-task network representation [6]. When the planning [7] and the scheduling formulations [6] are compared, the variable related to the production uses different physical elements: sites and units, respectively. In order to integrate different levels, differentiation of the physical and procedural models are required, which is partially given in ISA88 Batch Control Standard and applicable to other operation modes.

Combining the three examined equations gives the general view of the elements in the material balance CC. This general view contains the intermediate part of the constraint construction. Figure 4 summarizes the final generic mathematical equation instances and their connection to the elements in the material balance CC. The hierarchical conceptual relations of the constraint are given in Table 1. Relations in this paper are restricted to the Unit and Site levels in the hierarchy. While Fig. 2 has instances from the Unit to be used as set, equations in Fig. 3 have the Site concept instances. So, when a problem is required to be solved at Unit level, the same Conceptual Concept, depicted in Fig. 4, is applied at the Unit level. Also the Site concept instances are called when a problem at the Site level is required to be solved.

Fig. 4
figure 4

Material Balance CC and resulted mathematical expression

Full size image
Table 1 Nomenclature for the material balance CC:
Full size table

An additional example would be the CurrentlyAvailableMaterial concept, which is connected with an Identification concept to get the ProcessInput and the ProcessOutput for the identified level Fig. 1. In the case of the planning model, the Identification concept, which describes materials required for recipes, includes the SiteProcessSegmentInput (raw materials) and SiteProcessSegmentOutput (products) concepts. Then, the CurrentlyAvailableMaterial may become a function of

$$CurrentlyAvailableMaterial_{(Identification, PhysicalModel, Time)}$$

where the Identification refers to set of materials depending on the level. The PhysicalModel element includes the set of Unit or Site and the Time element adds the information related to the discretization (if the formulation is a discrete time).

4 Conclusions

This paper presents a methodology for building mathematical models from existing data using Conceptual Constraints (CCs). The aim of the study is to be able to comprehensively formulate and solve decision making problems from different points of view in a production system using a multi-scale generic approach. As a motivating example, the material balance has been selected to illustrate the use of a common CC at different decision-making levels. When some specific data-set related to the problem is selected, it is connected with the CC and the model structure is automatically generated from them. The proposed methodology is applicable to any system where a set of rules regulating the relations (connections) between the different sub-systems exists, provided that the information inside these systems is modeled accordingly. In the case of multi-level hierarchical systems, these relations are clear, previously identified and even standardized, so the application of the proposed methodology and the identification of the conceptual equivalences becomes evident; in the case of other systems, such as interwoven systems, systems of systems, etc., the relations may be more difficult to standardize for a generic case, although common concepts will also exist and might be exploited accordingly. As a result, and obviously accepting that there will be always constraints which are not practical or feasible to generalize, this methodology provides a basis for the systematic creation of models and, even more important, to ensure the coherence of the results obtained by different models operating at different hierarchical levels in a multi-scale system.