BatCAT deliverable 4.1: Data landscape and infrastructure related requirements

101137725/BatCAT/WP4/D4.1 D4.1: Data landscape and infrastructure related requirements 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: WP4 – Knowledge Integration Due date: 30.09.2024 Actual submission date: 30.09.2024 Responsible beneficiary: UKRI Dissemination level2: Public (PU) Version: V1.0 Abstract: This document summarizes the results of BatCAT tasks T4.1 and T4.3. Its main contributions are: an analysis and prioritization of concrete optimization problems to be addressed by the project, a list of user stories formulating requirements for the various architecture components, and a set of competency questions that will serve as input for the ontology development. All the information was gathered via interviews, questionnaires, collaborative workshops and inter-work package exchanges. 1 Deliverable type: R = Report, P = Prototype, D = Demonstrator, O = Other. 2 Dissemination level: PU = Public, SEN = Sensitive. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 2 of 51 THIS PAGE IS INTENTIONALLY LEFT BLANK 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 3 of 51 Author list Beneficiary Name Contact e-mail UKRI Silvia Chiacchiera [email protected] NMBU Martin T. Horsch [email protected] NMBU Fadi Al Machot fadi.al.macho[email protected] NMBU Dmytro Romanov dmytro.rom[email protected]o IFPEN Martin Petit martin.peti[email protected] IFPEN Carlos Nieto Draghi [email protected] SIMULA Eirik Valseth [email protected] CPI Danya Senthilkumar [email protected] NIC Sara Drvarič Talian [email protected] IS Timm Fitschen [email protected] NIC Blaž Likozar [email protected] UKRI Ilian Todorov [email protected] UKRI Noel Vizcaino noel.vizcain[email protected] AAU Mohamed El Bahnasawi [email protected] AAU Kyandoghere Kyamakya [email protected] AAU Martin Gebser [email protected] VANEVO Andreas Linhart andreas.linh[email protected]e CPI Katharina Roettger [email protected] CPI Robert Mitchell robert.mitch[email protected]m CPI Diana Mehta (previously at CPI) Document history Version Date Reason/comment Revised by 0.8 15/09/2024 Version for internal review Silvia Chiacchiera (UKRI), Dmytro Romanov (NMBU), input by all coauthors 0.9 26/09/2024 Addressed feedback by reviewers, proofreading Review by I. Castelli, M. Gebser, F. Al Machot. Changes implemented by S. Chiacchiera, T. Fitschen, input by all. 0.95 27/09 Removed track changes, final corrections S. Chiacchiera 1.0 27/09 Final formatting, cross-reference verification D. Romanov 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. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 4 of 51 Abbreviations and acronyms API Application Programming Interface ASP Answer Set Programming CQ Competency Question EQ Example Query DFT Density Functional Theory DKMS Data and Knowledge Management Software DoE Design of Experiment DoS Design of Simulation DT Digital Twin ELN Electronic Lab Notebook ERP Enterprise Resource Planning KB Knowledge Base KO Key Objective ID Identifier LIB Lithium-Ion Battery MCO Multi-Criteria Optimisation MC Monte Carlo (method) MD Molecular Dynamics NIB Sodium-Ion Battery OWL Web Ontology Language P2D / P3D Pseudo two dimensional (model) / Pseudo three dimensional (model) RFB Redox Flow Battery SEM Scanning electron microscopy TBD To be defined US User Story XPS X-ray photoelectron spectroscopy Note: For abbreviations related to the BatCAT architecture components see Table 3. In general, abbreviations used as part of identifier tags in tables of the Appendix are defined in the respective sections. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 5 of 51 List of Tables Table 1. Properties and values of tags used for user stories ________________________________________________ 30 Table 2. User stories grouped by epics _________________________________________________________________ 31 Table 3. List of architecture components, abbreviation and main responsible WP ______________________________ 44 Table 4. Properties and values of tags used for CQs, EQs and facts __________________________________________ 45 Table 5. Competency questions and facts ______________________________________________________________ 45 Table 6. Example queries ___________________________________________________________________________ 49 Table 7. Characterization techniques, instruments, evaluated quantities. ____________________________________ 50 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 6 of 51 List of Figures Figure 2.1 The percentage of participants categorized as internal and external. ________________________________ 9 Figure 2.2 The Percentage of Participants Categorized by “role” (omitting the distinction internal/external) _________ 9 Figure 3.1 Overview of data storage and access currently (left) and planned one with BatCAT (right). The complexity of the infrastructure at each site is encapsuled and hidden behind a common gateway, the Peripheral KB Node. _______ 15 Figure 4.1 Overview architecture of BatCAT: components and relations between them _________________________ 16 Figure 4.2 The logic-based scheduling problems ordered by the number of votes ______________________________ 18 Figure 4.3 The MCO problems ordered by the number of votes _____________________________________________ 19 Figure 4.4 The on-Cell logic-based/MCO problems ordered by the number of votes_____________________________ 20 Figure 4.5 The possible machine learning-based prediction problems ordered by the number of votes _____________ 20 Figure 6.1 Snapshot of the webform for the optimization questionnaire (page 1). ______________________________ 22 Figure 6.2. Snapshot of the webform for the optimization questionnaire (page 2) ______________________________ 23 Figure 6.3. Snapshot of the webform for the optimization questionnaire (page 3) ______________________________ 24 Figure 6.4. Snapshot of the webform for the optimization questionnaire (page 4) ______________________________ 25 Figure 6.5. Snapshot of the webform for the optimization questionnaire (page 5) ______________________________ 26 BatCAT has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement no. 101137725. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 7 of 51 Contents 1. Executive summary...................................................................................................................................... 8 2. Methodology ............................................................................................................................................... 8 Interviews ........................................................................................................................................................ 8 Knowledge base optimization questionnaire .................................................................................................. 9 Requirements formulated as user stories and competency questions........................................................... 9 3. Data and metadata landscape ................................................................................................................... 10 Analysis of the answers: simulation data ...................................................................................................... 10 Analysis of the answers: experimental data ................................................................................................. 12 Analysis of the answers: manufacturing/use-case data ................................................................................ 13 Overview of current and future data storage and access ............................................................................. 14 4. Knowledge Base Infrastructure Requirements ......................................................................................... 16 Architecture components .............................................................................................................................. 16 High level analysis of the requirements based on interviews ....................................................................... 16 Functional Requirements .............................................................................................................................. 17 Non-Functional Requirements ...................................................................................................................... 17 Requirements on mappings from high-level to low-level ............................................................................. 18 Optimization questionnaire: analysis of the answers ................................................................................... 18 5. Conclusions ................................................................................................................................................ 21 6. Acknowledgements ................................................................................................................................... 21 Appendix A: Questionnaire on optimization ................................................................................................. 22 Appendix B: Short set of questions to support the data and metadata landscape ...................................... 27 Appendix C: Epics and user stories, including prioritization ......................................................................... 30 Appendix D: Competency questions ............................................................................................................. 45 Appendix E: Characterization techniques and instruments .......................................................................... 50 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 8 of 51 1. Executive summary One of the key aspects of scientific collaboration is exchange of research data and knowledge, their representation and re-usability. Understanding the way BatCAT partners currently handle the research data and knowledge within already established research facilities and understanding their requirements for the project use cases is a necessary step before building the BatCAT data and knowledge management infrastructure. This document addresses the first challenges related to KO4 (Provide a knowledge base to support battery cell manufacturing across processes and partners through a federated, integrated, and semantically enriched data space), namely building the data and metadata landscape (T4.3) and gathering user requirements (T4.1). It summarizes the methodology designed to address them in BatCAT and draws conclusion on their future impact on knowledge infrastructure related tasks of WP4 (T4.2 - Knowledge base for cell manufacturing, T4.4 - Metadata standardization) and WP5 (e.g., T5.2 - Multicriteria optimization and T5.4 - Human-digital interaction). The structure of the document is as follows: In Sec. 2 we summarize the methodology used, especially for interviews, the optimization questionnaire, user stories and competency questions. Then we give in Sec. 3 a high-level summary of the results of the data and metadata landscape questionnaire, with answers grouped into simulation, experimental and manufacturing data. Next Sec. 4 gives an analysis of the requirements gathered from the interviews and the optimization questionnaire. The conclusions are drawn in Sec. 5. In the appendix, the questions we asked are listed (see Appendix A for optimization, and Appendix B for the data landscape). Then, the formulation of requirements in terms of epics and user stories is given in Appendix C, and as competency questions in Appendix D. Finally, Appendix E lists characterization techniques and instruments that will be used within BatCAT. We note that naturally there is some overlap in content between the various formulations of requirements, as the domain described and the overall input material used is the same. However, we believe different formulations offer different perspectives and are valuable as each of them is most suited as input for the following project tasks. 2. Methodology Interviews As a first step, we defined a set of 9 personas (roles), including: Manufacturing use-case owner (internal), Experimentalist (internal or external), Simulation researcher (internal), Digital twin technology user (internal), Developer of a related platform (external), Policy expert (external), Customer (external) and IT Administrator (internal), cf. Appendix C 3 . Then, we identified people that could represent each role and carried out two-stage interviews. Overall, 10 experts were interviewed at least once, and most of them interviewed twice, with each slot lasting 30 minutes, the second slot going more in depth on the topics. As preparatory material, the interviewees were sent various sets of questions, including those in Appendix B, and a questionnaire used by partner IndiScale (IS) for onboarding of users on CaosDB (that will be the core component of the BatCAT data and knowledge management system). We note that the interviews were carried out in close coordination with 3 With internal/external we mean with respect to BatCAT, i.e., whether they work on not on the BatCAT project. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 9 of 51 T6.1 - Industrial and use-case requirements analysis and T7.2 - Citizens’ role and societal and gender dimensions. Knowledge base optimization questionnaire We created a questionnaire as a webform, see Appendix A for snapshots of all its parts. The questionnaire begins with definitions of the proposed optimization problems. Participants then voted on different types of optimization issues, including logic-based, MCO-based, on-chip hybrid problems, and the necessary machine learning-based prediction problems. In total, 19 respondents completed the questionnaire. Figure 2.1 shows how the participants were divided into external and internal. Figure 2.2 shows the distribution of participants in terms of the roles defined in the previous subsection. Figure 2.1 The percentage of participants categorized as internal and external. Figure 2.2 The Percentage of Participants Categorized by “role” (omitting the distinction internal/external) Requirements formulated as user stories and competency questions User stories and competency questions are standard ways to formulate requirements from the user perspective: the first ones are generally used for software engineering 4 , the second one are typical of knowledge engineering (e.g., as part of ontology engineering process). In this section, we briefly describe what they are, how we gathered them, give some examples and outline how they will be used in the rest of the project. User stories and epics are both formulated as: “As <role>, I intend to do <concretely described action> in order to progress toward <overarching objective>.” The difference between the two types is that epics are more general: their action is the objective of multiple user stories, their objective a wider one. Given this structure, we collect the three variable parts (role, concrete 4 M. Cohn, “User Stories Applied: For Agile Software Development”, United Kingdom, Pearson Education, 2004. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 16 of 51 4. Knowledge Base Infrastructure Requirements Architecture components The BatCAT overall architecture is summarized in the figure below. Figure 4.1 Overview architecture of BatCAT: components and relations between them The components are: Decision support system [incl. DoE+DoS] (DSS); Knowledge base – central (KBC); Knowledge base – peripheral (KBP); Real-time environment [incl. actionable models] (RTE); Semantic interoperability layer (SIL); Data and knowledge management software [incl. API] (DKMS); Machine learning predictors [incl. surrogate models] (MLP); Physics-based modelling (PBM); Experimental characterization facilities [incl. ELN] (EXP); Pilots [incl. sensorics / on-line characterization] (PIL); LDS: Large-data storage (LDS); DT visualization and human-computer interaction (DTV). For convenience, they are listed again with their abbreviations in Table 5, Appendix D. There, also an additional category for Non-functional requirements is included. High level analysis of the requirements based on interviews T4.1 focuses on gathering and analysing the knowledge infrastructure requirements for BatCAT project's use cases. This includes the integration of the CaosDB data model and ensuring interoperability with BIG-MAP. The analysis consists of various levels of requirements, from low-level technical specifics to high-level functional needs, working in parallel with the landscape analysis in T4.3. An agile approach has been adopted to facilitate dynamic consultation with a broad spectrum of stakeholders within and outside the BatCAT consortium. After interviewing domain-knowledge experts (representatives of partners within BatCAT) and analysing questionnaires, a list of key requirements was formed. The list can be split into functional and non-functional 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 17 of 51 requirements. By defining them at the early stage of the project each of the project partners can better plan their contribution to the project as well as mitigate risks related to the knowledge base infrastructure. An anonymised list of key requirements extracted from the interviews, questionnaires, and cross-WP exchanges is given in the form of user stories in Appendix C. Below we highlight some of those requirements in a narrative form. Functional Requirements In the second stage of the interviews, several key technical requirements were outlined that are crucial for battery manufacturing and testing systems. The first major requirement is the separation of data into three distinct data vaults. This involves creating an internal vault that stores company-wide data unrelated to specific projects, a second vault that houses project-related data accessible only within the company, and a third common database intended for data that can be shared with external collaborators or across the project partners. This separation ensures that data is securely managed according to its sensitivity and intended use, thereby maintaining the integrity and privacy of both internal and project-specific information. A significant focus is also placed on managing time series data, particularly for individual batteries and cell testing. This requirement highlights the need for robust data storage and retrieval systems that can effectively handle the continuous stream of data generated during battery tests. In case of REDOX flow batteries, the flow rate is identified as a unique and critical parameter that must be accurately captured and analysed. This distinct parameter is crucial for understanding and optimizing the performance of this type of batteries, which operate differently compared to traditional battery types. Another important aspect is the consideration of material properties and manufacturing-related data. Certain project partners recognize that these factors can significantly impact battery performance and parameters. Therefore, the system must be capable of capturing and correlating this data with battery test results to enable comprehensive analysis and improvements in battery design and manufacturing processes. The need for version control and the ability to store iterations in the database is also emphasized. This capability is essential for tracking the evolution of testing procedures, data, and battery designs over time. It ensures that all changes are documented, and historical data is preserved, enabling better analysis and decision-making. The requirement for high-frequency data collection is particularly demanding, with a need to capture a high number of measurements per second at 16-bit resolution, although temperature measurements may require less precision. This level of data granularity is necessary to accurately monitor the performance of batteries under various conditions and to detect any issues or anomalies in real time. One of the project partners has in-house production of Battery Management Systems (BMS), which eliminates the need for third-party electronics. This internal capability allows for greater control over the integration and functionality of the BMS with their testing and data management systems, ensuring that the system meets their specific requirements without reliance on external suppliers. In summary, these key requirements are aimed to improve the design of the future system, helping to develop a highly specialized and secure system for managing battery testing data, with an emphasis on precision, control, and adaptability to accommodate the unique characteristics of different battery types. Non-Functional Requirements Non-functional requirements (NFRs) define the quality attributes, system constraints, or overall characteristics of a system that specify how it should perform, rather than what it should do. Unlike functional requirements, which describe specific behaviours or functions of the system (e.g., "the system must allow users to log in"), 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 18 of 51 non-functional requirements focus on aspects such as performance, security, usability, and scalability. In Appendix D, they are tagged as “NFCT”. Requirements on mappings from high-level to low-level Dedicated internal discussions addressed the mapping needs between low-level (schemas used by CaosDB as well as raw data, e.g. tabular data in csv files), mid-level (the ontologies) and high-level (ASP logic, used within the DSS system). In order for the DSS to query the knowledge base, facts from the knowledge base are to be translated into the representation used by the ASP framework. The main outcome of those was that that the existent CaosDB interfaces already address requirements for the mapping to clingo 6 (a system for ASP). In fact, it is not necessary to use OWL as an intermediate representation of the facts, they could be translated from CaosDB to clingo directly (there are python libraries for both systems). Especially, when working on raw data (say from a SQL data base) the mapping could also affect performance or become an unnecessary burden. However, as modularity, loose coupling and usage of standard technologies are typical non-functional requirements of complex systems a mapping from CaosDB to OWL and from OWL to the ASP framework is a “Should” requirement. Optimization questionnaire: analysis of the answers In this section, the responses to the questionnaire from Appendix A, including the overall votes from both internal and external groups, are presented for the following categories: logic-based, MCO-based, on-chip, and machine learning prediction problems. Figure 4.2 The logic-based scheduling problems ordered by the number of votes 6 See https://potassco.org/ 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 19 of 51 Figure 4.2 shows that regarding the logic-based scheduling problems, “Design of Simulation (DoS)” and “Design of Experiment (DoE)” are the top concerns, each with 9 responses (47.4%). “Energy Consumption Monitoring” follows with 8 responses (42.1%), while “Production Workflow Optimization” and “Quality Control Decision Making” both have 7 responses (36.8%). The least mentioned problems, each with 1 response (5.3%), include “Inventory Management Optimization”, “Equipment Performance Analysis”, and “Human Resource Allocation”. This highlights key areas needing optimization focus, especially in simulation, experimental design, and energy monitoring. Figure 4.3 The MCO problems ordered by the number of votes Figure 4.3 displays the most frequently selected MCO-Optimization Problems, with “Slurry Formulation Optimization” and “Design of Simulation (DoS)” both leading at 9 responses each (45%). Following closely are “Electrode Material Selection”, “Coating Thickness and Uniformity”, “Electrolyte Composition”, and “Design of Experiment (DoE)” each at 8 responses (40%). The least mentioned problem is “Waste Reduction in Manufacturing” with 4 responses (20%). This visualization highlights the areas with the highest perceived optimization needs. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 20 of 51 Figure 4.4 The on-Cell logic-based/MCO problems ordered by the number of votes Figure 4.4 highlights that, regarding on-chip hybrid optimization problems, “Design of Simulation (DoS)” as the most frequently mentioned issue, with 10 responses (52.6%). “Design of Experiment (DoE)” follows closely with 9 responses (47.4%). Both “Cell Capacity Optimization” and “Aging Rate Reduction” received 7 responses each (36.8%). The least cited problems, with only 1 response each (5.3%), include “Voltage Consistency Calibration” and “Safety Mechanism Compliance”. This chart indicates a strong focus on simulation and experimental design as critical optimization areas. Figure 4.5 The possible machine learning-based prediction problems ordered by the number of votes 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 21 of 51 Figure 4.5 illustrates the top Machine Learning-Based Prediction Problems. “Material Performance Prediction” is the most critical, with 66.7% of the votes. “Mapping between Simulation Methods” and “Interpolation between Simulation/Experimental Data” are also highly valued, with 55.6% and 50%, respectively. The chart highlights the importance of predicting performance and ensuring data consistency as well as interpolation accuracy, critical for effective machine learning applications in battery design. 5. Conclusions This document has summarized the methods and results of BatCAT T4.1 and T4.3, and its content will serve as a basis for following project tasks, notably T4.2 - Knowledge base for cell manufacturing, T4.4 - Metadata standardization and optimization tasks from WP5 – Digital Twin technology. We used a combination of interviews, collaborative workshops and questionnaires, mostly with project partners but also with a few representative external experts. As a result, we collected/formulated 56 user stories grouped under 23 epics and about 50 between competency questions and facts, representing the knowledge needed within BatCAT to address the project use cases and requirements for the knowledge-based data infrastructure. All stories and questions are assigned unique identifiers and are tagged along relevant dimensions to facilitate their uptake in the following project tasks (see in particular the mapping of architecture components to WPs). An extensive questionnaire on optimization, answered by 19 participants, provided a ranking of concrete optimization problems for various types, namely logic-based, MCO-based, on-chip, and machine learning prediction problems. This constitutes concrete input for other WPs, especially WP5, by pointing out what concrete scenarios are to be prioritized. This concludes the work of T4.1 and T4.3, and we believe it covers the bulk of information needed. However, the list of requirements will necessarily be a living entity as the project is in its initial phase, and extensions or adjustments could be made based on the project needs as it develops further. 6. Acknowledgements We warmly thank all project partners who participated in the interviews and the interactive workshop of month 6. We also thank the external experts who kindly agreed to be interviewed and answered the questionnaire for their valuable input. We acknowledge use of the BIG-MAP Archive, which among other functionalities enables data sharing within the Battery2030+ network. 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 22 of 51 Appendix A: Questionnaire on optimization Figure 6.1 Snapshot of the webform for the optimization questionnaire (page 1). 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 23 of 51 Figure 6.2. Snapshot of the webform for the optimization questionnaire (page 2) 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 24 of 51 Figure 6.3. Snapshot of the webform for the optimization questionnaire (page 3) 101137725/BatCAT/WP4/D4.1 Public Version v1.0 Page 25 of 51 Figure 6.4. Snapshot of the webform for the optimization questionnaire (page 4) Public Version v1.0 Page 32 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_DI_1 (n/a - epic) DI Track parameters and materials used for manufacturing of flowbatteries that have a unique set of parameters Establish a version control system for iterations of flow batteries (n/a - epic) n/a US_SIL_DI_1 SIL DI Obtain/read set of material IDs prior to manufacturing (QR, Barcode, etc.) EP_DI_1 (Track parameters and materials used for manufacturing of flow-batteries that have a unique set of parameters) EP_DI_1 S US_EXP_DI_1 EXP DI Perform required test on assembled batteries, store data, link it to materials used EP_DI_1 (Track parameters and materials used for manufacturing of flow-batteries that have a unique set of parameters) EP_DI_1 M US_KBP_DI_1 KBP DI Save the data obtained during testing and create a new state in the version control EP_DI_1 (Track parameters and materials used for manufacturing of flow-batteries that have a unique set of parameters) EP_DI_1 M US_KBC_DI_1 KBC DI Compare performance of batteries batch against the simulation model or the ones already existing in the DB EP_DI_1 (Track parameters and materials used for manufacturing of flow-batteries that have a unique set of parameters) EP_DI_1 M EP_DI_2 (n/a - epic) DI Use a transparent digital twin, meeting a series of requirements for reliability and interpretability Comply with all institutional, legal, and customers' requirements for transparency (n/a - epic) n/a US_DTV_DI_1 DTV DI Clearly distinguish and eventually compare the actual/measured and the predicted values for the various battery properties and other manufacturing parameters EP_DI_2 (Use a transparent digital twin, meeting a series of requirements for reliability and interpretability) EP_DI_2 S US_DTV_DI_2 DTV DI Be able to clearly see what control parameters can/cannot be tuned in a certain manufacturing process EP_DI_2 (Use a transparent digital twin, meeting a series of requirements for reliability and interpretability) EP_DI_2 C Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 33 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity US_KBC_DI_2 KBC DI For statements (and metadata values) in the KB, knowing whether they were manually or automatically generated (in case there is a nonnegligible fraction of statements of the second type). For example: was the data "topic" assigned manually or by an NLP tool? EP_DI_2 (Use a transparent digital twin, meeting a series of requirements for reliability and interpretability) EP_DI_2 M US_DTV_DI_3 DTV DI Be able to select options in an easy and coarse way, for example as a traffic light system (good, middle, bad), for properties where this is meaningful. [I would still like to know how that is assigned, e.g., how was a parameter space binned into three regions] EP_DI_2 (Use a transparent digital twin, meeting a series of requirements for reliability and interpretability) EP_DI_2 S US_KBC_DI_2 KBC DI Clearly know whether data are "raw" (i.e., as produced by a software/device) or were "processed" in some way. Which devices/tools (name+version+URL to info) generated and eventually processed it. EP_DI_2 (Use a transparent digital twin, meeting a series of requirements for reliability and interpretability) EP_DI_2 M Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 34 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_DI_3 (n/a - epic) DI Make informed decisions on the selection and use of ML models Comply with all institutional, legal, and customers' requirements for transparency (n/a - epic) n/a US_MLP_DI_1 MLP DI Select ML predictors / simulations that work in real-time or faster or slower, and select whether they are for short term or long term (usually, in ML, long term means more than 7 points in the future) EP_DI_3 (Make informed decisions on the selection and use of ML models) EP_DI_3 S US_MLP_DI_2 MLP DI Access/know the level of accuracy of a ML predictor (e.g., as defined by the mean square relative error between ground truth and prediction) - (e.g., 0.0X, 0.00X - per cent or per mille) EP_DI_3 (Make informed decisions on the selection and use of ML models) EP_DI_3 M EP_EI_1 (n/a - epic) EI Track the whole history (across laboratories) of each experimental sample being characterized in BatCAT Gathering complete experimental data on batteries (n/a - epic) n/a US_KBC_EI_1 KBC EI Assign a unique identifier to each sample within my lab and across BatCAT EP_EI_1 (Track the whole history (across laboratories) of each experimental sample being characterized in BatCAT) EP_EI_1 M US_EXP_EI_1 EXP EI Record all the sample input and preparation conditions (synthesis procedure, vendor of materials) EP_EI_1 (Track the whole history (across laboratories) of each experimental sample being characterized in BatCAT) EP_EI_1 M US_KBP_EI_1 KBP EI Record all processes undergone by a sample, including artificial / accelerated ageing EP_EI_1 (Track the whole history (across laboratories) of each experimental sample being characterized in BatCAT) EP_EI_1 M US_EXP_EI_2 EXP EI Record information on the experimental device used (vendor, machine/equipment ID/number, channel ID/number) for characterization, as part of metadata for characterization data EP_EI_1 (Track the whole history (across laboratories) of each experimental sample being characterized in BatCAT) EP_EI_1 C Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 35 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_EI_2 (n/a - epic) EI Efficient integration of (experimental) data from multiple sources into a single knowledge base Efficient data interoperability across institutions and over time (n/a - epic) n/a US_EXP_EI_3 EXP EI Upload data from my experimental device (e.g., potentiostat/galvanostat) to ELN/OpenSemanticLab directly (with little, and ideally no manual input needed) EP_EI_2 (Efficient integration of (experimental) data from multiple sources into a single knowledge base) EP_EI_2 C US_KBP_EI_2 KBP EI Track new (i.e., previously not recorded) metadata for my experimental data EP_EI_2 (Efficient integration of (experimental) data from multiple sources into a single knowledge base) EP_EI_2 C US_EXP_EI_4 EXP EI Use the metadata schema which has been agreed upon within the consortium to annotate my data EP_EI_2 (Efficient integration of (experimental) data from multiple sources into a single knowledge base) EP_EI_2 S US_KBC_EI_2 KBC EI Export a collection of data sets with metadata attached in order to publish my results EP_EI_2 (Efficient integration of (experimental) data from multiple sources into a single knowledge base) EP_EI_2 C EP_EI_3 (n/a - epic) EI Classify and categorize scrap materials from manufacturing, returning results to pilot operator and/or supplier Use experimental facilities to reduce the scrap rate in battery manufacturing (n/a - epic) n/a US_EXP_EI_5 EXP EI Record parameters and metadata of a material received from a supplier EP_EI_3 (Classify and categorize scrap materials from manufacturing, returning results to pilot operator and/or supplier) EP_EI_3 US_PIL_EI_1 PIL EI Record parameters obtained during testing of battery performance and link them against the materials used EP_EI_3 (Classify and categorize scrap materials from manufacturing, returning results to pilot operator and/or supplier) EP_EI_3 US_EXP_EI_6 EXP EI Rate materials performance EP_EI_3 (Classify and categorize scrap materials from manufacturing, returning results to pilot operator and/or supplier) EP_EI_3 Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 36 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_EI_4 (n/a - epic) EI Work with the BatCAT data space and the ELN as part of my established work routines the way they are now, with minimal required modifications Have consistent research workflows and keep doing experiments and reporting according to our established practices (n/a - epic) n/a US_EXP_EI_7 EXP EI Login with the user account of my home institution, because I don't want to sign-up for just another system EP_EI_4 (Work with the BatCAT data space and the ELN as part of my established work routines the way they are now, with minimal required modifications) EP_EI_4 C9 US_KBC_EI_3 KBC EI Search the BatCAT data space from a central entry point in order to have access to data that is spread over peripheral systems without the need to actually access all of those systems separately EP_EI_4 (Work with the BatCAT data space and the ELN as part of my established work routines the way they are now, with minimal required modifications) EP_EI_4 M US_DKMS_EI_1 DKMS EI Access the knowledge base via my personal computer, laptop, or mobile phone regardless of my operating system because otherwise I don't want to install more software on my devices and I want to connect using different devices from time to time (lab, office, home, traveling) EP_EI_4 (Work with the BatCAT data space and the ELN as part of my established work routines the way they are now, with minimal required modifications) EP_EI_4 S EP_EI_5 (n/a - epic) EI Ensure that the experiments done in BatCAT are the experiments that are needed Make effective use of our working hours and technical/laboratory equipment (and materials) (n/a - epic) n/a US_DSS_EI_1 DSS EI Access DoE functionality and obtain a set of recommendations for experiments required by a materials set to best complement all that already is known EP_EI_5 (Ensure that the experiments done in BatCAT are the experiments that are needed) EP_EI_5 M Table 2. User stories grouped by epics (continuation) 9 We note that ORCID could alternatively be used, as all researchers involved will have one. Public Version v1.0 Page 37 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_MI_1 (n/a - epic) MI Only use a digital tool in a production environment if it is trustworthy and reliable, including a clear assessment of numerical uncertainty throughout Comply with all institutional, legal, and customers' requirements for operational reliability (n/a - epic) n/a US_KBC_MI_1 KBC MI Obtain uncertainty metric(s) associated with every quantitative value that I obtain from anything developed in BatCAT EP_MI_1 (Only use a digital tool in a production environment if it is trustworthy and reliable, including a clear assessment of numerical uncertainty throughout) EP_MI_1 M US_RTE_MI_1 RTE MI Confidence intervals and clear/reliable assertions on the operational limitations (valid operating conditions) must be present for any recommendation or intervention by the actionable modelling EP_MI_1 (Only use a digital tool in a production environment if it is trustworthy and reliable, including a clear assessment of numerical uncertainty throughout) EP_MI_1 M EP_MI_2 (n/a - epic) MI Make good use of resources within the BatCAT project, without jeopardizing process safety Make effective use of our working hours and technical/laboratory equipment (and materials) (n/a - epic) n/a US_PIL_MI_1 PIL MI Choose sensors' connection type as appropriate for their needed reaction time scales (e.g., fastest ones for safety-critical measurements) EP_MI_2 (Make good use of resources within the BatCAT project, without jeopardizing process safety) EP_MI_2 M Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 38 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_SI_1 (n/a - epic) SI Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling Contribute meaningfully to a multiphysics simulation project, where lower-level methods pass on quantities to higher-level methods, and eventually to surrogate and actionable modelling (n/a - epic) n/a US_DSS_SI_1 DSS SI Use the MCO-based model parameterization methodology, known from the literature and previous work, for a problem such as parameterizing an ion model in combination with a water model EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 S US_PBM_SI_1 PBM SI Receive the simulation data that are necessary for a surrogate model that feeds into my simulations, e.g., a surrogate model for transport properties in case of the continuum simulaton of VRFB's using FEniCS EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 S US_MLP_SI_1 MLP SI Be able to construct the surrogate models that I will be using myself (not having to request them from a project partner, but doing it directly), including validation and testing and a clear indication of uncertainty/confidence EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 C US_PBM_SI_2 PBM SI Construct a potential modelling workflow that can predict simulation cell/battery system properties/behaviour from known parameters, based on choices available in the knowledge base. EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 S US_DSS_SI_2 DSS SI Determine decision criteria for choosing between potential modelling workflows. These should be stored in the knowledge base. EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 C Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 39 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity US_PBM_SI_3 PBM SI Implement simulation workflows using specific software, licensing and hardware setups (based on available choices in KB). EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 M US_SIL_SI_1 SIL SI Mapping of outputs to inputs between models in a workflow (e.g., I want to map the output of Lattice Boltzmann to input of CFD). Mappings should be stored, retrievable and modifiable. EP_SI_1 (Work with a knowledge base and interoperability environment that makes my simulation workflows efficient and my simulation results easily reusable for surrogate modelling) EP_SI_1 M EP_SI_2 (n/a - epic) Implement quality control in simulation and establish accuracy and validity of simulation workflows/results Contribute meaningfully to a multiphysics simulation project, where lower-level methods pass on quantities to higherlevel methods, and eventually to surrogate and actionable modelling (n/a - epic) n/a US_KBC_SI_1 KBC SI Validate simulation results based on experimental data in the knowledge base; this may require relating simulation data to experimental data in some way (correlations, etc.) EP_SI_2 (implement quality control in simulation and establish accuracy and validity of simulation workflows/results) EP_SI_2 M EP_SI_3 (n/a - epic) SI Exchange data relevant to simulation with the BatCAT data space in a way that does not disrupt simulation and data processing workflows Integrate simulation workflows and/or their results and/or input to them with the BatCAT data space (n/a - epic) n/a US_DKMS_SI_1 DKMS SI Interact with the knowledge base by means of a library in my preferred programming language (e.g. Python, Julia, R?) because I want to fetch and push data automatically and directly from my scripts EP_SI_3 (Exchange data relevant to simulation with the BatCAT data space in a way that does not disrupt simulation and data processing workflows) EP_SI_3 W10 Table 2. User stories grouped by epics (continuation) 10 It is not feasible to work with all people's private favourite programming languages. Public Version v1.0 Page 40 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity US_LDS_SI_1 LDS SI Access (read) and retrieve (get) data from the large data storage at a speed fast enough to not constitute a bottleneck to my work EP_SI_3 (Exchange data relevant to simulation with the BatCAT data space in a way that does not disrupt simulation and data processing workflows) EP_SI_3 M EP_CE_1 (n/a - epic) CE Adhere to my company's high standards on IP protection that typically apply in an industrial setting, e.g., for commercially sensitive data It is simply my job to do this (n/a - epic) n/a US_DKMS_CE_ 1 DKMS CE Being able to use BatCAT tools on my own data, while keeping my data within my company EP_CE_1 (Adhere to my company's high standards on IP protection that typically apply in an industrial setting, e.g., for commercially sensitive data) EP_CE_1 S EP_CE_2 (n/a - epic) CE Employ the BatCAT DT as a robust digital tool that is resilient to changes within its various components and its users' environments Have a resilient digital infrastructure that will not break down once normal changes and updates are done (n/a - epic) n/a US_NFCT_CE_1 NFCT CE Be informed about the governance processes and good practices, specially about maintenance, in place for BatCAT components, and be able to confirm that the processes and practices are resilient EP_CE_2 (Employ the BatCAT DT as a robust digital tool that is resilient to changes within its various components and its users' environments) EP_CE_2 C11 Table 2. User stories grouped by epics (continuation) 11 We are going to TRL 5, so it is not crucial to be able to inform external customers about maintenance. Public Version v1.0 Page 41 of 51 Story ID Design target Role Concretely described action Overarching objective Falls under broader story (ID) Prio rity EP_DE_1 (n/a - epic) DE Enable interoperability and exchange of knowledge, including models and data, on LIB cell manufacturing between KIproBatt and BatCAT Achieve synergy between KIproBatt and other digital twin and battery manufacturing digitalization platforms (n/a - epic) n/a US_SIL_DE_1 SIL DE Use mutually agreed interfaces specified as OOLD schema for data exchange EP_DE_1 (Enable interoperability and exchange of knowledge, including models and data, on LIB cell manufacturing between KIproBatt and BatCAT) EP_DE_1 M US_SIL_DE_2 SIL DE Rely on agreed domain ontologies that go beyond what has been standardized so far; this must account for the concepts listed in the KIproBatt wiki (e.g., separator foil, https://kiprobatt.de/wiki/ Category:OSLa24dc426cfb 44c8a93c18e176147c593) EP_DE_1 (Enable interoperability and exchange of knowledge, including models and data, on LIB cell manufacturing between KIproBatt and BatCAT) EP_DE_1 M US_KBC_DE_1 KBC DE Mutually recognize PIDs for all elements on which information is exchanged, including surrogate models, samples, sensors, and characterization and manufacturing equipment EP_DE_1 (Enable interoperability and exchange of knowledge, including models and data, on LIB cell manufacturing between KIproBatt and BatCAT) EP_DE_1 C EP_DE_2 (n/a - epic) DE Develop metadata standards such that they can be used across organizations and projects without unnecessary redundant work such as adjusting the expressivity multiple times Efficient data interoperability across institutions and over time (n/a - epic) n/a US_SIL_DE_3 SIL DE Follow a design specification for the ontologies for epistemic metadata that is in line with the requirements of ASP reasoning and the KGA XAIR WG's requirements EP_DE_2 (Develop metadata standards such that they can be used across organizations and projects without unnecessary redundant work such as adjusting the expressivity multiple times) EP_DE_2 C Table 2. User stories grouped by epics (continuation) Public Version v1.0 Page 48 of 51 ID Competency Question (CQ) / Natural language sentence (fact) (FA) Answer [for questions only] CQ_MAN_3.2 What are the sensor types for on-line characterization of LIB? Thermocouples, Accelerometer + vibration sensor, Power monitoring clip, CO / CO2 sensor, Pressure sensor, Laser profilometer CQ_MAN_4 What are the main (manufacturing) quantities to monitor? Energy consumption, Equipment performance, Waste produced (amount), Product quality CQ_MAN_5.1 What are the main ordered steps in the LIB/NIB manufacturing process? Mixing, Coating, Drying, Calendering, Cutting, Assembly, Filling, Forming, Degasing CQ_MAN_5.2 What are the main ordered steps in the RFB manufacturing process? (Incoming goods inspection), Stack assembly, Stack compression, Stack sealing (glueing), (Stack testing), Tanks: Assembly stacks+Piping+Periphery, (Tanks testing) CQ_MAN_6.1 What are the LIB/NIB battery (product) design parameters? Active material choice, Formulation, Particle Size Disitribution (PSD), Electrolyte composition, Separator, Size CQ_MAN_6.2 What are the RFB battery (product) design parameters? Current density, Ion species concentration, Electrode base material, Volume flow rate, Product dimensions CQ_MAN_6.3 What are the battery operating conditions? TBD CQ_MAN_7.1 What are the control/process parameters of the LIB/NIB manufacturing process? Solvent choice, Mixing protocol, Coating gap, Coating speed, Pump speed, Drying temperature, Drying speed, Calendering thickness, Electrode geometry, Electrolyte volume, Soak conditions, Formation protocol CQ_MAN_7.2 What are the control/process parameters of the RFB manufacturing process? Processing atmosphere, Processing time, Processing temperature, Throughput rate CQ_MAN_8.1 What are the variables to evaluate the LIB/NIB manufacturing process? Scrap (rate), Production cost (per unit) CQ_MAN_8.2 What are the variables to evaluate the RFB manufacturing process? Production performance, Production cost, Throughput failure rate CQ_MAN_9.1 What are the LIB/NIB battery product main properties? Initial performance, Ageing, Safety CQ_MAN_9.2 What are the RFB battery product main properties? Efficiency, Capacity, Durability, Round trip efficiency CQ_MAN_10 What are other general input parameters of the manufacturing process? Electricity cost, Personnel cost CQ_MAN_11 How are labels for batches defined (i.e., what parameters of the batch have to be included as part of a label)? E.g., template of a string in format could be: '%BATCH_NUMBER%_%WEEK%%YEAR%_%BASE_MATE RIAL_1%_%BASE_MATERIAL_2%' FA_MAN_1 A sample belongs to a batch n/a - fact Table 5. Competency questions and facts (continuation) Public Version v1.0 Page 49 of 51 ID Competency Question (CQ) / Natural language sentence (fact) (FA) Answer [for questions only] CQ_SIM_1 What force field was used to obtain the (molecular) simulation results? n/a - case-specific CQ_SIM_2 Are these input data compatible (=directly usable) by software X (version V)? Yes, No CQ_SIM_3 What are the modelling approaches for LiB? Atomistic & electronic models (Ab initio DFT Reactive MD Classical MC/MD); Mesoscopic models; Electrode models (4D resolved Phase field); Cell models (P3D, P2D, SP Circuit model) CQ_SIM_4 What are the modelling approaches for RFB? Atomistic models (Ab initio DFT Reactive MD Classical MC/MD); Continuum models for flow field (porous media flow), and electrochemistry (Poisson-NernstPlanck, possibly others) FA_SIM_1 Surrogate models can be classified by the dimensionality of input and output fed to the neural network (e.g., input can be numbers, geometry/image, a transient; predict a scalar quantity - 0D, local quantity (field), replace an equation - 4D) n/a - fact Table 5. Competency questions and facts (continuation) ID Example Query (EQ) Answer EQ_EXP_1 What is the measured value of the property Z (e.g., porosity) of the electrode material synthesized according to X and Y synthesis parameters? n/a - EQ, answer will be case specific EQ_SIM_1 What models/parametrizations of a certain class (e.g., DPD) can be applied to a certain system (e.g., water with vanadium ions)? n/a - EQ, answer will be case specific Table 6. Example queries Public Version v1.0 Page 50 of 51 Appendix E: Characterization techniques and instruments In this section, we list the main characterization techniques that will be used within BatCAT, and the mapping to the instruments used. For each technique, its high-level type, the battery types it applies to and the quantities evaluated are given as well. The first table is for techniques of electrochemical type, the second one for physicochemical and rheology ones. This information complements what is given as competency questions in Appendix D and will also serve as an input for the BatCAT ontology development. High level characterization type Characterization technique Instrument used Battery type Quantity evaluated Electrochemical Calendar aging Potentiostat LIB/NIB, RFB Full cell aging Electrochemical Charge test Potentiostat LIB/NIB Charge capabilities Electrochemical Charge test Potentiostat RFB Performance Electrochemical Conductivity measurement Conductivity probe LIB/NIB Electrode conductivity Electrochemical Cyclic voltametry Potentiostat RFB Electrolyte electrochemical properties Electrochemical Cycling Potentiostat LIB/NIB, RFB Full cell aging Electrochemical Discharge test Potentiostat LIB/NIB Full cell capacity Electrochemical Discharge test Potentiostat RFB Performance Electrochemical Duty profile test Potentiostat RFB Round trip efficiency Electrochemical EIS test Potentiostat LIB/NIB Impedance Electrochemical GITT test Potentiostat LIB/NIB Diffusion coefficient, Active material potentials Electrochemical HPPC test Potentiostat LIB/NIB OCV and resistance/Full cell power Electrochemical Road profile test Potentiostat LIB/NIB Round trip efficiency Table 7. Characterization techniques, instruments, evaluated quantities. Public Version v1.0 Page 51 of 51 High level characterization type Characterization technique Instrument used Battery type Quantity evaluated Physicochemical BET measurement BET surface area analyzer RFB Active surface area Physicochemical Conductivity measurement Electrochemical impedance spectroscopy (EIS). RFB Felt conductivity Physicochemical Direct measurement Palmer RFB Membrane thickness Physicochemical Electrode thickness assessment Palmer LIB/NIB Coating thickness Physicochemical Hg porosimetry Porosimeter LIB/NIB Electrode porosity Physicochemical Porosimetry Porosimeter RFB Felt porosity Physicochemical Raman Raman LIB/NIB Morphology and composition Physicochemical Raman Raman RFB Felt surface properties Physicochemical SEM SEM LIB/NIB Microscopic geometry/ Active material granulometry/ Electrode tortuosity Physicochemical SEM SEM RFB Felt surface properties Physicochemical XPS XPS LIB/NIB Morphology and composition Physicochemical XPS XPS RFB Felt surface properties Rheology Pressure drop measurement Pressure flow sensor (within single cell test bench) RFB Pressure drop Table 7. Characterization techniques, instruments, evaluated quantities (continuation).