Decision-making in complex production environments is considered challenging as the information and knowledge requirements need to be observed constantly since the ecosystem they operate within is continuously changing. Artificial intelligence (AI) act as an infrastructure to tackle these needs and establish the flexibility required by decision makers. Such novel ways to support the decision makers are in scope of the work presented in this contribution, more specifically the Democratic AI-based Decision Support System (DAI-DSS) that is designed and implemented in the EU-funded FAIRWork project. Decentralization and democratization of decision processes are in scope, that considers on one hand the information needs of human actors and on the other hand formalisation requirements for technical actors / automation. The FAIRWork project proposes a model-based approach that builds upon existing modelling techniques to formally describe the decision processes and enriches those with AI services to elevate the utility during the creation and use of conceptual models.
European manufacturing companies are experiencing growing pressure due to the efects of
international competition. They have to act in global production ecosystems and proactively
adapt to changing circumstances on various levels (e.g. in the design of their supply chain
network, legal regulation, market needs, and novel production techniques). Integration of
advanced technological capabilities within the management of these production environments [
The increased complexity within the manufacturing domain impacts decision-making
processes as coordination mechanisms are required and a common understanding between the
involved actors is required. Decision support is evolving from a central, potentially hierarchical
organisation towards a decentralized [
To tackle these challenges, the Democratic AI-based Decision Support System (DAI-DSS) is designed and implemented within the EU-funded FAIRWork project. The FAIRWork project is a collaborative project within the Horizon Europe Programme involving eight project partners from six countries with an overall budget of around 3.4 MEUR.
DAI-DSS supports the configuration of domain-specific decision strategies supported by AI services, which can be applied on concrete decision problems during the design and operation of production processes.
As the project is running, this paper introduces the first results achieved and presents the
envisioned architecture. The development of the architecture is based on design thinking
workshops organized in collaboration with the industrial pilot partners in the project following the
approach of the OMiLAB Digital Innovation Environment (DIEn) [
The remainder of this paper is structured as follows: section 2 discusses related work and the theoretical background. Section 3 introduces the project context and idea as aspects for the DAIDSS. This section is followed by the introduction of the design procedure in section 4, resulting in a discussion of identified decision support challenges (see section 4.2). These challenges are input for designing the DAI-DSS, from the perspective of model-based alignment of decision problems (in section 5) to the proposal of the architecture of DAI-DSS (in section 6). The paper concludes by highlighting next steps in the realisation and the industrial evaluation of the result at FAIRWork partner FLEX and CRF.
Distributed decision-making is a process where the decision-making responsibility is distributed
across a group of individuals or agents instead of centralising it with a single agent or group [
Conceptual models can not only be used as mediators between machine-readable models
and human interpretable models but can also be used to connect high-level design models of
human experts with abstractions of runtime systems (e.g., using Cyber-Physical Systems, CPS),
as introduced in the approach of [10]. This approach implies that the mediation is not only on
the level of mapping and communication but that - assuming well-defined execution semantics
of the underlying metamodel - these models are also impact for run-time configuration. This
means that they bridge knowledge of creating business value with knowledge about digital
or physical twins. A prototyping environment in the context of product-service system is
presented and discussed in [
Digital Twins. Building upon the definition of digital shadows [ 18] and digital twins [19], in FAIRWork these concepts are understood from a knowledge and data representation perspective, specifically in the context of complex industrial processes. An adapted version of the definition and approach of [20] is relevant: • Digital shadow (DS) and digital twin (DT) exist for physical and virtual assets, i.e., objects that change their state over the lifecycle of the asset. • The digital shadow is defined as an assignment of status data to a specific asset at a certain point in time. • There is only one and no second digital shadow of an object, including and combining all relevant properties along the specific asset’s lifecycle. • The structure of digital twins is application-oriented and not universally valid. • In contrast to a digital shadow, the digital twin allows for an adaptation of the asset via the twin (bi-directional).
In the FAIRWork project, the concepts are applied via model-based techniques. Conceptual models as discussed above are considered digital shadows of the production environment, enhanced with historical operation data. Through model-processing techniques and abstraction/decomposition approaches, the digital twin comes into existence: based on the learning on model level, scenarios are developed and can be deployed on the production infrastructure directly.
As a manufacturing enterprise, it is not suficient anymore to only consider production time and costs in the production planning, but due to the evolution towards organisations that act in a global ecosystem, also environmental and social factors have to be considered. Through the EU-funded FAIRWork project, novel technologies are applied to tackle these challenges and improve the decision-making processes. These technologies can be used to gather and pre-process data, allow multiple actors to participate in the decision process, and use AI to enable identifying the solution space for complex problems. One result of the project is the Democratic AI-based Decision Support System (DAI-DSS), integrating diferent technologies to support decision makers. This section will discuss the influencing factors for the development of the DAI-DSS.
One goal for the DAI-DSS is the facilitation of democratic decision-making. Democratisation in this context means, that we focus on the participation aspect and do not delve into social or political aspects of democratization. We mean with participation that all involved stakeholders of a decision can contribute and are considered in the decision-making process. Consequently, participation-based democratization requires decentralized decision-making, where the involved stakeholders can contribute, in contrast to centralized decision making where a central person or small group makes the decisions on behalf of the organisation.
Decentralisation can be accomplished by directly involving the actors or by using agents representing the actors and acting on their behalf. Using agents allows for further support, as the agents can negotiate between themselves and find solutions benefiting the involved actors. Independent if a decision is made centrally or decentrally, information is needed as the foundation to define the decision process. Therefore, a knowledge base is needed which can save, ofer and manage data from diferent sources, encoded in diferent formats, and provides input in a static, dynamic or even real-time manner.
To increase the flexibility of a decision-support system, the need to adapt to new or changing decision problems is considered. The decision support system itself is designed modular to allow for a flexible combination of individual modules through configuration. A configuration in this context is a set of modules that are linked together and can be used to create a solution for a problem. To create such a configuration, it is important that humans can capture the knowledge and provide it in a way so that the decision support system can understand it.
The FAIRWork decision support system utilizes AI algorithms capable of a) understanding complex decision problems and b) providing feasible solutions as decision support. The goal is not to identify a single AI algorithm which can help with every decision problem but to ofer diferent implementations of AI algorithms within the decision support system, which can be configured in a domain-specific manner to help with concrete problems. The decision support system is capable to manage and control the diferent modules and make them work together. It orchestrates the modules (e.g., diferent implementations of AI algorithms, data from the knowledge base, input from involved stakeholders, etc.) to identify solutions to concrete decision problems.
An example of such a decision problem is allocating workers to production lines. Considering their qualifications or physical capabilities is essential and integrating them with their individual needs establishes the knowledge base to be considered (e.g., how often the worker has had to substitute for colleagues lately or how much experience the worker has with a specific production line). Another scenario in the project targets the support of choosing an alternative for a given decision problem. The most adequate solution may be a combination of various parameters such as lead time, worker satisfaction, and environmental conditions.
These cases are examples that are identified within the FAIRWork project to provide input for the design of the system. The cases stem from the two manufacturing companies Stellantis/CRF (https://www.stellantis.com/) and FLEX (https://flex.com/). The concrete use cases have been abstracted to Decision Support Challenges, which are introduced in section 4.2. A more detailed description of the use cases can be found in [21].
In this section, we introduce the procedure which guides the creation of the DAI-DSS in the FAIRWork project and how the DAI-DSS is applied in real-world scenarios.
The procedure itself is based on the Plan-Do-Check-Act (PDCA) methodology [22], where its four phases are aligned circularly, meaning that they are executed multiple times to improve the overall result (design iterations, continuous improvement). In the context of the overall goal of the DAI-DSS, this means that not only solutions to decisions should be proposed but also data on the execution of the chosen solution is gathered so that it can be analysed to allow further improvement.
The Plan phase consists of analyzing the problem and creating one or more solution strategies to solve it. In this paper’s context, the type of decision and its context must be understood to provide “fitting” and “adequate” decision support. After it is understood, the important aspects of the decision are captured and described in a comprehensible way. This requires for a domain-specific vocabulary in the form of a metamodel to derive conceptual models. The model-based approach for understanding and capturing the needed knowledge of the decision problems and their context is described in section 5 and visualized in the top layer of Figure 1. This approach was established and used in two manufacturing companies to guide the design of the DAI-DSS, and the results were abstracted into the decision support challenges, introduced in section 4.2.
After the decision problem is understood, a solution strategy is designed and configured utilizing the models. The configuration contains the preparation and orchestration of diferent decision support modules and the connection to the knowledge base to gather the needed information. Therefore, after the Plan phase, the DAI-DSS is established to ofer support for the identified decision problem.
In the Do phase, the prepared system is used in real-world environments to support the production process containing the identified decision problems. In the project, an experimental approach is applied to evaluate DAI-DSS first in a small-scale setting under laboratory conditions. This enables the industrial partners of the project to assess the applicability. This includes real-time data processing of the system, containing the input of actors, to provide contextual information or to start a decision support process. During the execution of a decision support process, data is collected as input for a later evaluation and planning of adaptations. Which data is collected depends on the concrete usage, but the system enables mechanisms to persist this data, for example, through log files or directly saving it to the knowledge base as input for the calculation of key performance indicators (KPI) of the system.
After one or multiple decision support processes are executed, the Check phase is applied. First, KPIs are defined to evaluate the DAI-DSS configuration for the specific decision problem. Afterwards, the KPIs are calculated and prepared based on the available data to evaluate the decision support system as a whole or to analyze specific parts, like assessing if the chosen AI approach was feasible or not. The KPIs themselves focus on diferent aspects, like analyzing the influence of the decision support system on the production process, if the available data is suficient, whether all needed stakeholders could participate, or if the decision support tool itself is adequate for the task.
Last but not least, in the Act phase, reflection on the results from the previous phase is triggered to learn how the decision support can be improved for future usage for the same or similar decision problems. Based on the identified problems with the current solution, diferent starting points for improvement can be identified, e.g., the specification of the problem, the used AI algorithms, or other parts of the configuration. The identified problems and starting points are then used as input for the Plan phase of the next iteration. These findings from the Act phase are not only applicable for the upcoming iteration of system design, but are also useable as lessons learned to be applied to similar decision support processes, or insights can be generated on how new decision problems can be supported with the DAI-DSS.
To guide the design of the DAI-DSS, multiple decision problems of the two manufacturing companies CRF and Flex, were thoroughly investigated during the Plan phase of the aboveintroduced design procedure (see section 4). Following the set objective to support flexible adaptation to changing or newly identified decision problems, three categories of decision support challenges were abstracted from the concrete decision problems of the industrial partners. These challenges are used to guide the design of the DAI-DSS and are introduced in this section. More information on the underlying use cases from the manufacturing companies can be found in [21].
Resource Mapping is the category of decisions where a requester and a provider of artefacts or services must be matched to achieve a common goal. An example is that workers (providers) with certain capabilities must be matched to machines (requesters) to fulfil the orders. Here the characteristics of the provider and the requester must be considered and compared to each other. This not necessarily leads to the decision if an allocation is a match, but how fitting it is, so that diferent allocations can be compared with each other. This mapping goes beyond a one-to-one mapping towards mappings between sets of requesters and sets of providers. Solution Configuration is applied in the context of an adaptive system (e.g., a production line), and the decision support helps to decide which configuration of the system is feasible or allow a comparison between them. The resulting configuration must not only be feasible within the company but also within the current restrictions, based on available resources, orders that must be fulfilled, therefore considering the production ecosystem as a whole. Selection is the decision support challenge for decisions that are applied after resource mapping or solution configuration , which result in a list of possible alternatives from which one must be chosen. Selection contains algorithms that support a comparison of diferent possible solutions and rank them accordingly. Therefore, context information of the solution proposals (from resource mapping and solution configuration ) is used as an input to be used for comparison, including the human in the loop.
The common requirements from the above challenges result in the following two aspects of the DAI-DSS to be considered: • Common understanding of the decision scenario: The decision problem scenario and its context must be suficiently understood. This requires means to have an adequate knowledge representation in place. • Module orchestration: The adequate algorithms need to be identified (based on the common understanding) and composed/orchestrated in a manner to fulfil the needs of the application scenarios and domain.
Within the DAI-DSS, these two aspects are targeted through a model-based alignment which is visualized in Figure 1. The figure shows three layers, where the top layer represents how the decision problem is understood and formalized (diferent levels of abstraction are applicable), whereas the bottom layer shows what the DAI-DSS ofers with respect to decision support. The middle layer is concerned with mediation between the needs and the available resources. In the following each layer is introduced, starting from the top and bottom ones. The core layer of DAI-DSS is concerned with the configuration environment for decision support challenges. Application Scenario As a means to understand the decision problem scenario, which should be supported by the DAI-DSS (represented in the top layer of Figure 1), a model-based approach is used. First, the decision support scenario and its context are elicited and afterwards formalized before they can be integrated into the DAI-DSS operational environment. Conceptual models on diferent abstraction levels thereby support these steps.
During design thinking workshops (virtual and/or physical) with the involved stakeholders a
high-level scenario is developed. The participants of such workshops are experts in diferent
domains (e.g., finance, compliance, manufacturing, business) and therefore, tangible techniques are
used to foster participation, understanding and communication between them. The Scene2Model
(cf. [
To capture the knowledge produced in the workshop, the Scene2Model environment ofers an automated transformation from the used paper figures to digital conceptual models. These models are considered “digital twins of the scenario design”. The models are later adapted and enriched with information so that the knowledge from the workshops becomes shareable with stakeholders not presented. An example of such a resulting model can be seen in Figure 1 (titled with Design Thinking). The models created during the workshops facilitate communication and understanding of the decision problem scenario, but to capture this knowledge in an unambiguous way - so that it becomes usable in a decision support system - a formal knowledge representation is required. This can be achieved through conceptual modelling methods. In the FAIRWork project, the general purpose Business Process Model and Notation (BPMN) language is used to formalise the decision process, and the Decision Model and Notation (DMN) language is used to capture the parameters of a decision and its logic.
To efectively address such decision problems, it is crucial to understand the problem at hand and derive potential solutions. The DAI-DSS introduces a flexible approach by using a collection of AI services, each equipped with diferent AI algorithms, which act as the foundation for generating possible solutions. When faced with a new decision problem, users of the DAI-DSS can select the appropriate AI services from the provided set and cater them to the specific requirements of the problem, ensuring adaptability and eficiency in decision-making. Enabling Data and AI Environment As these services are technical components, which consume data and provide possible solutions, they must be integrated into an infrastructure to be useable. Therefore, digital twins and digital shadows of the production environment will be used and connected to the DAI-DSS and the AI services. In this way, actual data can be accessed, and the result of the decision can be integrated into the production processes.
The available set of AI services must be known so that users can choose the ones they need, and the selected AI services must be deployed and started so that they can be used. To create a concrete solution, input data must be provided to the service, and the output must be passed to the users. By having diferent AI services that can be selected, the DAI-DSS can be flexibly adapted to new decision problems (graphically in Figure 1 bottom).
DAI-DSS Layer: Model-based Alignment But the AI services only lay the base for flexibility, as ofering them is not enough to make them usable for new decision problems. Therefore, the logic of the identified decision problems must be realised with the AI services and other components of the DAI-DSS, which is achieved through a model-based alignment using a configurator. This is visualized in the middle layer of Figure 1.
The configurator uses the models from the top layer and the AI services from the bottom layer as input and creates a configuration for the DAI-DSS. This includes user interfaces, a knowledge base, and the orchestration of the services to enable the creation of possible solutions (more details on the components can be found in section 6). Therefore, the configuration not only focuses on the AI services and their requirements but also includes other aspects such as interaction and continuous improvement/lessons learned needed for the decision support system to become usable.
Based on this conceptual perspective on alignment, the technical architecture is presented in the next section.
As an initial result, the implementation architecture of DAI-DSS has been established and is introduced in the following subsection. Based on the scenarios/challenges (see section 4.2) and alignment consideration, the architecture is presented as a distributed, service-oriented environment that utilizes models as a configuration, interaction and operational artefact. As such it acts as a blueprint for implementation.
This section will provide an overview of the architecture’s main components. A detailed description of the architecture can be found in [23]. The architecture is visualised in Figure 2, and the main components are highlighted with red boxes.
User Interface. The user interface enables involved stakeholders to interact with the DAI-DSS. Diferent interfaces will be provided to achieve various tasks. For example, decision-makers need an overview of possible alternative solutions and their diferences. Other users need an overview of the KPIs of the decisions so that they can evaluate their applicability, or actors need an interface to trigger the required decision process. The user interface is defined as its own component, as interfaces for diferent tasks and also diferent devices (e.g., laptops, smartphones, TVs, AR glasses, etc.) are needed. Therefore, the user interfaces are implemented separately and linked to the core system via defined interfaces. An important aspect related to the interface layer is provenance and trust. This means that the presented results or visualisation are required to enable the drill-down mechanisms to assess how results (algorithm, data) have been achieved. Configurator. The configurator component allows to adapt the DAI-DSS and its components so that it can be flexibly adapted to various decision problems. This component will be modelbased and able to create and consume models created with dedicated tools to establish the configurations of the DAI-DSS accordingly. Additionally, the configurator will ofer functionality to asses the configured decisions, based on usage data (e.g. logged information or user feedback via questionnaires).
AI Enrichment Services. The AI enrichment services component represents the usage of AI algorithms to provide solutions for decision problems. Diferent AI algorithms are thereby implemented as services, following a micro-service architecture (cf. [24]). The services themselves can be configured to support diferent decision problems and are then used by the orchestrator to support concrete decision problems with the DAI-DSS.
AI algorithms of diferent types, like symbolic, sub-symbolic, or hybrid approaches (cf. [ 25]) can be used by this component. It is important that the algorithm allows an adaptation and usage in the context of the abstracted decision support challenges, which implies that a) the input/output requirements are clearly defined and b) configuration possibilities are foreseen. Agent System. This component represents the environment that enables agents which will be created to represent human and virtual actors within the DAI-DSS. The agents themselves will negotiate for the represented actors to support the decision-making process. Additionally, agents can be used by the orchestrator to support the orchestration of the diferent services, not through centrally designed workflows, but by cooperating with each other to find feasible solutions.
Orchestrator. The orchestrator is a critical component of the DAI-DSS, as it controls the configured micro-services and facilitates decision support. This includes on one side managing the life-cycle of the micro-services, like starting, stopping, restarting, or decommissioning them. On the other side, the orchestrator also manages the information flow between diferent services. For example, one decision in a production line may be separated into two sub-decisions, which are executed separately utilizing independent implementations in micro-services. The results are later combined into one proposed solution.
The orchestration can be done by using workflows or multi-agent systems. Users define workflows to specify which service or other components are used at which stage of the decision support process and how data is exchanged. If a multi-agent approach is chosen, then the individual agents will coordinate themselves to find solutions for the decision problem. Knowledge base. The knowledge base of the DAI-DSS will be the central repository for saving and retrieving data. The DAI-DSS requires data from diferent sources, which are used as input, e.g., real-time data from a production line or context information like workers’ qualifications. Additionally, the data created by the decision support system is stored and persisted in the knowledge base. The structure of the knowledge base is based on two concepts: digital twins/ digital shadows and data lakes. Digital shadows/twins have been introduced in section 2, whereas data lakes (cf. [26]) are relevant to store data from multiple sources combined to provide access in a distributed system, independent of the actual source system/provider. Real-World Use Cases in the Production. This component represents data which is gathered from outside the DAI-DSS. They can either be provided directly from technical components linked with machines or humans or from a data catalogue that acts as an extensible metadata platform, enriching data with meta information. The data catalogue is connected to external data sources to integrate them and make the data available within the DAI-DSS. The architecture itself is designed to support the flexibility of the system and allow for an adaptation to concrete, domain-specific decision problems. Data can be saved and exchanged using the knowledge base component, which decouples the singular components and further supports flexibility.
This paper provided an overview of the EU-funded FAIRWork project and its initial result the architecture of the democratic AI-based decision support system (DAI-DSS) and the specification of the decision challenges used as the basis for its design. Therefore, the design procedure used to create the DAI-DSS has been introduced, followed by a discussion of the decision challenges, resulting in the architecture presented. An important aspect of the architecture relates to the use of conceptual models as a core element of the components. Matching requirements in the form of models towards abstract representations of resources (algorithms, data sources) is considered a flexibilisation aspect as the environment is open to extension (data, AI services) and adaptable to other manufacturing domains and decision problems.
This also poses a challenge during the development, as the underlying metamodels need to be adequate for the purpose. This becomes specifically relevant when utilizing domainspecific modelling languages where execution semantics need to be considered as part of the conceptualisation of the modelling method. Consequently, techniques are assessed that allow for dynamic modification of metamodels (potentially at runtime) to capture these aspects and classify modelling techniques according to their specific purpose as defined in [27].
As discussed in the above section, this paper introduces the architecture of the DAI-DSS system. Future work is scheduled according to the project lifecycle to evaluate the feasibility of the environment and trigger the implementation and integration of the components. The OMiLAB infrastructure is available at FAIRWork partners BOC and JOANNEUM research and is used to perform small-scale experiments and trigger the community involvement to extend, contribute services and/or model-based approaches based on the challenges identified. Through this approach, community-based innovation processes are made feasible.
This work has been supported by the FAIRWork project (www.fairwork-project.eu) and has been funded within the European Commission’s Horizon Europe Programme under contract number 101049499. This paper expresses the opinions of the authors and not necessarily those of the European Commission. The European Commission is not liable for any use that may be made of the information contained in this paper. The authors express their gratitude to the project consortium for their input in writing this paper, specifically the industrial partners Stellantis/CRF and FLEX for the valuable time during the requirements elicitation phase. [6] P. Leitão, Agent-based distributed manufacturing control: A state-of-the-art survey, Engineering Applications of Artificial Intelligence 22 (2009) 979–991. URL: https: //www.sciencedirect.com/science/article/pii/S0952197608001437. doi:https://doi.org/ 10.1016/j.engappai.2008.09.005, distributed Control of Production Systems. [7] D. Karagiannis, R. Woitsch, Knowledge Engineering in Business Process Management, in: J. vom Brocke, M. Rosemann (Eds.), Handbook on Business Process Management 2: Strategic Alignment, Governance, People and Culture, Springer Berlin Heidelberg, Berlin, Heidelberg, 2014, pp. 623–648. URL: https://doi.org/10.1007/978-3-642-45103-4_26. doi:10.1007/978-3-642-45103-4_26. [8] R. Cognini, F. Corradini, A. Polini, B. Re, Business Process Feature Model: An Approach to Deal with Variability of Business Processes, in: D. Karagiannis, H. C. Mayr, J. Mylopoulos (Eds.), Domain-Specific Conceptual Modeling: Concepts, Methods and Tools, Springer International Publishing, Cham, 2016, pp. 171–194. URL: https://doi.org/10.1007/ 978-3-319-39417-6_8. doi:10.1007/978-3-319-39417-6_8. [9] T. Biard, A. Le Mauf, M. Bigand, J.-P. Bourey, Separation of decision modeling from business process modeling using new “Decision Model and Notation”(DMN) for automating operational decision-making, in: Risks and Resilience of Collaborative Networks: 16th IFIP WG 5.5 Working Conference on Virtual Enterprises, PRO-VE 2015, Albi, France„ October 5-7, 2015, Proceedings 16, Springer, 2015, pp. 489–496. [10] M. Walch, D. Karagiannis, How to connect design thinking and cyber-physical systems: the s* IoT conceptual modelling approach, in: Proceedings of the 52nd Hawaii International Conference on System Sciences, 2019. URL: http://hdl.handle.net/10125/60161. doi:10. 24251/hicss.2019.870. [11] X. Xu, Y. Lu, B. Vogel-Heuser, L. Wang, Industry 4.0 and Industry 5.0—Inception, conception and perception, Journal of Manufacturing Systems 61 (2021) 530–535. [12] I. Vaidian, A. Jurczuk, Z. Misiak, M. Neidow, M. Petry, M. Nemetz, Challenging Digital Innovation Through the OMiLAB Community of Practice, in: D. Karagiannis, M. Lee, K. Hinkelmann, W. Utz (Eds.), Domain-Specific Conceptual Modeling: Concepts, Methods and ADOxx Tools, Springer International Publishing, Cham, 2022, pp. 41–64. URL: https: //doi.org/10.1007/978-3-030-93547-4_3. doi:10.1007/978-3-030-93547-4_3. [13] C. Muck, W. Utz, A Recognition Service for Haptic Modelling in Scene2Model, in: A. Martin, H.-G. Fill, A. Gerber, K. Hinkelmann, D. Lenat, R. Stolle, F. van Harmelen (Eds.), Proceedings of the AAAI2023 Spring Symposium on Challenges Requiring the Combination of Machine Learning and Knowledge Engineering(AAAI-MAKE 2023)„ CEUR Workshop Proceedings, 2023. URL: https://ceur-ws.org/Vol-3433/short4.pdf. [14] A. Felsberger, B. Oberegger, G. Reiner, A Review of Decision Support Systems for Manufacturing Systems, in: R. Kern, G. Reiner, O. Bluder (Eds.), Proceedings of the 1st International Workshop on Science, Application and Methods in Industry 4.0co-located with (i-KNOW 2016), 2016. URL: https://ceur-ws.org/Vol-1793/paper6.pdf. [15] S. Zhang, F. Tang, X. Li, J. Liu, B. Zhang, A hybrid multi-objective approach for realtime flexible production scheduling and rescheduling under dynamic environment in Industry 4.0 context, Computers & Operations Research 132 (2021) 105267. URL: https: //www.sciencedirect.com/science/article/pii/S0305054821000599. doi:https://doi.org/ 10.1016/j.cor.2021.105267.