BatCAT deliverable 5.1: Cellular neural networks and multicriteria optimization

101137725/BatCAT/WP5/D5.1 D5.1: Cellular neural networks and multicriteria optimization Grant agreement number: 101137725 Project acronym: BatCAT Project title: Battery Cell Assembly Twin Project website: http://batcat.info/ Project start date: 01.01.2024 Project duration: 42 months Call topic: HORIZON-CL5-2023-D2-01-03 Deliverable type1: Report (R) Related work package: WP5 Due date: 30.06.2025 Actual submission date: 29.06.2025 Responsible beneficiary: ITWM Dissemination level2: Public (PU) Version: final Abstract: This deliverable (D5.1) reports on the development and results of advanced battery health optimization and performance within T5.1 of the project. The work focuses on creating a self-supervised Cellular Neural Network (CeNN) predictor to provide real-time and adaptable battery State of Health (SOH) by leveraging a student-teacher learning framework. Additionally, the deliverable covers T5.2, i.e. the implementation of Multi-Criteria Optimization (MCO) for dynamic, staged Constant Current (CC) charging protocols, which enables optimized balance charging speed, safety, and battery longevity. 1 Deliverable type: R = Report, P = Prototype, D = Demonstrator, O = Other. 2 Dissemination level: PU = Public, SEN = Sensitive. Public Version: final Furthermore, Long-Term State Forecasting (LTSF) models are developed for predictive maintenance, enabling reliable SOH and capacity fade predictions over extended battery life cycles. The utilization of these models is supported by the DoE/DoS developments under T5.2 and the interoperability constructions integrated from T3.4 and T4.4. Keywords ML trained by simulated & characterization data; MCO, DoE, DoS Author list Beneficiary Name Contact e-mail ITWM Peter Klein [email protected] ITWM Marco Baldan marco.bal[email protected] NMBU Aditya Dey [email protected] NMBU Fadi Al Machot fadi.[email protected] Reviewer list Beneficiary Name Contact e-mail HSKL Johanna Glutting [email protected] NMBU Maria Bashir maria[email protected] AAU Mohamed El Bahnasawi moham[email protected] Document history Version Date Reason/comment Revised by 1.0 29.06.2025 Submitted See author list for all who contributed Disclaimer Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Climate, Infrastructure and Environment Executive Agency (CINEA). Neither the EU nor the CINEA can be held responsible for them. Abbreviations and acronyms ASP answer set programming CC constant current CV constant voltage CeNN cellular neural network DoE design of experiment DoS design of simulation LIB Li-ion battery LTSF Long-term state forecasting MCO multicriteria optimization RFB redox flow battery SoH state of health Public Version: final BatCAT has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement no. 101137725. Contents 1. Executive summary ...................................................................................................................................... 3 Description of the deliverable content and objectives .................................................................................... 3 2. Progress report (main activities) .................................................................................................................. 3 2.1 Integration of work streams from work packages different from WP5 .................................................... 3 2.2 Task T5.1 — Battery health optimization strategies .................................................................................. 4 2.3 Adaptable cellular neural network predictor ............................................................................................. 4 2.4 Multicriteria optimization for staged charging profiles ............................................................................. 5 2.5 Long-term state forecasting for predictive maintenance .......................................................................... 5 3. Results and impact ....................................................................................................................................... 5 4. Conclusion .................................................................................................................................................... 6 References ............................................................................................................................................................ 6 Annex 1: Software modules for MCO and tutorial use case ................................................................................ 7 1. Executive summary Description of the deliverable content and objectives Task 5.1 focuses on developing a self-supervised machine-learning predictor for battery health optimization. The core of T5.1 is to design an adaptive, self-supervised Cellular Neural Network (CeNN) predictor which allows for a continuous retraining and improvement. This is integrated with the developments of T5.2, MCO technology, which is one out of several technologies that contribute to the digital twin approach in BatCAT. Design of experiment (DoE) and design of simulation (DoS) have been demonstrated for a combined simulation/experimentation characterization of electrolytes. The main objectives of the tasks related to this deliverable are fulfilled. 2. Progress report (main activities) 2.1 Integration of work streams from work packages different from WP5 Public Version: final Within Work Package 4, Task T4.4 - Metadata standardization, ontologies are being developed to cover all aspects of battery manufacturing, modelling and characterization that will be needed within BatCAT and in particular in Work Package 5. Currently a set of eight modules is being drafted, namely: (a) Higher level; (b) Optimization, decision support, design; (c) Twinning; (d) Data and metadata; (e) Modelling and simulation; (f) Characterization; (g) Manufacturing; (h) Battery (LiB and RFB). Particularly relevant to this deliverable, the module for optimization will cover both logic-based and numerical optimization, which within BatCAT Work Package 5 are tackled by answer set programming (ASP) and multicriteria optimization (MCO), respectively. Currently, for example, it contains concepts such as “problem”, “solution”, “constraint”, which can be “qualitative” or “quantitative”. In parallel, coverage of BatCAT requirements by existing semantic artifacts is assessed, so that reuse and development are suitably combined. As T4.4 will continue over the next six months, further concepts will be added to cover all requirements. Work Package 5 will pick up the ontology developments from WP 4 as they go, initial integration steps were already undertaken. 2.2 Task T5.1 — Battery health optimization strategies Within WP5 — Digital Twin Technology, Task 5.1 focuses on developing a self-supervised machine-learning predictor for battery systems. The core of T5.1 is to design an adaptive, self-supervised CeNN predictor, which leverages a student-teacher learning architecture. This enables the model to continuously adapt its parameters in response to new operational data, providing a robust and scalable solution for real-time, datadriven battery modeling and health optimization. T5.1 advances the project objectives by developing a suite of complementary models, each addressing a critical aspect. The task delivers: • An adaptive, self-supervised CeNN predictor for real-time state of health (SoH) and operational parameter estimation [1, 4]. • MCO for staged constant-current (CC) charging profiles to balance speed, safety, and battery life. • Long-term state forecasting (LTSF) models for lifecycle-aware predictive maintenance [2, 3]. All models are validated on publicly available benchmark datasets. This task directly supports: • Fast, safe charging operations • Accurate SoH estimation and forecasting • Autonomous model adaptation to changing conditions • Real-time, embedded deployment for digital twin platforms T5.1’s approach is integrated and modular, allowing each model to be used independently or as part of a unified framework. The key methodologies and innovations are described below: 2.3 Adaptable cellular neural network predictor The CeNN-based predictor follows a student-teacher learning architecture which allows to: Public Version: final • Adapt its parameters in response to changing battery states and operational conditions [1,4]. • Deliver real-time, high-accuracy estimates of SoH, capacity, and energy. • Low computational footprint. The predictor is suitable for a wide range of data-driven battery modeling tasks. 2.4 Multicriteria optimization for staged charging profiles Traditional CC-CV charging protocols do not adequately balance charging speed with safety and degradation. In T5.1, we innovate by segmenting the CC phase into adaptive stages, each optimized using MCO algorithms. This approach: • Dynamically optimizes charging current ramp rates in each stage to rapidly reach the target voltage while controlling thermal and chemical stress. • Allows fine-grained trade-offs between charging speed, safety, and battery longevity, all tuned in real time. • Integrates temperature and SoH constraints directly into the optimization process, resulting in safer and more efficient charging cycles. This method is crucial for enabling ultra-fast charging applications without sacrificing battery health or safety. 2.5 Long-term state forecasting for predictive maintenance Long-term forecasting of battery SoH and capacity fade is essential for predictive maintenance and operational planning. The LTSF models developed in T5.1: • Employ both frequencyand time-domain representations to accurately predict SoH trajectories over extended horizons (e.g., 48 to 720+ cycles). • Use model architectures with significantly lower complexity than state-of-the-art transformer models, making them practical for deployment [2, 3]. • Support second-life and recycling strategies by providing reliable end-of-life predictions. 3. Results and impact The innovations developed in T5.1 have resulted in measurable improvements across all critical dimensions of battery management. Specifically: • SoH prediction: The CeNN predictor delivers real-time, accurate SoH estimates, outperforming classical approaches and providing reliability for embedded use [1, 4]. • MCO: Clear interfaces to modelling approaches from WP2 are implemented. Public Version: final • DoE/DoS: The ITWM technology has been utilized for a demonstration case, including flexible strategies for enhancing the predictive power of surrogates from few to many data, demonstrated for electrolyte characterization/optimization. • Charging optimization: The staged CC charging protocol with MCO achieves significantly faster charging while maintaining strict safety and health limits. • Lifecycle management: LTSF models offer robust, long-term forecasts, enabling proactive and costeffective maintenance strategies [2, 3]. Contributions to the BatCAT impacts include: • Modelling support for increased battery performance and lifespan. • Enhanced predictive maintenance and second-life applications. • Support flexible, scalable digital twin deployments. • Concrete contributions to project objectives KO5, KO6, and KO7. 4. Conclusion The AI/ML models implemented mainly in Task T5.1 are designed to be continuously updatable, and this will be done as soon as new data are available either from the consortium or from the literature. The APIs of these models are integrated into the MCO and DoE/DoS modules from Task T5.2, so that a first demonstration of aspects of digital twins, the overarching goal of BatCAT, was successful. It is to be expected that the developments presented in this deliverable report are updated as the project evolves, since retraining of the models from Task T5.1 and numerical subtilities when it comes to the integration of more sophisticated models from WP2 into the MCO and DoE/DoS approaches will continue. References [1] Samarathunga, L. S. W., Horsch, M. T., Dey, A. & Al Machot, F. (2025). Predicting Battery Degradation Using Cellular Neural Network Model. DTE & AICOMAS 2025. [2] Dey, A., Kusch, J., & Al Machot, F. (2025). Symmetric Fourier Fragment Transform for Univariate Long-Term Time Series Forecasting. 28th International Conference on Discovery Science (under review). [3] Dey, A., Kusch, J., & Al Machot, F. (2025). HADL: A Haar-DCT and Low-Rank Framework for Noise-Resilient Long-Term Time Series Forecasting. International Conference on Time Series and Forecasting (ITISE 2025). [4] Samarathunga, L. S. W., Dey, A., Horsch, M. T., & Al Machot, F. (2025). Lightweight and Resource-Efficient Battery Degradation Prediction Using Teacher-Informed Cellular Neural Networks (TICeNN). 3rd International Conference on Frontiers of Artificial Intelligence, Ethics, and Multidisciplinary Applications (FAIEMA 2025) (submitted). [5] M. Baldan, D. Alt, X. Zhang, P. Klein, S. Stephan (2026). Optimal Experimental Design Methods for the Parametrization of Entropy-Scaling Transport Property Models, Computers & Chemical Engineering (to be submitted) Public Version: final Annex 1: Software modules for MCO and tutorial use case Multicriteria Optimization (MCO) and model-based Design-of-Experiment/Simulation (DoE, DoS): Use Case, architecture and implementation modules Peter Klein a, ∗ , Marco Baldan a a Fraunhofer Institute for Industrial Mathematics ITWM, Fraunhofer Platz 1, D-67663 Kaiserslautern, Germany Contents 1 Introduction 2 2 The hypothetical business case used in this tutorial 2 3 Kinetic reaction model: simulation workow and data foundation 4 3.1 The reactor model ..................................... 4 3.2 The kinetic reaction model, related to a simulation workow .............. 6 3.3 Prototype implementation modules ............................ 9 4 Multi criteria optimization 14 4.1 Introduction to MCO for continuous problems ...................... 14 4.2 Design space, constraints and objectives for the batch reactor MCO problem . . . . 15 5 MCO implementation modules 18 5.1 MCO solver and associated wrappers for MCO problem set-up ........... 18 5.2 Design space-, objective-, and constraints-wrapper for the prototype ......... 21 5.3 Approximation of the Pareto front and cognitive surrogates .............. 23 6 Optimal experimental design 25 6.1 Introduction to optimal design of experiment/simulation for continuous problems . . 25 7 Acknowledgement 25 8 References 25 ∗ Corresponding author Email address: [email protected] (Peter Klein ) 1. Introduction In BatCAT, we strive for the development of a general set of software modules implementing Multi Criteria Optimization MCO and model based Design-of-Experiment/-Simulation DoE, DoS to be integrated in a general platform supporting the digital-twin approach taken by BatCAT. The purpose of this document is to introduce the mathematical background behind the methodologies used, to dene an initial implementation architecture, and to present a reduced use-case which serves as a tutorial for the mathematical concepts. This tutorial starts with a hypothetical business case inspired by a chemical engineering challenge: a toy reaction performed in an idealized batch reactor. From a modelling perspective, the batch is described using a standard approach, namely reaction kinetics dierential equations describing the dynamics of substance concentrations. The specic model used here admits an analytical solution, so the forward simulation in this tutorial is fast, in contrast to many physics based models to be used in BatCAT. Then, a mapping of the toy system to a simulation workow will get constructed. Already in this tutorial, the idea to relate business cases to use cases is put forward as well. In particular, the relation of design and objective space (KPI and cost measures of the business case) is outlined. Together with constraints describing the reactor capabilities and business requirements, a multi-criteria optimization model and a solution strategy based on existing solvers will be set up. Implementation modules are described in a CRC like style: the responsibilities and collaborations between implementation modules will get identied and a high level description of the data attributes and functionalities of the implementation modules is suggested. After the introduction of Multi-Criteria Optimization, this tutorial discuss the concept of optimal model based experimental design, again in a multi-criteria setting. Conceptually, optimal DoE/DoS has many similarities to MCO: the MCO design space is the DoE/DoS parameter space and the MCO objectives/KPIs relate to DoE/DoS experiment/simulation results. However, as discussed below, the focus of what is to be considered as being "optimal" is somewhat dierent leading to adapted numerical solution strategies. 2. The hypothetical business case used in this tutorial The business case, we want to use in this tutorual, including a reference implementation, consists of a hypothetical reaction of two educts, A and B in a liquid: 2 3.3. Prototype implementation modules The kinetic model needs to be initialized by the concentrations of the substances, the parameters of the reaction constant's model and the process parameters (reactor). This calls for the following 4 modules:  a ReactionKnowledgeGraph module for the initial concentrations,  a MaterialsData module for the parameters of the Arrhenius reactivities,  a ProcessData module describing the process environment and its parameters,  a modelling workow module for solving the kinetics (3.6). The information from the ReactionKnowledgeGraph module is rather simple: the product P may be produced by a reaction of the two educts, the pure concentrations of the substances A and B should be equal, and an estimate of the reaction time: Module ReactionKnowledge.mod: of reaction partners. Responsibility: Chemical inference handling based on data in a Knowledge Graph Collaborators: The informations gathered by domain experts, patents, literature,.. Data: stores a knowledge graph // return (list of) potential reaction partners for Product P. ; 1 Function (X, Y )getEducts4Product(P) // look up knowledge graph, for prototype return educts A and B. ; 2 return info (A, B) ; // from chemical inference retrieve potential side products ; 3 Function list getSideProducts(X+Y−> Z) // for prototype, return 1 element S ; 4 return list ; 5 Function info goodPractice4Reaction(X+Y−> P) 6 return info [A]0== [B]0 ; 7 Function time estimateReactionTime(A+B−> P) 8 return estimate; 9 The interface to the MaterialsData is trivial: upon request, the reaction enthalpy and the pre-factor of the Arrhenius equation are returned. Database Materials.db: of reaction partners. Responsibility: Stores reaction partner material parameters. Remember: only two reactions occur!! Collaborators: Data space Data: Information on possible reactions of A and B 1 Function (MassMolecule)getComponentMolecMass(X) // inspect data base ; 2 return massX 3 Function ρXgetP ureComponentDensity(eductX) // inspect data base, map (contaminated) educt name to pure substance ; 4 return ρX ; 5 Function {ν, ∆H}getArrheniusP arams(X+Y−> Z) // inspect data base ; 6 return {ν, ∆H} ; 7 Function cost getSupplierCostEduct(eductX) // inspect data base ; 8 return cost ; ProcessData are handled similar to the MaterialsData . Since the cost measures are sensitive parameters, their gradient calculation according to the tunable parameters is handled in this module as well: 10 Database Process.db: of reaction partners accessible to processing. Responsibility: Accessor for processing specic parameters, i.e. the reactor. Collaborators: Excel sheets provide basic parameters, Materials.db Data: A reactor description, including purication info. 1 Function ( costprod,∇Xproc costprod)calcProductionCost(Xproc) // parameters for equation (3.2) from excel sheet ; 2 return (cost, ∇X0cost) ; 3 Function (ContaminationMin, ContaminationMax)getContaminationRange(eductA) // look up excel sheet, ContaminationMax: supplier info, ContaminationMin: purification ; 4 return available contamination range; 5 Function (TMin, TMax)getTempRange() // look up excel sheet ; 6 return available temperature range; 7 Function (cost, ∇Xload )calcMatCost(Xload) // supplier costs from Materials.db and use equ. (3.3); 8 return (cost, ∇Xload ) ; 9 Function reactorvolume getReactorV ol() // look up excel sheet ; 10 return volume of reactor; The information necessary for the initialization of the kinetic model is now spread over Materials.db,Process.db and ReactionKnowledge.mod. We collocate these information in an Initializer module: 11 Module Initializer.mod: for kinetic model. Responsibility: Initializer Strategy for the simulation of reaction kinetics Collaborators: Materials.db,Process.db,ReactionKnowledge.mod Data: Handle's to collaborators, for example supplier data bases 1 Function X0getInitDataKinModel(A+B→P) // use midpoint for ranges (TMin, TMax) = Process.db :: getT empRange() ; 2 X:: T= 0.5·(TMin +TMax) ; 3 (ContaminationMin, ContaminationMax) 4 =Process.db :: getContaminationRange(A) ; 5 ¯ [C]=0.5·(ContaminationMin +ContaminationMax) ; // Product and side product not loaded ; 6 X:: [P] = X:: [S] = 0 ; // [A] == [B] , use mass conservation (3.14) ; 7 info =ReactionKnowledge.mod :: goodP ractice4Reaction(A+B−> P ) ; 8 E=1−¯ [C]/ρC ρ−1 A+ρ−1 B−¯ [C]/(ρBρC) ; 9 info−>(X:: [A] = X:: [B] = E) ; 10 X:: [C] = ¯ [C](1 −X::[B] ρB) // reaction time from chemical inference ; 11 X:: τ=ReactionKnowledge.mod :: estimateReactionTime4Reaction(A+B→P) ; 12 return X; 13 Function M getMaterialRelationData(A+B→P) 14 S=ReactionKnowledge.mod :: getSideP roducts(A+B→P) :: listentry ; 15 M:: {νP,∆HP}=Materials.db :: getArrheniusParams(A+B→P) ; 16 M:: {νS,∆HS}=Materials.db :: getArrheniusParams(A+B→S) ; 17 return M; Now, the Simulation workow has only one dependency to Initializer.mod. At constant temperature, the kinetic model has an analytical solution. The prototype SimWorkow module implements the analytical solutions in order to return the physical state variable associated with the solution of the kinetic model. As already noted in the introduction, analytical solutions are in 12 general not available for most real world problems; however, the interface to numerical solutions of forward simulations is similar to the one described in the SimWorkow module. Beside the physical state variable (3.12) the gradient in the space of tunable parameters (3.15) is calculated. Remark: This module may act as a persistence layer for simulations already performed (another software design option could be the introduction of an additional data base). The idea is that once the simulation of a materials model takes considerable computing resources, then results might be cached and reused (including interpolations if appropriate), thus saving a lot of computing time. Module ReactionKinetics.mod: simulates reaction kinetics. Responsibility: Simulation of reaction kinetics Collaborators: Initializer.mod Data: Persistency layer for storage of simulations already performed. 1 Function (Xmat,∇X0Xmat)runDefault(A+B→P) // Use Initializer.mod and run the simulation ; 2 X=Initializer.mod :: getInitDataKinModel(A+B→P) ; 3 M=Initializer.mod :: getMaterialRelationData(A+B→P) ; 4 return self :: run(X, M) ; 5 Function (Xmat,∇X0Xmat)run(X0, M) 6 if (X0, M) simulation cached then 7 return cached result; 8 else // implement solver of kinetic model (3.6); 9 calculate reactivity constants according to Arrhenius equation (3.7) 10 calculate Xmat(X:: Xproc :: τ) according to (3.10); 11 calculate ∇X0Xmat ; 12 cache {{X0, M},{Xmat,∇X0Xmat}} ; 13 return (Xmat,∇XXmat) ; 14 end 13 4. Multi criteria optimization 4.1. Introduction to MCO for continuous problems In general, an MCO model has three ingredients:  An objective space O . Each component of a vector from O represents one criterion to be optimized. By mathematical convention, we always seek for their minimization (by changing sing on criteria to be maximized).  A design space D spanning the parameter space mapped to objectives.  A set of constraints acting in the design space and/or in the objective space, usually given as equalities and inequalities (both linear and non-linear) The design variables associated with the MCO problem in the batch reactor example are continuous and the objectives are dierentiable. Furthermore, the objectives in the batch reactor example are functions of control variables (reaction time, temperature) and of a dynamical state variable. Thus, we deal with a multi-objective control problem. In general, these type of problems are formulated mathematically as min y∈D{O1(X(y), y), ..., On(X(y), y)} (4.1) subject to {ci(y)=0} : design space equality constraints {Ci(y)≤0} : design space in-equality constraints {gi(O)=0} : objective space equality constraints {Gi(O)≤0} : objective space in-equality constraints {Fi(t, X, ˙ X)=0} : state constraints, implicit rep. of ODE/PDE The notation min is commonly used here as a short hand for Pareto optimality. Since usually the objectives represent conicting goals, they may not be minimized simultaneously and we seek for best possible compromises, which in general are not unique. Most solvers of MCO problems of this type, so called gradient based solvers, use a common strategy: 14  scalarization: use a scalar product of a weight vector with the vector of objectives, thus mapping the MCO to a single criterion optimization problem.  solve the single criterion control problem using non-linear programming (see [1] for details), the theory behind single criteria optimization problems resides on the Karush-Kuhn-Tucker theorems, see [2]:  solve ODE for a given design space point.  calculate objectives and derivatives.  advice new candidate design space point.  stop once the KKT conditions are fullled. This leads to one candidate Pareto point (usually locally Pareto).  use a strategy to modify the weight vector in order to nd the next candidate Pareto point.  If the MCO problem is not globally convex, we need to apply a lter mechanism in order to get rid of dominated points not on the global Pareto front.  once a good enough approximation of the Pareto front is obtained: stop. An impression on how to classify MCO problems according to the nature of the objectives and of the constraints can be found in the wikipedia articles cited above. Even within one class of MCO problems, the choice of the weight strategy and of the KKT-solver is not unique and needs to get adapted to the specic MCO problem. 4.2. Design space, constraints and objectives for the batch reactor MCO problem The model ingredients will now get constructed for the business case; in the language of the EMMC, this construction is a translation process . It is obvious that here we have some freedom in constructing an MCO model. For instance, we may use as design space the space of variables closely connected to the mathematical formulation given as tunable parameters, equation (3.15), subject to mass conservation (3.14) and mixing role constraints (3.1). This modelling would serve the needs of an engineer interested in 'understanding'. In this prototype, we take a somewhat dierent point of view: the design space shall closely reect the tunable parameters of the process. We use as design space the process parameters and describe 15 the mixing process by appropriate volume fractions. We thus have a 4 dimensional design space with obvious constraints: D={(V˜ A,[C]e, T, τ)∥0≤V˜ A≤Vr,[C]min ≤[C]e≤[C]max, Tmin ≤T≤Tmax,0≤τ} (4.2) The volume load related to substance B is then given by Vr=V˜ A+VB . The initial concentrations, as functions of the design variables, now read: [A]0= [A]e·V˜ A Vr =ρA·(1 −[C]e ρC )·V˜ A Vr [B]0=ρB·Vr−V˜ A Vr [P]0= 0 (4.3) [S]0= 0 [C]0= [C]e·V˜ A Vr This modelling of the design space closely reects the needs of an operator running the reactor since the volumes to be loaded from the purication buer and from tank B are readily retrieved from design space variables. Now, we construct the mapping from the design space to the objective space. In natural language we have 3 objectives:  maximize the product P, which is equivalent to a minimization of product impurities [I] .  minimize the production cost costprod .  minimize the materials cost costmat . The product impurity is naturally modelled as a function of the physical state variables at the unloading time and implicitly as a function of temperature (via the reaction constants): [I] =[S]+[C]0+res([A]) + res([B]) (4.4) res(X) : residual concentrations of X=A,B at nal reaction time , We collocate the KPI (4.4) and the cost measures, equations (3.2) and (3.3), in one 3 dimensional vector ˜ O . The mapping of the design space to these vector of objectives uses the analytical expressions obtained above, re-written as functions of the design variables in y∈D . For the physical 16 state variable Xmat , this is done by using the initial conditions (4.3) and the reaction constants, as functions of temperature T , from the Arrhenius equation (3.7). Similar algebraic manipulations of the mixing parameters lead to cost measures as function of variables from the design space. Thus, the 3 objectives are given by ˜ O1=[I](X(y)) ˜ O2=costprod(X(y)) ˜ O3=costmat(X(y)) and derivatives are readily constructed analytically using the chain role based on the analytical solution for the time depended state variable given in equation (3.10). Since the residual impurities and the corresponding directional derivatives are assumed to be very small at long enough reaction times, we use a numerically more stable variant of the objectives: O1= ln([I](X(y))/[C]0) O2=costprod(X(y)) (4.5) O3=costmat(X(y)). Thus, the KPI from equation 4.4 is redened by it's logarithm. The MCO problem, formulated as a control problem, now reads: min y{O1(X(y)), ..., O3(X(y))} subject to y:T≤Tmax from (3.5) y:T≥Tmin y: [C]e≤ [C] max from (3.4) y: [C]e≥ [C] min ODE(3.6) with materials relation and initial conditions as functions of y τ≤τmax 17 We restrict the reaction time by a τmax for computational reasons: the contamination of the nal product may be minimized at innite reaction time only, which for a simulator means innite computing time (similar to convergence criteria of linear algebra solvers). We see, that up to the ODE constraint, all constraints are linear in-equalities. ( Note: if we use the 'mathematical' formulation discussed above, then the constraints need to reect the mixing roles as a non-linear equality. ) The formulation as a control problem, however, has some technical diculties related to the MCO solver implementations to be used in the prototype, namely that the MCO solver implementations 'want' to solve the ODE internally using their own solver and estimates the gradient informations. In a more general situation we use a modelling workow and this needs to get integrated in a deep manner into the MCO solvers (too much for a prototype!!). Since we have an analytical solution at hand, we use in this prototype another MCO modelling which uses these analytical solutions and thus turning the control problem to a standard MCO problem. min y{O1(X(y)), ..., O3(X(y))} subject to y:T≤Tmax from (3.5) y:T≥Tmin y: [C]e≤ [C] max from (3.4) y: [C]e≥ [C] min y:τ≤τmax (4.6) the functions X(y) are then the solutions (3.10) of the kinetic model (3.6) with initial conditions (4.3). 5. MCO implementation modules 5.1. MCO solver and associated wrappers for MCO problem set-up The description of the implementation modules used in the prototype implementation of the batch reactor example starts from the central result: a point-wise approximation of the Pareto front. 18 6. Optimal experimental design 6.1. Introduction to optimal design of experiment/simulation for continuous problems ToDo: include the basic ideas behind DoE/DoS. 7. Acknowledgement The compilation of this training material had been funded by the European Commission under the H2020 programme, project BatCAT, Grant Agreement No.101137725. 8. References References [1] Unkown, Wikipedia, https://en.wikipedia.org/wiki/Nonlinear_programming , Nonlinear Programming (2017). [2] Unkown, Wikipedia, https://en.wikipedia.org/wiki/Karush-Kuhn-Tucker_conditions , Karush-Kuhn-Tucker conditions (2017). 25