Generation and processing of data associated with batteries in decentral systems

Abstract

The invention relates to the field of sustainability, in particular to the field of sustainable industrialization. The disclosure relates to methods, apparatuses, systems, and computer elements for generating a component data set associated with components of a battery. The disclosure further relates to methods, apparatuses, systems, and computer elements for validating component data associated with component(s) of batteries. The disclosure further relates to the use of validated component data associated with battery component(s) as generated herein to generate battery passports associated with batteries produced at least in part from such component(s).

Description

[0001] GENERATION AND PROCESSING OF DATA ASSOCIATED WITH BATTERIES IN DECENTRAL SYSTEMS

[0002] TECHNICAL FIELD

[0003] The invention relates to the field of sustainability, in particular to the field of sustainable industrialization. The disclosure relates to methods, apparatuses, systems, and computer elements for generating a component data set associated with components of a battery. The disclosure further relates to methods, apparatuses, systems, and computer elements for validating component data associated with component(s) of batteries. The disclosure further relates to the use of validated component data associated with component(s) of batteries as generated herein to generate battery passports associated with batteries produced at least in part from such component(s).

[0004] TECHNICAL BACKGROUND

[0005] In the supply and production of products multiple regulatory requirements need to be met, which differ depending on the product. To fulfil such regulatory requirements, data on such products may need to be exchanged between different participants involved in the production and use of such products. Such data may be exchanged in a secure and controlled manner within a decentral network connecting different participants involved in the production and / or recycling of the product. Owing to the transfer of highly standardized data packages within the decentral network, generation of such data packages is cumbersome in handling, especially for various supply chain participants. Hence, there is a need to simply generation of data packages, in particular for production input(s) used to produce the product, which can be exchanged via a decentral network while at the same time ensuring transfer of all data required for further processing, such as for generation of chemical product passports associated with the product.

[0006] SUMMARY OF THE INVENTION

[0007] Disclosed is in one aspect a method in particular a computer-implemented method, for generating a component data set associated with a battery component, wherein the battery component is used as input material to produce at least one battery, the method comprising:

[0008] • providing data associated with the battery component including at least one component identifier;

[0009] • gathering - based on the provided data associated with the battery component - component data from one or more databases;

[0010] • generating the component data set by transforming the gathered component data using a rulebased engine including one or more rule(s) associated with at least one of the batteries;

[0011] • providing the generated component data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set. In a further aspect disclosed is an apparatus for generating a component t data set associated with a battery component , wherein the battery component is used as input material to produce at least one battery, the apparatus comprising:

[0012] • a data providing interface configured to provide data associated with the battery component including at least one battery component identifier;

[0013] • a data gathering unit configured to gather - based on the provided data associated with the battery component - component data from one or more databases;

[0014] • a data set generator configured to generate the component data set by transforming the gathered component data using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0015] • a decentral network interface configured to provide the generated component data for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set.

[0016] In yet a further aspect disclosed is a system for generating a component data set associated with a battery component , wherein the battery component is used as input material to produce at least one battery, the system comprising:

[0017] • a data source layer configured to provide component data from one or more data source(s),

[0018] • a data consumer layer configured to gather the component data provided by the one or more data source(s) containing one or more data instances that relate to the battery component;

[0019] • a data transformer layer configured to generate the component data set by transforming the gathered component data using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0020] • a connector layer to a decentral network configured to provide the generated component data for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set.

[0021] In yet a further aspect disclosed is a method in particular a computer-implemented method, for generating a component data set associated with a battery component, wherein the battery component is used as input material to produce at least one battery, the method comprising:

[0022] • receiving via a decentral network incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data;

[0023] • gathering - based on the received incident data - component data associated with the battery component;

[0024] • updating one or more rule(s) associated with the battery component based on the received incident data;

[0025] • generating an updated component data set by transforming the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries, wherein at least one of the rule(s) is an updated rule; • providing the generated updated component data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set.

[0026] In yet a further aspect disclosed is an apparatus for generating a component data set associated with a battery component, wherein the battery component is used as input material to produce at least one battery, the apparatus comprising:

[0027] • a decentral network interface configured to receive via a decentral network incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data;

[0028] • a data gathering unit configured to gather - based on the received incident data - component data associated with the battery component;

[0029] • a rule updater configured to update one or more rule(s) associated with the battery component based on the received incident data;

[0030] • a data transformer configured to generate an updated component data set by transforming the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries, wherein at least one of the rule(s) is an updated rule;

[0031] • a decentral network interface configured to provide the generated component data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set.

[0032] In yet a further aspect disclosed is a system for generating a component data set associated with a battery component, wherein the battery component is used as input material to produce at least one battery, the system comprising:

[0033] • a connector layer to a decentral network configured to receive via a decentral network incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data;

[0034] • a data source layer configured to provide component data from one or more data source(s),

[0035] • a data consuming layer configured to gather - based on the received incident data - component data associated with the battery component;

[0036] • a rule updater configured to update one or more rule(s) associated with the battery component based on the received incident data;

[0037] • a data transformer layer configured to generate an updated component data set by transforming the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries, wherein at least one of the rule(s) is an updated rule;

[0038] • a connector layer to the decentral network configured to provide the generated updated component data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set. In yet a further aspect disclosed is a method in particular a computer-implemented method, for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the method comprising:

[0039] • providing battery data including battery identifier(s) and component identifier(s) associated with the battery component(s);

[0040] • obtaining the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on the provided component identifier(s) in particular wherein the component data is generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein;

[0041] • validating at least a part of the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0042] • linking the validated component data to at least one of the battery identifiers;

[0043] • determine storage location(s) for the validated component data based on component identifier(s) associated with the validated component data;

[0044] • providing the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data.

[0045] In yet a further aspect disclosed is a method in particular a computer-implemented method, for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the method comprising:

[0046] • providing battery data including battery identifier(s) and component identifier(s) associated with the battery component(s);

[0047] • obtaining the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on the provided component identifier(s) in particular wherein the component data is generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein;

[0048] • validating at least a part of the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0049] • linking the validated component data to at least one of the battery identifiers;

[0050] • providing the validated component data linked to the battery identifier(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data.

[0051] In yet a further aspect disclosed is an apparatus for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising: • a battery data providing interface configured to provide battery data including battery identifier(s) and component identifier(s) associated with the battery component(s);

[0052] • a decentral network interface configured to obtain the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on the provided component identifier(s), in particular wherein the component data is generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein;

[0053] • a data validator configured to validate at least a part of the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0054] • a linking unit configured to link the validated input component to at least one of the battery identifiers;

[0055] • a storage determinator configured to determine storage location(s) for the validated component data based on component identifier(s) associated with the validated component data;

[0056] • a validated data providing interface configured to provide the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data.

[0057] In yet a further aspect disclosed is an apparatus for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising:

[0058] • a battery data providing interface configured to provide battery data including battery identifier(s) and component identifier(s) associated with the battery component(s);

[0059] • a decentral network interface configured to obtain the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on the provided component identifier(s), in particular wherein the component data is generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein;

[0060] • a data validator configured to validate at least a part of the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0061] • a linking unit configured to link the validated input component to at least one of the battery identifiers;

[0062] • a validated data providing interface configured to provide the validated component data linked to the battery identifier(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data.

[0063] In yet a further aspect disclosed is a system for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising: • a connector layer to a decentral network configured to obtain the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on component identifier(s) associated with the battery component(s), in particular wherein the component data is generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein;

[0064] • a service layer including one or more input node(s) configured to gather the component data provided by the connector layer and to provide the gathered component data as component data set(s) to one or more downstream node(s),

[0065] • a data validation layer comprising the one or more downstream node(s) and configured to o validate at least a part of the component data set(s) provided by the service layer by using a rule-based engine including one or more rule(s) associated with at least one of the batteries, o link the validated component data to at least one of the battery identifiers, o determine storage location(s) for the validated component data based on component identifier(s) associated with the validated component data, o provide the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data,

[0066] • a storage layer comprising one or more databases and configured to store the provided validated component data.

[0067] In yet a further aspect disclosed is a system for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising:

[0068] • a connector layer to a decentral network configured to obtain the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on component identifier(s) associated with the battery component(s), in particular wherein the component data is generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein;

[0069] • a service layer including one or more input node(s) configured to gather the component data provided by the connector layer and to provide the gathered component data as component data set(s) to one or more downstream node(s),

[0070] • a data validation layer comprising the one or more downstream node(s) and configured to o validate at least a part of the component data set(s) provided by the service layer by using a rule-based engine including one or more rule(s) associated with at least one of the batteries, o link the validated component data to at least one of the battery identifiers, o provide the validated component data linked to the battery identifier(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data,

[0071] • a storage layer comprising one or more databases and configured to store the provided validated component data.

[0072] In yet a further aspect disclosed is a method, in particular a computer-implemented method, for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the method comprising:

[0073] • generating incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data;

[0074] • providing the generated incident data via a decentral network to the decentral data providing node associated with the non-validated component data,

[0075] • receiving updated component data from the decentral data providing node(s) via the decentral network;

[0076] • validating at least a part of the updated component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0077] • linking the validated component data to at least one associated battery identifier;

[0078] • determining storage location(s) for the validated component data based on component identifier(s) associated with the validated component data;

[0079] • providing the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data.

[0080] In yet a further aspect disclosed is an apparatus for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising:

[0081] • an incident data generator configured to generate incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data;

[0082] • a decentral network interface configured to provide the generated incident data via a decentral network to the decentral data providing node associated with the non-validated component data,

[0083] • a decentral network interface configured to receive updated component data from the decentral data providing node(s) via the decentral network;

[0084] • a data validator configured to validate at least a part of the updated component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries;

[0085] • a linking unit configured to link the validated component data to at least one associated battery identifier; • a storage determinator configured to determine storage location(s) for the validated component data based on component identifier(s) associated with the validated component data;

[0086] • a data providing interface configured to provide the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data.

[0087] In yet a further aspect disclosed is a system for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising:

[0088] • a connector layer to a decentral network configured to o provide generated incident data via a decentral network to the decentral data providing node associated with the non-validated component data, o receive updated component data from the decentral data providing node(s) via the decentral network;

[0089] • a service layer including one or more input node(s) configured to gather the updated component data provided by the connector layer and to provide the gathered updated component data as updated component data set(s) to one or more downstream node(s),

[0090] • a data validation layer comprising the one or more downstream node(s) and configured to o generate the incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data, o validate at least a part of the updated component data set(s) provided by the service layer by using a rule-based engine including one or more rule(s) associated with at least one of the batteries, o link the validated component data to at least one associated battery identifiers, o determine storage location(s) for the validated component data based on component identifier(s) associated with the validated component data, o provide the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with the at least one battery including at least a part of the validated component data,

[0091] • a storage layer comprising one or more databases and configured to store the provided validated component data.

[0092] In yet a further aspect disclosed is a use of the validated component data associated with battery components as generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein for generating battery passports associated with batteries produced at least in part from the battery component(s). In yet another aspect disclosed is a computer element, in particular a computer program product or a computer readable medium, with instructions, which when executed on one or more computing node(s) are configured to carry out the steps of any of the methods disclosed herein.

[0093] In yet another aspect the present disclosure relates to a computer element with instructions, which when executed on one or more computing node(s) is configured to carry out the steps of the method(s) of the present disclosure or configured to be carried out by the apparatus(es) of the present disclosure.

[0094] Any disclosure, embodiments and examples described herein relate to the methods, the apparatuses, systems, the uses and computer elements lined out above and below. Advantageously, the benefits provided by any of the embodiments and examples equally apply to all other embodiments and examples.

[0095] Embodiments

[0096] In the following, embodiments of the present disclosure will be outlined by ways of embodiments and / or examples. It is to be understood that the present disclosure is not limited to said embodiments and / or examples.

[0097] To enable or improve the exchange of component data associated with component(s) used as input material to produce at least one battery, simple and efficient generation of such component data is crucial. However, sharing of component data set(s) within a decentral network is generally associated with the use of highly complex semantic model(s) or data model(s) to ensure uniform data set(s) containing all required data point(s). Such complex data model(s) are, however, associated with high cost for generation and maintenance. Hence, use of such complex data models makes the generation of component data set(s) a complicated and tedious effort. Such effort may not be feasible for small supplier companies, hence posing a hurdle for sharing component data associated with components produced by such companies within the decentral network.

[0098] By using a rule-based engine including rule(s) associated with at least one battery produced from such component(s) as input material(s), in particular associated with data model(s) of the battery or a battery type the battery is associated with, it can be ensured that component data point(s) required according to the data model, such as an aspect model, associated with the battery or battery type are contained in the component data set, hence avoiding missing data point(s) during generation of a battery passport associated with the batteries using said data model. Since the rule(s) are derived from the data model of the battery or battery type, suppliers producing battery component(s) used in the production of such battery do not necessarily have to use complex data models to generate the component data set(s). Instead, they can use existing complex data model for batteries or battery types and generate the rule(s) based on such existing data models, hence avoiding costly and cumbersome generation of such models for their produced component. By transforming the gathered component data using such rule-based engine, aggregation of the gathered component data into a given data structure, such as a tabular representation, can be achieved without the use of complex data models, hence facilitating simple generation and reliable sharing of component data set(s) within the battery ecosystem. The component data set(s) may be associated with authorization rule(s), hence avoiding unauthorized access to such data and ensuring secure sharing of such data via the decentral network. The component data, such as the tabular representation, may be stored within a dedicated storage associated with the data owner of the component data for consumption of such component data by a decentral data consuming node associated with a data consumer under the control of the data owner. Hence, the component data can be directly consumed based on identifier(s) associated with such component data and endpoint(s) of decentral data providing node(s) associated with the dedicated storage without having to use any intermediary registries, such as decentral registries storing access elements pointing to 'data set(s) generated using highly defined data models.

[0099] By using rule template(s) including unstructured data associated with transformation operation(s), generation of one or more rule(s) may be facilitated using natural language, hence allowing simple and reliable generation of rule(s) based on natural language text, such as user input, contract clauses, etc. In addition, the rule template(s) may be predefined, hence allowing generation of component data set(s) based on given rule template(s) and rule(s), resulting in a further simplification of the generation of the component data set(s).

[0100] By enabling simple generation of component data set(s), such component data set(s) can be reliably shared within a decentral network by supply chain participants who are not familiar with data models or who can't afford to create such complicated data model(s). Such sharing may enable more efficient production and / or recycling processes based on the shared component data, for instance based on component composition data included in the shared component data. By using a decentral network, the generated component data set(s) may be shared in a secure and controlled manner by avoiding access to such data set(s) by unauthorized decentral network participant(s), hence avoiding unwanted transparency on supply chains and / or chemical composition of the component by third parties.

[0101] By using a rule-based engine operating on data point level, multiple data points level or whole data level, it may be ensured that the generated component data set include(s) all component data point(s) required by the data model associated with batteries or battery types. This ensures that battery passports associated with such batteries can be reliably generated from component data gathered via the decentral network, without a risk that required data point(s) are missing, hence resulting in the battery passport having a low data quality. Since it may be required that batteries and / or products containing such batteries which sold to customers are associated with such battery passports, lack of generation of such passports due to missing component data may result in increased storage times of batteries or products including such batteries and may negatively influence downstream participants of the supply chain due to lack of battery and / or battery containing product supply. In addition, low data quality of the battery passports may negatively influence the production of products using the battery and / or the processing of end-of-life batteries based on the data included in the battery passports.

[0102] By validating the component data set(s) generated in a simple and efficient way using a rule-based engine including rules associated with batteries produced using component(s) associated with such data set(s) as production input(s), it can be ensured that the consumed component data set(s) include the data point(s) required by the data model. This allows to avoid missing data points upon generation of battery passports associated with such batteries using the consumed component data. Validation of consumed component data sets by the consumer side ensures that the battery passport contains all data required by a data model used to generate such battery passport, hence allowing to reduce the complexity associated with the component data set generation at the provider side by avoiding the use of complex ata models during generation of the component data set(s) since this complexity is shifted to the consumer side. This may enable reliable sharing of component data of battery component(s) irrespective of the existence of data models for such components since the rule(s) required to transform the gathered component data may be readily derived or generated from the data model associated with batteries or battery types or from data models derived from the data models associated with the batteries or battery types.

[0103] By generating incident data during generation of the component data at the provider side if application of one or more rule(s) by the rule-based engine results in an error (e.g. conditions stipulated in such rule(s) are not fulfilled), updated component data may be generated and provided to the consumer side. This allows to ensure that the generated component data set(s) fulfil the one or more applied rule(s), avoiding validation errors at the consumer side. By generating incident data during validation of the component data at the consumer side, data providers may be enabled to generate updated component data set(s) fulfilling the validation rule(s) used by the rule-based engine at the consumer side. By using the incident data at the provider side to update rule(s) included in the rule-based engine transforming the gathered component data ensures that component data set(s) fulfilling the validation rule(s) used at the consumer side is generated, hence reducing the occurrence of errors and delays in the generation of battery passports.

[0104] Various units, entities, nodes or other computing components may be described as “configured to” perform a task or tasks. Configured to shall recite structure meaning “having circuitry that” performs the task or tasks on operation. The units, circuits, entities, nodes or other computing components can be configured to perform the task even when the unit / circuit / component is not operating. The units, circuits, entities, nodes or other computing components that form the structure corresponding to “configured to” may include hardware circuits and / or memory storing program instructions executable to implement the operation. The units, circuits, entities, nodes or other computing components may be described as performing a task or tasks, for convenience in the description. Such descriptions shall be interpreted as including the phrase “configured to.” In general, the methods, apparatuses, systems, computer elements, nodes or other computing components described herein may include memory, software components and hardware components. The memory can include volatile memory such as static or dynamic random-access memory and / or nonvolatile memory such as optical or magnetic disk storage, flash memory, programmable read-only memories, etc. The hardware components may include any combination of combinatoric logic circuitry, clocked storage devices such as flops, registers, latches, etc., finite state machines, memory such as static random-access memory or embedded dynamic random-access memory, custom designed circuitry, programmable logic arrays, etc.

[0105] The method for generating the component data set may be executed by one or more computing node(s) associated with a production producing the battery component. The method for generating the component data set may be executed by one or more computing node(s) associated with a component producer. The component producer may operate the production. The method for validating the component data may be executed by one or more computing node(s) associated with a production producing the battery. The method for validating the component data may be executed by one or more computing node(s) associated with a battery producer. The method for validating the component data may be executed by one or more computing node(s) associated with a production producing the battery.

[0106] A component may refer to any component which is used to produce a battery. The component may be a discrete component. The component may be an electrode, a battery cell, a battery module, a battery management system, a cooling system, a housing, a separator or a mechanical subsystem. The component may be a chemical product. The component may be a metal, a metal salt, an anode material, a cathode active material, an electrolyte or a polymer. The battery may be produced by one or more production chains. The production chains may include one or more production stages or steps. The component may be any supply chain product produced by upstream production stages with respect to the battery production stage. The component may be used in at least one of the production steps associated with the production of the battery. The component may be associated with a component identifier. The component identifier may be a digital or virtual component identifier. The component identifier may uniquely identify the component within the entity producing the component. The component identifier may uniquely identify the component within the decentral network. The component identifier may be associated with an identifier element physically connected to the component. The identifier element may encode the digital component identifier. The component identifier may include a component name, a component number, a LOT number, a batch number, a serial number or a combination thereof.

[0107] The components may be associated with the component data sets (e.g. assets). The component data set may include a component identifier associated with the component data set and component data transformed by the rule-based engine. The component identifier may be associated with the c component. The component identifier, e.g. the asset identifier, may be different from the digital component identifier uniquely identifying the component within the component production. The component identifier may not be discoverable by participant nodes of the decentral network. The component identifier may not be accessible within the decentral network for participant nodes of the decentral network.

[0108] The component and the battery may be part of a battery ecosystem. The battery ecosystem may include chemical products. The battery ecosystem may include production chains to produce a battery. The production chain(s) may include one or more production stage(s). The production stages may include component production stage(s) producing the component(s) and the battery stage producing the battery. A component produced by an upstream production stage may be used as production input by a downstream production stage. The downstream production stage may be a further component production stage or the battery production stage. The component may be used as production input in any of the downstream production stages associated with the production of the battery. The battery ecosystem may include production chains to produce a battery containing end product. The battery ecosystem may include processing chains to process used batteries resulting from the use of produced batteries. Processing chains may include recycling chains to recycle at least part of the used batteries or a component thereof. Processing chains may include re-use chains to re-use the used batteries. The battery ecosystem may include various participants, such as raw input material producers, chemical product producers, battery producers, end-product producers, end-product users, EOL product collectors and recyclers. The battery ecosystem may allow to use of recycled materials resulting from recycling of end-of-life end batteries or parts thereof to produce new products, such as chemical products. The battery ecosystem may be associated with the production and / or re-use and / or recycling of physical batteries or parts thereof.

[0109] The participants of the battery ecosystem may be connected via a decentral network. The decentral network may include one or more decentral network node(s) configured to perform data transactions. The decentral network node(s) may be associated with participants of the battery ecosystem. The data transactions may be based on a transaction protocol including authentication and / or authorization mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer network between decentral network node(s) of the decentral network may be established. The one or more authentication mechanism(s) may be associated with or linked to decentral identifier(s). The one or more authentication mechanism(s) associated with decentral identifier(s) may be provided to decentral network node(s). The one or more authentication mechanism(s) associated with decentral identifier(s) may be accessible by decentral network node(s). The decentral configuration allows for more efficient use of computing resources and strengthens control by each data owner of the decentral network.

[0110] The decentral data providing network node may comprise computer-executable instructions for providing and / or processing data within a decentral network, such as the component data sets, by a decentral data consuming network node. The decentral data providing network node may be associated with or connected to one or more dedicated data storage(s) storing the component data sets. The decentral data providing network node may be directly or indirectly connected to the data storage(s) storing the component data sets. Hence, the decentral data providing network node may be associated with the component data sets. The dedicated data storage(s) may be under control of the data owner of the component data sets. The data owner may be an entity having access to the component data sets and controlling access by data consuming services of the decentral network to the component data sets. The data owner may be the component producer. Via the component identifier and its unique association with the data owner and component data set access to the component data set may be controlled by the data owner. The component data sets may be accessible for the data owner. The data owner may hence directly or indirectly own the component data sets. The component data sets may be stored in a database of or associated with the data owner. The component data sets may be stored in a database accessible by the data owner. The data owner may control access to the component data sets via the data providing service of the data owner. The data owner may control access to the component sets. The component sets may be associated with the data owner. The data owner may be the owner of the component data sets or the component data set owner. The component data sets may be stored in a data base of or under control by the data owner.

[0111] The decentral data consuming network node may comprise computer-executable instructions for accessing and / or processing data within a decentral network, such as component data, provided by a decentral data providing network node. The decentral data consuming network node may be controlled or owned by or associated with a consumer of the component data (e.g. the entity generating the battery passport). The consumer may be any entity processing the component data. The consumer may be any entity operating a production configured to process the components associated with the component data as input material(s) Processing may include using the components as input materials to produce further battery components or batteries. Processing may include performing one or more recycling step(s) on the battery or components thereof as input material. The consumer may be an upstream participant of the component producer in the product ecosystem.

[0112] A rule-based engine may be used to transform at least part of the gathered component data associated with battery component(s). The rule-based engine may be a software or software component that applies one or more rules to at least part of the gathered component data. The rule(s) may include or correspond to executable logic. The executable logic may be generated from a rule template including unstructured data associated with instructions related to transformation operation(s). The rule-based engine used to transform at least part of the gathered component data may include one or more rule(s) associated with batteries produced from the component (s) (e.g. by using the component as input material(s)). The one or more rule(s) may be associated with or derived from or generated based on a semantic model or data model associated with batteries or battery types. Hence, the one or more rule(s) may ensure that data point(s) for such components required according to the data model may be included in the generated component data set. The one or more rule(s) may be defined by the mandatory component data points present within or defined by the data model. The one or more rule(s) may be generated based on the mandatory component data points present within or defined by the ata model. This may ensure that component data required by the data model is included in the generated component data set. The one or more rule(s) may hence be generated based on or defined by the data model associated with batteries produced from the component(s) as input materials or battery types the batteries are associated with. The one or more rule(s) may hence not be derived or generated based on a data model associated with the produced components. This may allow to avoid generation of complex data models for produced components but may instead allow to use existing data models of batteries or battery types for generation of rule(s) to transform gathered component data to component data set(s).

[0113] The rule-based engine may operate on individual data point level, combination of data points or the whole gathered component data. The operation of the rule-based engine may be defined by the one or more rule(s). The rule(s) may include or correspond to executable logic. The executable logic may be generated from a rule template including unstructured data associated with instructions related to validation operation(s). Rule(s) associated with individual data point(s) may include one or more rule(s) defining condition(s) for individual data points present with the gathered component data. Use of such rule(s) allows to ensure that data point(s) required by the data model associated with batteries or battery types are contained in the generated component data sets. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points. Use of such rule(s) allows to ensure that combination(s) of data point(s) required by the data model associated with batteries or battery types are contained within the generated component data sets.

[0114] A rule-based engine may be used to validate at least part of the component data gathered via the decentral network. The rule-based engine may be a software or software component that applies one or more rules to at least part of the gathered component data. The rule-based engine used to validate at least part of the gathered component data may include one or more rule(s) associated with batteries. The one or more rule(s) may be associated with or derived from or generated based on a data model associated with batteries or battery types. Hence, the one or more rule(s) may ensure that data point(s) for such components required according to the data model may be included in the gathered component data set. The one or more rule(s) may be defined by the mandatory component data points present within the data model. The one or more rule(s) may be generated based on the mandatory component data points present within the data model. This may ensure that component data required by the semantic model is included in the gathered component data, hence ensuring reliable and efficient generation of battery passports using such validated component data.

[0115] The rule-based engine may operate on individual data point level, combination of data points or the whole gathered component data. The operation of the rule-based engine may be defined by the one or more rule(s). Rule(s) associated with individual data point(s) may include one or more rule(s) defining condition(s) for individual data points present with the gathered component data. Use of such rule(s) allows to ensure that data point(s) required by the data model associated with batteries or battery types are contained in the consumed component data. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points. Use of such rule(s) allows to ensure that combination(s) of data point(s) required by the data model associated with batteries or battery types are contained within the consumed component data.

[0116] The battery passport may refer to a data set having a defined semantic structure. The defined semantic structure may be obtained by applying a data model, such as an aspect model, to validated component data and battery data associated with the respective battery. The battery passport may include a product identifier, at least one decentral identifier, validated component data and battery data (e.g. passport data). The battery passport may include one or more authentication mechanisms associated with the decentral identifier(s), the validated component data and the battery data. The battery passport may relate to one or more authorization mechanisms associated with the decentral identifier(s), the validated component data and the battery data. The one or more authorization mechanisms may include authorization rules determining if access to the at least a part of the validated component data and / or battery data is granted. The battery passport may be associated with one or more digital representations of the passport data or parts thereof. The digital representations may be regarded as access element(s) providing access to the battery passport or parts thereof. The digital representation may include a decentral identifier and access data for accessing the passport data or parts thereof. The access data may include a locator or pointer, such as am url or uri, to a dedicated storage storing the passport data, such as a dedicated storage address, associated with the data owner of the battery passport. The pointer or locator may point directly to the dedicated storage. The pointer or locator may point to a data providing network node associated with the dedicated storage. The access element may include one or more authentication mechanisms associated with the decentral identifier(s) and the access data. The access element may be associated with one or more authentication mechanisms associated with the decentral identifier(s) and the access data. The access element may be provided to a decentral registry storing access elements to be discoverable and / or accessible by participant node(s) of the decentral network. The decentral identifier may be discoverable and / or accessible by participant node(s) of the decentral network, for example via the access elements stored in the decentral registry. The decentral registry may be associated with the data owner of the passport data.. The decentral registry may be associated with a data providing network node. This may allow to control access to such registry and access to access element(s) stored in such registry via the data providing network node. The decentral registry may be associated with a participant of the product ecosystem. The decentral registry may be associated with the data owner of the battery passport. The decentral registry may be part of the decentral network but may not be associated with a particular participant of the production chain, e.g. may be regarded as infrastructure node of the decentral network.

[0117] In an embodiment, the one or more databases are distributed databases, wherein at least one of the databases stores instance(s) of the component data. A distributed database may be a collection of data stored at different sites of a computer network. Each site might expose a degree of autonomy, providing services for the execution of local applications, but also participating in the execution of a global application. For instance, a distributed data source may be a distributed database. A distributed database can be created by splitting and scattering the data of an existing database over different sites or by federating together multiple existing databases. Each data source may contain only a fragment of the data associated with the respective component. This leads to a fragmentation of said data. Two common types of data fragmentation are horizontal fragmentation, wherein (possibly overlapping) subsets of data tuples are stored at different sites; and vertical fragmentation, wherein (possibly overlapping) subtuples of data tuples are stored at different sites. More generally, the data associated with the respective component may be fragmented into a set of relations (tables of a relational database, distributed across multiple sites).

[0118] In an embodiment, the component is a battery component. The battery component may be an electrode, a battery cell, a battery module, a separator, a cell casing, a battery management system, a cooling system, mechanical subsystem or a battery pack housing. The battery component may be a chemical product used to produce the battery. The chemical product may include a metal, a metal salt, an anode material, a cathode active material, an electrolyte or a polymer.

[0119] In an embodiment, the gathered component data includes component identifier data, property data associated with the component, component name data, component producer data, component declaration data, component safety data, emission data associated with the component, recyclate content data associated with the component, biobased content data associated with the component, biodegradability data associated with the component, production data associated with the component, certificate of analysis data associated with the component, certificate data associated with the component, life cycle data associated with the component, storage instruction data associated with the component, assembly instructions associated with the component, operating conditions associated with the component or a combination thereof.

[0120] Component identifier data may include a batch number, a serial number, a LOT number or a combination thereof.

[0121] Property data may include at least one measured chemical and / or physical property of the produced component and / or at least one chemical and / or physical property determined from collected data associated with the production of component. The data may be collected before, during and / or after production of the component. The collected data may be used to determine at least one physical and / or chemical property of the produced component. For instance, the at least one physical and / or chemical property may be determined from sensor data obtained from sensor(s). The data may be collected with a suitable sensor configured to measure the chemical and / or physical property. The chemical property may be a property of the component that becomes evident during, or after, a chemical reaction. Hence, the chemical property may be any quality that can be established only by changing the chemical identity of the component. Examples of chemical properties include heat of combustion, enthalpy of formation, toxicity, chemical stability in a given environment, flammability, oxidation state(s), ability to corrode, combustibility, acidity and basicity, chemical composition, recyclate content used for producing or manufacturing the product, bio-based content used for producing or manufacturing the product, renewable content used for producing or manufacturing the product and / or pH value. The physical property may be any property of the component that is measurable. Hence, the value of a physical property describes a state of the component. Examples of physical properties include absorption, brittleness, boiling point, capacitance, color, concentration, continuous discharge, density, ductility, physical dimensions, distribution, efficacy, elasticity, electric charge, electrical conductivity, electrical impedance, electric potential, flow rate, fluidity, hardness, capacity, inductance, intrinsic impedance, luminance, luminescence, luster, mass, melting point, opacity, permeability, permittivity, plasticity, pulse discharge, power, pressure, radiance, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tension, thermal conductivity, thermal resistance, weight, viscosity, volume and / or wave impedance. The measured at least one physical and / or chemical property may be obtained by sensors configured to measure such property. The sensor may be included in a measuring device. The sensor may correspond to the measuring device.

[0122] Recyclate content data and / or bio-based content data may comprise any data related to the recyclate content or the bio-based content used for providing or manufacturing the component.

[0123] Emission data may comprise any data related to environmental footprint. The environmental footprint may refer to the component and its associated environmental footprint. The environmental footprint may be component specific. For instance, the environmental footprint may relate to the component or additional component-specific relations. Emission data may include data relating to the carbon footprint of the component or a Product Carbon Footprint (PCF). Emission data may include data relating to greenhouse gas emissions e.g. released in production of the component. Emission data may include data related to greenhouse gas emissions. Greenhouse gas emissions may include emissions such as carbon dioxide (CO2) emission, methane (CH4) emission, nitrous oxide (N2O) emission, hydrofluorocarbons (HFCs) emission, perfluorocarbons (PFCs) emission, sulphurhexafluoride (SFe) emission, nitrogen trifluoride (NF3) emission, combinations thereof and additional emissions.

[0124] Emission data may include data related to greenhouse gas emissions of an entities or companies own operations (production, power plants and waste incineration). Scope 2 may comprise emissions from energy production which is sourced externally. Scope 3 may comprise all other emissions along the value chain. Specifically, this may include the greenhouse gas emissions of raw materials obtained from suppliers. Product Carbon Footprint (PCF) may sum up greenhouse gas emissions and removals from the consecutive and interlinked process steps related to a particular component. Cradle-to-gate PCF may sum up greenhouse gas emissions based on selected process steps: e.g. from the extraction of resources up to the factory gate where the component leaves the company. Such PCFs may be called partial PCFs. In order to achieve such summation, each company providing any products may provide the scope 1 and scope 2 contributions to the PCF for each of its products.. Production data may comprise any data related to the production of the component. Production data may include monitoring and / or control data associated with the production of the component. Production data may be acquired prior to, during and / or after production of the component.

[0125] In an embodiment, the rule-based engine operates on individual data points present within at least part of the gathered component data, multiple data points present within at least part of the gathered component data or the whole gathered component data. The rule-based engine may be configured to transform gathered component data based on one or more included rule(s). The rule-based engine may apply one or more rule(s) to individual data point(s), multiple data point(s) and / or the whole data set to generate the component data set(s). If the rule-based engine determines that individual data point(s), multiple data point(s) and / or the whole data matches one or more condition(s) in the rule(s), such individual data point(s), multiple data point(s) or the whole data may be included in the generated component data set.

[0126] In an embodiment, the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to transformation operation(s). The instructions may signify the transformation operation(s). The instruction(s) may relate to the transformation operation(s). The transformation operation(s) may relate to aggregation component data gathered from multiple data sources into a given data structure, filters to filter gathered component data, attribute construction(s) to create or add new attributes to the gathered component data and / or a trigger condition and a corresponding group of one more actions. The rule template may be used to generate executable logic that may be executed by the rule-based engine. Use of a rule template may facilitate generation of one or more rule(s) since the instructions for generation of executable logic may be formulated in natural language. The rule template may be a predefined rule template. The rule template may be generated to match data model(s) associated with batteries produced by using the component as input material or battery types the batteries are associated with. The rule template may be generated and provided by a third party. This may allow to provide rule template(s) as a service to data providers to further simplify the generation of the component data sets and to lower the entry barrier for input material suppliers to generate and provide component data sets via a decentral network to allow data consumers access to such data for generation of battery passports.

[0127] In an embodiment, the one or more rule(s) are associated with or are derived from or are generated based on a semantic model, e.g. a data model, associated with batteries, in particular wherein the one or more rule(s) are defined by one or more mandatory component data point(s) present within the semantic model. The data model may be associated with a battery type the battery is associated with. This may allow to avoid the use of complex data models associated with component and instead may allow to use existing data models of batteries which are produced from such components or battery types the batteries are associated with. This allows to significantly reduce the complexity of the generation of component data sets for producers of such component(s), hence ensuring reliable and efficient provision of such component data set(s) within the decentral network for access by consuming entities for generation of battery passports.

[0128] In an embodiment, the one or more rule(s) define aggregation rule(s) for aggregating component data gathered from multiple data sources into a given data structure, define filters to filter gathered component data, define attribute construction(s) to create or add new attributes to the gathered component data and / or include a trigger condition and a corresponding group of one more actions. The given data structure may be a tabular representation. Hence, the rule-based engine may be configured to generate, based on the one or more included rule(s), a tabular representation filled with gathered component data matching one or more included rule(s). The tabular representation may be stored within a dedicated storage associated with the decentral data providing node, allowing provision of the tabular representation by requesting access to such tabular representation based on a component identifier included in such tabular representation. Filters may define data point(s) to be included in the generated component data set. For instance, a filter may define one for more component property data point(s), component identifier data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s). A filter may define data point(s) per data category. A filter may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data.

[0129] In an embodiment, transforming the gathered component data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered component data and providing the applicable rule(s) to the rule-based engine. The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to at least one component identifier included in the gathered component data. The applicable rule(s) may be included in a rule template. Hence transforming the gathered component data may include identifying an applicable rule template. The applicable rule(s) and / or the applicable rule template may be stored on a database connected to the rule-based engine. The identifier associated with each applicable rule or rule template may correspond to a digital component identifier included in the gathered component data. The applicable rule(s) or rule template may be gathered based on mapping data including identifier(s) associated with rule(s) or rule template(s) and associated component t identifier(s) and optionally component type identifier(s).

[0130] In an embodiment, transforming the gathered component data includes • generating executable logic from the one or more identified applicable rule(s),

[0131] • and transforming the gathered component data by executing the generated executable logic by the rule-based engine subject to rule execution criteria.

[0132] The rule execution criteria may be included in the executable logic. The execution criteria may relate to action(s) associated with triggers included in the executable logic. Generating executable logic allows provision of rule(s) or rule template(s) as unstructured data, such as in natural language, hence simplifying creation of executable logic by using rule template(s) or rule(s) including unstructured data, such as rule(s) and / or rule template(s) written in natural language. Simplifying creation of the executable logic ensures that the barrier to generate and provide component data set(s) within the decentral network is lowered, hence ensuring that also small supplier entities are able to participate as data providers within the decentral network. This in turn allows data consumers generating battery passports to reliably consume all required component data via the decentral network, hence ensuring efficient and reliable generation of battery passports using the gathered component data. This way, the data quality of the battery passports may be improved, allowing more reliable production of products using the battery and / or more reliable processing of end-of-life batteries based on the data included the battery passports.

[0133] In an embodiment, the component data set is generated responsive to fulfilment of one or more rule(s) applied to the gathered component data by the rule-based engine. This may ensure that generation of component data set(s) is then performed if at least a part of the rule(s) could be successfully applied to the gathered component data by the rule-based engine, e.g. if application of the rule(s) did not result in an error, for example due to missing data, wrong data, incomplete data, etc.. This may ensure that only component data set(s) are provided via the decentral network which fulfil the applied rule(s), hence avoiding errors during validation performed on the consumer side which may negatively influence the data quality of generated battery passports. This may in turn have a negative influence on the provision of such batteries and products including such batteries for example if certain data from upstream production stages must be included in the battery passport from a regulatory standpoint. The delayed provision of such batteries and products including such batteries may result in a negative influence on the production of downstream participants, since required input materials are not available for production. In addition, the low data quality may negatively influence the processing of the batteries, such as end-of- life batteries, based on the data included in the battery passports.

[0134] In an embodiment, the generated component data set includes or is associated with at least one component identifier, in particular the component identifier(s) included in the provided data associated with the component.

[0135] In an embodiment, the generated component data set includes at least a part of the data included in the gathered component data. For instance, the generated component data set may include data point(s) defined by the one or more rule(s) used to generate the component data set. Such rule(s) may define one or more data point(s) to be included in the generated component data set(s). In an embodiment, the generated component data set includes component property data point(s), component identifier data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s). For instance, the generated component data set may include component emission data point(s).

[0136] In an embodiment, the method further includes a step of generating group access data associated with the generated component data set and optionally one or more authorization rule(s) defining access to and / or usage of the generated component data set. The group access data may identify access control groups including decentral participant identifier(s) associated with decentral network participants permitted to access at the generated component data set. This access group data may allow to control access to such data sets, hence avoiding access of unauthorized data consumers to such data. This may ensure that the component data sets are only shared with such data consumers that require such data, for example for the generation of battery passports.

[0137] In an embodiment, the method further includes a step of generating a contract template including the digital component identifier and the group access data identifier. The method may further include a step of linking the group access data to the digital component identifier. The linking may be included in the contract template. The contract template may be used by the decentral data providing node to generate an electronic contract. The electronic contract may be provided to a decentral data consuming node requesting access to such component data set(s) associated with the decentral data providing node. The contract may include access data. The access data may include an endpoint pointing to the dedicated storage storing the respective component data set. This may allow the decentral data consumer node to use such endpoint within the request for such component data upon accepting the electronic contract. The electronic contract may include authorization rule(s) associated with the usage of the component data set(s). This may avoid unauthorized use of the provided component data by the data consumer, hence improving data security.

[0138] In an embodiment, the access to the generated component data set is controlled by the decentral data providing node associated with the data owner based on the group access data and contract template associated with the component data set. This may allow to configure access to the component data set such that access to such data by unauthorized data consumers not requiring access to such data is avoided. Access to the generated component data set may be controlled based on the digital component identifier associated with the component data set and the component. In an embodiment, the method further includes a step of generating incident data responsive to the determination that at least one rule applied by the rule-based engine to the gathered component data is not fulfilled. The incident data may identify the data point(s) and rule(s) which resulted in non-fulfillment. The incident data may be used to generate an updated component data set. Use of such incident data may allow to avoid provision of component data sets which may not be validated by the consumer side, thus resulting in delay of generation of battery passport(s) since such generation must be delayed until component data set(s) including valid data are available from the provider side.

[0139] In an embodiment of the method for validating component data associated with component(s), the battery data further includes product property data including at least one measured chemical and / or physical property of the battery and / or at least one chemical and / or physical property determined from collected data associated with the production of the battery. The chemical and / or physical property may correspond to the properties previously described. The data may be collected prior to, during and / or after production of the battery.

[0140] In an embodiment of the method for validating component data associated with component(s), the decentral data providing node(s) are determined from mapping data mapping decentral data providing node data to associated component identifier(s) by matching component identifier(s) included in the battery data to component identifier(s) included in the mapping data. This mapping data may be stored in a database. The database may be associated with the data consumer or the entity performing the method. The database may be associated with the system performing the method. The component identifier(s) and associated data providing node data may be provided by respective decentral data providing node(s) to the consuming entity consuming such component data from such data providing node(s). Data providing node data may include location data pointing to the location of the component data set associated with the respective data providing node, an endpoint address associated with the respective data providing node and / or a decentral participant identifier associated with the respective data providing node. The database may not contain associated component data set(s), hence the database may not be regarded as a central repository of component data set(s). Instead, the control over access to the component data set(s) is retained by the respective data providers, while such database only allows to locate component data set(s) required to generate respective battery passports.

[0141] In an embodiment of the method for validating component data associated with component(s), the obtained component data is provided to one or more input node(s) configured to gather the obtained component al data and to provide the gathered component data as component data set(s) to one or more downstream node(s), wherein the one or more downstream node(s) are configured to validate at least a part of the data included in the component data set(s) provided by the one or more input node(s), link the validated component data to at least one of the battery identifiers, determine storage location(s) for the validated component data and to provide the validated component data linked to battery identifier(s) to the determined storage location(s). An input node may represent a computing node gathering component data from one or more decentral data consuming node(s). The one or more input node(s) may be configured to generate data packages, such as messages or events, from the received component data. The generated data packages may be sent downstream from the input node to the one or more downstream node(s). The downstream node(s) may be configured to retrieve data packages provided by the input node(s). The input node(s) may be configured to provide data packages to a persistent or non- persistent log. The downstream node(s) may be configured to retrieve data packages provided to the persistent or non-persistent log. The downstream node(s) may be configured to receive data packages provided to the persistent or non-persistent log. The input node(s) may be associated with a decentral network. For instance, the input node(s) may be associated with a decentral data consuming network node being part of a decentral network. Downstream node may refer to a computing node consuming data from a computing node present upstream with respect to the flow of data. Consuming data may include receiving data or retrieving data packages from the input node(s) or the persistent or non- persistent log. For instance, data “flows” downstream from an input node to the downstream node. The downstream node may be regarded as an output node. A request for data may be sent upstream from the downstream node to the input node.

[0142] In an embodiment of the method for validating component data associated with component(s), the rulebased engine operates on individual data points present within at least part of the component data, multiple data points present within at least part of the component data or the whole component data. The rule-based engine may be configured to validate component data based on one or more included rule(s). The rule-based engine may apply one or more rule(s) to individual data point(s), multiple data point(s) and / or the whole data set to generate validated component data. If the rule-based engine determines that individual data point(s), multiple data point(s) and / or the whole data matches one or more condition(s) in the rule(s), such individual data point(s), multiple data point(s) or the whole data may be regarded as validated. The validated data may be associated with a classifier indicating successful validation of the respective data point, combination of data point(s) or the whole data. The classifier may indicate that the component data passed the one or more applied rule(s). Validating the component data on data point level may ensure that all component data point(s) required by the data model associated with the battery or battery type are contained in the gathered component data. Validation on data point level may compensate for the simplified component data set generation at the provider side which does not require the use of data models ensuring that the generated component data set(s) include all required data point(s).

[0143] In an embodiment of the method for validating component data associated with i component(s), the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to validation operation(s). The validation operation(s) may relate to one or more data point(s) and / or data point combination(s) to be present within the component data. The rule template may be used to generate executable logic that may be executed by the rule-based engine. Use of a rule template may facilitate generation of one or more rule(s) since the instructions for generation of executable logic may be formulated in natural language. The rule template may be a predefined rule template. The rule template may be generated to match data model(s) associated with batteries or battery types.

[0144] In an embodiment of the method for validating component data associated with component(s), the one or more rule(s) define data point(s) and / or combination(s) of data point(s) to be present within the component data. This may ensure that the component data includes all data point(s) required by the data model associated with batteries or battery types, hence ensuring that the gathered component data includes all data points required by the data model for the particular component.

[0145] In an embodiment of the method for validating component data associated with component(s), validation of the component data may further include transforming the component data. Transforming the component data may include unit transformation to transform a unit associated with a data point into a unit required by the data model associated with batteries or battery types. This may allow to shift unit transformation operations to the consumer side, hence allowing to simplify generation of component data sets at the provider side to ensure reliable provision of component data set(s) by various suppliers of the battery ecosystem, irrespective of the size of the entity producing the components.

[0146] In an embodiment of the method for validating component data associated with component(s), the one or more rule(s) are associated with or derived from a data model associated with at least one of the batteries or battery types, in particular wherein the one or more rule(s) are defined by the mandatory component data point(s) present within the data model. The data model may be a predefined (e.g. existing) data model. The data model may define the data structure of the battery passport. The data model may define the value(s) and / or value range(s) for data point(s) to be included in the battery passport. The ata model may define mandatory and optional data point(s) to be included in the battery passport. The data model may define relationships between different data point(s).

[0147] In an embodiment of the method for validating component data associated with component(s), validating the gathered component data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered component data and providing the applicable rule(s) to the rule-based engine. The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to at least one component identifier included in the gathered component data as previously described. The applicable rule(s) may be included in a rule template. Hence validating the gathered component data may include identifying an applicable rule template. The applicable rule(s) and / or the applicable rule template may be stored on a database connected to the rule-based engine. The identifier associated with each applicable rule or rule template may correspond to a digital component identifier included in the gathered component data. The applicable rule(s) or rule template may be gathered based on mapping data include identifier(s) associated with rule(s) or rule template(s) and associated component identifier(s) and optionally component type identifier(s). In an embodiment of the method for validating component data associated with component(s), transforming the gathered component data includes

[0148] • generating executable logic from the one or more identified applicable rule(s),

[0149] • and transforming the gathered component data by executing the generated executable logic by the rule-based engine subject to rule execution criteria.

[0150] In an embodiment of the method for validating component data associated with i component(s), the component data is validated responsive to fulfilment of one or more rule(s) applied to the component data by the rule-based engine. This may ensure that the gathered component data is only validated if the rule(s) could be successfully applied to the gathered data by the rule-based engine, e.g. if application of the rule(s) did not result in an error, for example due to missing data, wrong data, incomplete data, etc.. This may ensure that the battery passport may be generated by applying the respective data model to the validated component data and respective battery data without any errors due to missing or wrong component data, hence avoiding a delay in generation of the battery passports.

[0151] In an embodiment of the method for validating component data associated with component(s), the storage location is determined based on mapping data including a mapping between component identifier(s) and associated storage location data or a mapping between component identifier(s) and associated component type identifier(s) and storage location data. The storage location may correspond to a database. The database may be a relational or a non-relational database. Use of different storage location(s) allows to improve data security, since validated component data to be used for the generation of battery passports associated batteries, may be stored within a particular dedicated storage accessible only by the application generating the battery passports for such batteries but not for other applications generating passports for other product types.

[0152] In an embodiment of the method for validating component data associated with component(s), the validated component data includes one or more validated component property data point(s), validated component identifier data point(s), validated component name data point(s), validated component producer data point(s), validated component declaration data point(s), validated component safety data point(s), validated component emission data point(s), validated component recyclate content data point(s), validated component biobased content data point(s), validated component biodegradability data point(s), validated component production data point(s), validated component certificate of analysis data point(s), validated component certificate data point(s), validated component life cycle data point(s), validated component storage instruction data point(s), validated component assembly instruction data point(s) and / or validated component operating condition data point(s).

[0153] In an embodiment of the method for validating component data associated with component(s), the method further includes a step of generating incident data responsive to the determination that at least one rule applied by the rule-based engine to the gathered component data is not fulfilled. The incident data may identify the data point(s) and rule(s) which resulted in non-fulfilment. The incident data may be provided to the data provider from which the objected input component data was received, hence allowing the data provider to generated updated component data and to provide such updated component data for repeated validation.

[0154] BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0155] In the following, the present disclosure is further described with reference to the enclosed figures. The same reference numbers in the drawings and this disclosure are intended to refer to the same or like elements, components, and / or parts.

[0156] FIG. 1 illustrates an example of a participant network of a product ecosystem including a material loop and being associated with a decentral peer-to-peer network for exchange of data associated with raw materials, chemical product(s), discrete product(s), end product(s) and recycled material(s).

[0157] FIG. 2 illustrates an example of a participant network of a battery ecosystem including a material loop and being associated with a decentral peer-to-peer network for exchange of data associated with raw materials, chemical product(s), batteries, end product(s) and recycled material(s).

[0158] FIG. 3A, 3B illustrate a schematic block diagram of a production process of a battery.

[0159] FIG. 4 illustrates schematically a battery with a battery identification element as product.

[0160] FIG. 5 illustrates schematically a battery component with an identification element as an input material used to produce the battery.

[0161] FIG. 6A illustrates a block diagram of an example system for generating component data set(s) associated with produced component(s) and for providing the generated component data set(s) for access by decentral data consuming nodes.

[0162] FIG. 6B illustrates a diagram showing an example of gathering component data and transforming at least part of the gathered component data using a rule-based engine.

[0163] FIG. 7 illustrates an example system and associated methods for generating component data set(s) associated with produced component(s) and providing access to the generated component data set(s).

[0164] FIG. 8 illustrates an example of a decentral system for accessing component data set(s) associated with produced component(s).

[0165] FIG. 9 illustrates a flow chart of an example method for generating component data set(s) associated with component(s). FIG. 10 illustrates an embodiment of the method illustrated in FIG. 9.

[0166] FIG. 11 illustrates a flow chart of a further example method for generating component data set(s) associated with component(s).

[0167] FIG. 12 illustrates a sequence diagram of an example method for generating component data set(s) associated with component(s).

[0168] FIG. 13A illustrates a block diagram of an example system for validating component data associated with component(s) used to produce a battery.

[0169] FIG. 13B illustrates a diagram showing an example of validating component data associated with component(s) used to produce a battery using a rule-based engine.

[0170] FIG. 14 illustrates a flow chart of an example method for validating component data associated with component(s) used to produce a battery.

[0171] FIG. 15 illustrates an embodiment of the method illustrated in FIG. 14.

[0172] FIG. 16 illustrates a sequence diagram of an example method for validating component data associated with component(s) used to produce a battery.

[0173] FIG. 17 illustrates a flow chart of a further example method for validating component data associated with component(s) used to produce a battery.

[0174] DETAILED DESCRIPTION

[0175] FIG. 1 illustrates an example of a participant network of a product ecosystem associated with a decentral peer-to-peer network for exchange of data associated with raw materials, chemical product(s), discrete product(s), end product(s) and recycled material(s). The decentral participant network 130 may include one or more decentral network participants, such as decentral participants 102 to 114. The decentral network participants may be part of a product ecosystem including chemical products. The product ecosystem may include production chains to produce an end-product. The product ecosystem may include recycling chains to recycle at least part of an end-of-life product resulting from the use of the end product. The product ecosystem may include a raw material producer 104, a chemical product producer 102, a chemical product user 106, an end-product producer 108, an end-product user 110 an EOL product collector 112 and a recycler 114. The decentral participant network 130 may include a chemical supply chain. The product ecosystem may allow to use of recycled materials resulting from recycling of end-of- life products to produce new products, such as chemical products. The product ecosystem may be associated with the production and / or recycling of physical products. The product may be a chemical product, an intermediate chemical product, a component, a component assembly, an end product, an end-of-life product or a recycled material. At least a part of the participant(s) of the decentral participant network 130 may be associated with the production of the product and / or the recycling of end-of-life products resulting from the use of the product by product users, such as end-product users 110. The decentral network participant 102 to 114 may refer to a manufacturer of physical products, such as raw material producer 104, chemical product producer 102, chemical product user 106, end-product producer 108, a user of physical goods, such as end-product user 110, and / or a participant of a recycling chain associated with the physical product, such as EOL product collector 112 and recycler 114. The decentral network participant may be associated with a decentral participant identifier. The decentral participant identifier may uniquely identify the decentral network participant within the decentral participant network 130.

[0176] At least a further part of the participant(s) of the decentral participant network 130 may be associated with the generation of product passport(s). Such decentral participants may not be associated with the production of the product and / or the recycling of the end-of-life products. Such decentral participants may gather component data, for example as described in the context of FIG. 14 and may generate product passports using at least a part of the gathered component data. The generated product passports may be provided by such participants for access via the decentral network 130. For instance, recycler 114 may access such product passports to determine the composition of the end-of-life product, allowing adaption of the recycling process to the determined composition.

[0177] The participant(s) of the decentral participant network 130 may be connected via material flows. The material flow may be a loop material flow 136. The loop material flow 136 may be a closed loop material flow. A closed loop material flow may refer to a material loop where recycled material is used to produce the same end products the recycled material is obtained from via recycling. The loop material flow 136 may be an open loop material flow. An open loop material flow may refer to a material loop where recycled material is used to produce different end products than the one the recycled material is obtained from. The material flow may be a linear material flow (e.g. not including recycling). The material flow 136, 138 may correspond to the flow of product from one participant of the decentral participant network 130 to the downstream participant of the decentral participant network 130. The material flow 136, 138 may refer to a continuous or a discontinuous flow of product. The flow of product may include any means of transportation suitable to transport the product from a participant to the downstream participant. The means of transportation may include pipes, containers, barrels, packages. The material flow 138 may be associated with raw materials used to produce a chemical product, such as virgin raw materials. The raw materials may be provided to chemical product producer 102 for producing chemical product(s) and / or intermediate chemical product(s) (not shown). The loop material flow 136 may be associated with chemical product(s) and discrete product(s). The chemical product(s) may be provided from chemical product producer 102 to chemical product user 106 for producing discrete product(s). In contrast to chemical production, the discrete products being produced are distinct units sold as individual products. The loop material flow 136 may be associated with recycled material. The recycled material may be provided from recycler 114 to chemical product producer 102 for the production of chemical product(s) using the recycled material.

[0178] At least part of the participants of the decentral participant network 130 may be associated with decentral participant network nodes 116 to 128. The decentral participant nodes 116 to 128 may be under control of the respective decentral participant associated with the respective decentral participant node. The decentral participant nodes 116 to 128 may form decentral network 134. The decentral network 134 may be a peer-to-peer communication network. The decentral network 134 may be configured to perform data transactions 132. The data transactions 132 may be based on a transaction protocol including authentication and / or authorization mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer communication between decentral network nodes 116 to 128 associated with decentral network participants 102 to 114 may be established. The one or more authentication mechanism(s) may be associated with or linked to an identifier as described in the context of FIG. 8. The one or more authentication mechanism(s) associated with the identifier may be accessible by the decentral participant nodes as described in the context of FIG. 8. The decentral configuration allows for more efficient use of computing resources and strengthens control by the data owners of the decentral network.

[0179] Data transactions between decentral network participant nodes may be based on an identifier associated with respective data to be accessed, for example as described in the context of FIG. 8. The identifier may be uniquely associated with the physical entity of the respective product and associated product data. The identifier may be a decentral identifier uniquely identifying the product within the decentral network. The identifier may be a local identifier used by the respective product producer to uniquely identify the respective product. The identifier may be associated with further identifier(s), such as identifier(s) of production input(s) (e.g. input materials) used to produce the component. This may allow to track the product input(s) used to produce a product, such as an end-product. The identifier may, for example, be included in a component data set associated with the battery component, for example as described in the context of FIG. 9.

[0180] The data flow 132 (e.g. transactions) between decentral network participant nodes may be directly or indirectly associated with the material flow 136, 138 between the decentral network participants. For instance, data flow 132 may be directly associated with material flow 136, 138 if data associated with an input material provided from the raw material producer 104 to the chemical product producer 102 is accessed by decentral participant node 118 associated with said chemical product producer 102. For instance, data flow 132 may be indirectly associated with material flow 136, 138 if data associated with a chemical product produced by chemical product producer 102 is accessed by decentral participant node 128 associated with recycler 114.

[0181] The decentral participant nodes 116 to 128 may be decentral computing nodes. The decentral computing node may be any device or system that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that are executed by a processor. The memory may take any form and depends on the nature and form of the computing node.

[0182] At least part of the decentral participant nodes 116 to 128 may be decentral data providing network nodes. At least part of the participant nodes 116 to 128 may be decentral data consuming network nodes. A participant of the decentral participant network 130 may be associated with a decentral data providing network node and / or a decentral data consuming network node depending on whether data is provided to downstream participants and / or consumed from upstream participants. For instance, end-product producer 108 may be associated with a decentral data providing network node configured to provide product data to a downstream participant (e.g. recycler 114). In addition to or alternatively, end-product producer 108 may be associated with a decentral data consuming network node configured to access data associated with a discrete product produced by an upstream participant (e.g. chemical product user 106) for example as described in the context of FIG. 8.

[0183] The decentral network 134 may include further decentral network nodes. The further decentral network nodes may be decentral infrastructure service nodes (not shown in FIG. 1). The decentral infrastructure service nodes may not be associated with a participant of the product ecosystem. The decentral infrastructure service nodes may provide services for decentral participant nodes 116 to 128, such as verifying the identity of the decentral network participant nodes 116 to 128 prior to performing a data exchange. The decentral network participant nodes 116 to 128 may be associated with or include certificate(s), such as X.509 certificate(s). The certificate(s) may be associated with decentral infrastructure service node(s) including e.g. a certificate issuing service and / or a dynamic provisioning service providing dynamic attribute tokens (e.g. OAuth Access Tokens). This way the decentral network participant nodes 116 to 124 possess a unique identifier embedded in a X.509 certificate that identifies the respective decentral network participant node 116 to 128. The information required to verify the certificate may be provided via an authentication registry associated with the certificate issuing service and / or a dynamic provisioning service. For instance, in the IDSA Reference Architecture Model, Version 3.0 of April 2019, a decentral data providing network node associated with a data owner, a Certification Authority (CA), a Dynamic Attribute Provisioning Service (DAPS) and a decentral data consuming network node associated with a data consumer are used to verify the identity prior to performing a data exchange (not shown, refer to FIG. 8).

[0184] FIG. 2 illustrates an example of a participant network of a battery ecosystem including a material loop and being associated with a decentral peer-to-peer network for exchange of data associated with raw materials, chemical product(s), batteries, end product(s) and recycled material(s). The decentral participant network 216 may include one or more decentral network participants, such as decentral network participants 108, 112 and 202 to 212. The battery ecosystem may include production chains to produce an end product, such as a machine containing a battery. The battery ecosystem may include recycling chains to recycle at least part of an end-of-life battery resulting from the use of the end product. The battery ecosystem may include a miner 202, a refiner 204, a precursor cathode active material (PCAM) and cathode active material (CAM) producer 206, a battery producer 208, an end-product producer 108, an EOL product collector 112, a black mass producer 210 and a metal extractor 212. The battery ecosystem may allow to use recycled materials, such as recycled metals and metal salts, resulting from recycling of end-of-life batteries or components thereof to produce new products, such as PCAM and CAM. The product ecosystem may be associated with the production and / or recycling of batteries.

[0185] The participant(s) of the decentral participant network 216 may be associated with the production of a battery containing end product and / or recycling of end-of-life batteries or components thereof. The decentral network participant may be a manufacturer of physical products, such as miner 202, refiner 204, PCAM & CAM producer 206 chemical product producer 102, chemical product user 106, end-product producer 108 and / or a participant of a recycling chain associated with the end-of-life batteries or components thereof, such as EOL product collector 112, black mass producer 210 and metal extractor 212. For instance, the metal extractor 212 and the PCAM & CAM producer 206 may be a single entity performing recycling operations to obtain recycled material, such as recycled metals and / or metal salts, and producing new chemical product(s), such as PCAM and / or CAM using the recycled metal and / or metal salts. The decentral network participant may be associated with a decentral participant identifier. The decentral participant identifier may uniquely identify the decentral network participant within the decentral participant network 216.

[0186] At least a further part of the participant(s) of the decentral participant network 130 may be associated with the generation of battery passport(s). Such decentral participants may not be associated with the production of the battery containing end product and / or the recycling of the end-of-life batteries or components. Such decentral participants may gather component data, for example as described in the context of FIG. 14 and may generate battery passports using at least a part of the gathered component data. The generated battery passports may be provided by such participants for access via the decentral network 130. For instance, recycler 114 may access such battery passports to determine the chemical composition of the end-of-life batteries or components thereof, allowing adaption of the recycling process to the determined composition.

[0187] The participant(s) of the decentral participant network 216 may be connected via material flows as described in the context of FIG. 1 . The raw materials, such as metals, may be provided to refiner 204 for refinement. The refined metals may be provided to PCAM & CAM producer 206 for the production of cathode active material. The CAM may be used, for example by battery producer 208, to produce battery cells (see also FIG. 3A, FIG. 3B). The battery cells may be used to produce batteries or battery packs (see also FIG. 3B). The batteries or battery packs may be provided to end-product producer 108 to produce battery containing end products, such as electric vehicles. Scrape from battery production may be provided to black mass producer 210. At least a part of the participants of the decentral participant network 216 may be associated with decentral participant network nodes 218 to 232 as described in the context of FIG. 1. The decentral participant nodes 218 to 232 may form decentral network 208. The decentral network 208 may be a peer- to-peer communication network as described in the context of FIG. 1 . The decentral configuration allows for more efficient use of computing resources and strengthens control by the data owners of the decentral network.

[0188] Data transactions between decentral network participant nodes may be based on an identifier associated with respective data to be accessed, for example as described in the context of FIG. 8. The identifier may be uniquely associated with the physical entity of the respective product and associated product data. The identifier may be a decentral identifier uniquely identifying the product within the decentral network. The identifier may be a local identifier used by the respective product producer to uniquely identify the respective product. The identifier may be associated with further identifier(s), such as identifier(s) of production input(s) (e.g. input materials) used to produce the component. This may allow to track the product input(s) used to produce a product, such as an end-product. The identifier may, for example, be included in component data associated with components, for example as described in the context of FIG. 14.

[0189] The data flow 132 (e.g. transactions) between decentral network participant nodes may be directly or indirectly associated with the material flow 136, 138 between the decentral network participants as described in the context of FIG. 1 .

[0190] The decentral participant nodes 218 to 232 may be decentral computing nodes as described in the context of FIG. 1.

[0191] At least part of the decentral participant nodes 218 to 232 may be decentral data providing network nodes. At least part of the participant nodes 116 to 128 may be decentral data consuming network nodes. A participant of the decentral participant network 130 may be associated with a decentral data providing network node and / or a decentral data consuming network node depending on whether data is provided to downstream participants and / or consumed from upstream participants (see also FIG. 1).

[0192] The decentral network 134 may include further decentral network nodes as described in the context of FIG. 1.

[0193] FIG. 3A and FIG. 3B illustrate a schematic block diagram of a production process of a battery. The battery may be produced by one or more production chains as illustrated in FIG. 3A and FIG. 3B, such as production chains associated with the production of the battery cell, the cooling system, the battery housing, the battery management system and / or the mechanical subsystem. The production chains may each include one or more production stages. For example, the battery cell production chain may include production stages for producing the anode, the cathode, the separator, the housing and the electrolyte. The battery may be used within a machine, such as an automotive. The battery may be used until reaching its end of life. End-of-life batteries may have a state of health (SoH) which is below predefined threshold values. The state-of-health (SoH) may be a measurement that indicates the level of degradation and remaining capacity of the battery. It may be defined as the ratio of the maximum battery charge to its rated capacity. SoH may be determined with the BMS of the battery. SoH may be determined using Battery Capacity Determination (BCD).

[0194] With reference to FIG. 4, the battery 402 may comprise a battery management system 408 and a plurality of battery cells 410 arranged inside a battery housing 412. The battery cells 410 may be arranged in battery packs or modules comprising multiple battery cells 410. The battery cell 410 may comprise an electrolyte 414 , an anode element 416 , a cathode element 418, and a separator 420. Depending on the application, different components of batteries may comprise different material compositions. For instance, the battery produced by the production process illustrated in FIG. 3A and FIG. 3B may be a lithium-ion battery.

[0195] With continued reference to FIG. 4, the cathode elements 318, 418 may include cathode active material (CAM) 342 coated on a collector foil 344 such as an aluminum or copper foil. The CAM 342 may contain layered oxides (LiMO2 with M=Co, Ni, Mn, Al such as LCO (LiCoO2), NCM (LiNixMnyCozO2), NCA (LiNixCoyAlzO2)), spinels (UM2O4 with M=Mn, Ni such as LMO (LiMnO4)) or phosphates (LiMPO4 with M= Fe, Mn, Co, Ni such as LiFePO4). The CAM 342 may be produced from lithium salts, such as LiOH and IJ2CO3. The CAM 342 may be produced from precursor material via solid state synthesis. The precursor material may be produced by co-precipitation of transition-metal sulfate or hydroxide materials, such as NiSO4, MnSO4, CoSO4, Ni(OH)2, Mn(OH)2, Co(OH)2. Co-precipitation may be achieved by adding sodium hydroxide and ammonia to a solution of the transition-metal sulfate or hydroxide materials. The precursor material, such as NixCoyMni-x-y(OH)2 may be mixed with the lithium salt(s) and calcinated. The calcinated material is ground and classified to obtain the CAM 342. The CAM may further contain binders 338, polyvinylidene fluoride (PVDF) and carbon as conducting agents. The binder 338 may be a polymer produced from one or more monomers (e.g. raw materials binder 306).

[0196] With continued reference to FIG. 4, the anode elements 316, 416 may include anode active material 334 coated on collector foil 336, such as an aluminum or copper foil. The anode active material may contain artificial graphite (e.g. synthetically produced graphite), natural graphite or mixtures thereof. Further the anode active material may include silicon, SiO2, lithium titanate (LTO) or combinations thereof. Further the anode active material may contain binders 338, such as styrene-butadiene rubber (SBR), polymeric thickener like carboxylmethyl cellulose (CMC) and carbon as conducting agent. The binder 338 may be a polymer produced from one or more monomers (e.g. raw materials binder 306).

[0197] With continued reference to FIG. 4, the electrolyte 324, 414 may comprise salts 354, solvents 352 such as carbonates, esters or ethers to provide conductivity and additives e. g. to support the formation of SEI- layers such as alkyl sulfites and sulfones e. g. ethene sulfite and propene sulfone. The solvent may include cyclic carbonates such as ethylene carbonate (EC) or propylene carbonate (PC), open chained carbonates such as dimethyl carbonate (DMC) and / or ethyl methyl carbonate (EMC), or mixtures thereof. Salts 354 may include conducting lithium salts, such as lithium hexafluorophosphate (LiPFs), lithium bis(trifluormethyl)sulfonylimid (LiTFSI) and its derivates (e.g., lithium bis(fluorosulfonyl) imide (LiFSI)) or lithium [tris(pentafluorethyl)-trifluorphosphate] (LiFAP), lithium 4,5-dicyano-2-trifluoromethyl-imidazolide (LiTDI), lithium bis(oxalate)borate (LiBOB)). The salts 354, solvents 352 and further additives may be prepared from respective raw materials 364, 366 and 368.

[0198] With continued reference to FIG. 4, the separator 320, 420 may include microporous membranes, coated separators, non-woven mats, solid inorganic or polymeric materials. Coated separators may include polyolefin-based membranes coated e.g., with PVDF or ceramics. The polyolefin-based membrane may be produced from respective raw materials 346. Separators 320, 420 may divide the space between the electrodes and are permeable for ions.

[0199] Battery cells, such as Lithium-ion battery cells 370, may be produced from anode element 316, cathode element 318, separator 320, a casing 322 and electrolyte 324. The casing may be a metal casing produced from steel or aluminum 348. The casing may have various shapes, such as prismatic or round shapes, pouch shapes, etc.. The anode element 316, cathode element 318 and separator 320 may be placed inside the casing 322. The casing 322 including the anode element, cathode element and separator may be filled with the electrolyte 324. The casing may be filled with the electrolyte after closing and evacuating the casing. The casing may be filled with the electrolyte prior to closing the casing.

[0200] With reference to FIG. 5, a component identification element 404, 406 may be associated with the produced battery cell 410. The identification element 404, 406 may be physically attached to the component 410. The identification element 404, 406 may be arranged inside or outside the battery component 410. The identification element 404, 406 may be a passive identification element 404, 406. The passive element 404, 406 may be arranged on the outer surface of the battery cell housing lithium salt 310. The passive element 404, 406 may be based on markers embedded into the cell housing. The passive element 404, 406 may include a printed code such as a bar code or a QR code and / or a printed number, such as a serial number and / or a printed combination of numbers and letters including symbols. The identification element 404, 406 may be an active identification element 404, 406. The active identification element 404, 406 may be a transmitter or transceiver tag, such as an RFID tag enabling communication through e.g. NFC, Bluetooth, Zigbee or other suitable near- to mid-range communication protocols. The identification element 404, 406 may be associated with a digital component identifier (e.g. with a digital battery cell identifier). The digital component identifier may include or relate to at least one component identifier associated with production input(s) used to produce the component, such as the battery cell. In particular, the identification element 404, 406 may be configured to provide a digital component identifier, such as a digital battery cell identifier, for accessing component data associated with the respective component, such as the battery cell. Component data may include, for example cathode active material composition data, anode active material composition data and / or electrolyte composition data. The composition data may include data related to critical compounds present within the CAM, anode active material and / or electrolyte.

[0201] The produced battery cells, such as Lithium-ion battery cell 370, may be used to produce a battery pack, such as Lithium-ion battery pack 372. Battery pack production may involve module production and battery pack production. For module production, the battery cells may be joined, for example using liquid or solid adhesives being electrically insulating. Examples of adhesives may include polyurethane-based adhesives. The joined or stacked cells may be pressed to create a defined stack geometry and minimize swelling during charge and discharge. Plastic plates or foils may be applied to the joined or stacked cells for heat dissipation and electrical insulation. The stacked cells may be wired by electrical connection of the contact tabs / current collectors. Depending on the module voltage, the cells may be contacted to form one or more parallel strings. A slave circuit board of the battery management system (BMS) 326 or a complete contacting unit for processing the data and controlling the sensors may be joined to the module by welding and / or screwing. A controller and, if necessary, a cooling system 332 for later connection to the BMS master may be joined to the module. The produced module may be subjected to testing procedures. Testing procedures may include control of external irregularities (optical tolerances), functionality of communication and sensors (software test), cell voltage, cell difference (balancing), state of Charge (SOC) of the module, HV strength (resistance measurement), gas leakage test, overpressure test, vacuum test, etc.. The module may likewise be associated with an identification element as described in the context of the battery cells. The identification element may likewise be configured to provide a digital module identifier for accessing module data associated with the respective module. Module data may, for example, include adhesive data associated with the adhesive used for joining the battery cells, data associated with the slave circuit board and / or data associated with the cooling system. Module data may further include identifiers associated with input material(s) used to produce the module, such as battery cell identifier(s), slave circuit board identifier and / or cooling system identifiers.

[0202] For pack production, cooling elements may be mounted in the bottom of the battery pack tray or housing 328 for cooling and / or heating the modules. Afterwards, the produced battery modules may be fixed inside the pack housing. The cooling system 332 may be attached and connected to the cooling elements in the pack housing. A high-voltage module may be mounted and connected to the modules. The high- voltage module may include a relay, fuses, pre-charge & current measuring system, insulation monitoring etc. The battery management system (BMS Master) may be installed and wired to control the cooling system, modules, slave circuit boards and high-voltage module. The final battery pack 372 may be obtained by apply a sealant to the edge of the housing or cover and placing the cover of the housing on the sealant and connecting it to the housing.

[0203] With reference to FIG. 4, an identification element 404, 406 may be physically associated with the battery

[0204] 402. The identification element 404, 406 may be physically attached to the battery housing 412. The identification element 404, 406 may be arranged inside or outside the battery housing 412. The identification element 404, 406 may be a passive identification element 404, 406 or an active identification element 404, 406 as previously described. The identification element 404, 406 may be part of the battery management system 408, for instance if the battery identifier associated with the battery is stored within the BMS 408.

[0205] The battery 402 may be associated with a digital battery identifier. The digital battery identifier may be associated with the identification element 404, 406. The digital battery identifier may be stored within BMS 408. The digital battery identifier may be unique for the physical entity of the battery 402. The digital battery identifier may be associated with battery data. Such data may include any data collected during the production and / or the lifetime of the battery 402. For instance, such data may include component identifier(s) associated with production input(s) used to produce the battery, data collected before, during and / or after production of the battery and / or monitoring data collected during use of the battery 402.

[0206] The digital battery identifier may be associated with or include at least one decentral battery identifier. The decentral battery identifier may comprise any unique identifier uniquely associated with the battery data and the identified battery 402. The decentral battery identifier may further be associated with the data owner of the battery data. The decentral battery identifier may include at least one Universally Unique I Dentifier (UUID) and / or at least one Digital I Dentifier (DID). The decentral battery identifier may be issued by a central or decentral identity issuer. The decentral battery identifier may include authentication information for authentication of the battery data. Via the decentral battery identifier and its unique association with the battery 402, access to the battery data may be controlled by the data owner of the battery data. This contrasts with central authority schemes, where identifiers are provided by central authority and access to data is controlled by such central authority. Decentral in this context refers to the usage of the identifier as controlled by the data owner. The decentral battery identifier may be discoverable and / or accessible for participant node(s) of the decentral network. Based on the discovered and / or accessed decentral battery identifier, access to the battery passport may be requested by decentral network node(s) associated with data consumers, such as battery users or production(s) processing the battery. The identification element 404, 406 may be configured to provide the decentral battery identifier or to provide data associated with the decentral battery identifier, such as the digital battery identifier, for accessing battery data.

[0207] The data owner may comprise any entity generating data, particularly data relating to the battery identified. The generating node may be coupled to the entity owning physical products from or for which data, particularly, the battery data associated with the battery identifier or the battery passport associated with the the battery identified, is generated. The data, particularly the data relating to the battery identified, may be generated by a third-party entity on behalf of the entity owning physical products from or for which data is generated. The data owner may be the producer of the material and / or component(s) contained in the battery, the producer of the battery or the end product producer using the battery to produce end products containing the battery. The data owner may be the production producing the material and / or component(s) contained in the battery, the production producing the battery or the production producing end products containing the battery. Via the decentral identifier and its unique association with the data owner and the battery data or battery passport, access to the respective data may be controlled by the data owner. The battery data or battery passport may be accessible for the data owner. The data owner may hence directly or indirectly own or control the battery data or battery passport. The battery data or battery passport may be stored in a storage environment of or associated with the data owner. The data relating to the product identified may be stored in a storage environment accessible by the data owner. The data owner may control access to the battery data or battery passport via the data providing service of the data owner. The data owner may control access to the battery data or battery passport. The battery data or battery passport may be associated with the data owner. The data owner may be the owner or controller of the battery data or battery passport . The battery data or battery passport may be stored in a storage environment of or under control by the data owner. In this sense, the data owner may relate to the entity having access to the battery data or battery passport or parts thereof and controlling access by decentral data providing network nodes of the decentral computing environment to the battery data or battery passport or parts thereof.

[0208] In particular, the decentral identifier may be associated with material data specifying the material composition of one or more component(s) of the battery. The decentral battery identifier may be associated with the battery 402 and the material data may specify the material composition of one or more component(s) of the battery 402.

[0209] The produced battery pack, such as Lithium-ion battery pack 372, may be used to produce a machine powered by an electric engine, such as an electric vehicle or a vehicle comprising a combustion engine and an electric engine.

[0210] FIG. 6A illustrates a block diagram of an example system for generating component data set(s) associated with component(s) and for providing the generated component data set(s) for access by decentral data consuming nodes. The component may be a component of a battery, such as an electrode, a battery cell, a battery module, a separator, a cell casing, a battery management system, a cooling system, mechanical subsystem or a battery pack housing. The component may be any component produced by upstream production stage(s) with respect to the battery production stage. The asset generation system 646 may be configured to perform the method illustrated in FIG. 9. The system may be associated with a production, such as a chemical production or a discrete production, producing the component(s). The component may be produced or producible by the production. Produced components may include physical entities of components having been produced by the production. Producible components may include components not yet having been produced by the production. Producible components may be producible by one or more production processes performed within the production. With reference to FIG. 7, the component 706 may be produced or producible using one or more input material(s) 702. The component may comprise or be any component produced by the production 704 and provided at any exit point of the production 704. The production 704 may be a chemical production. The production 704 may be a discrete production. The input material may include starting material used in a production process performed within production 704 to produce the component. An input material can be used in any process step of the production process. This means, the intermediate output product of the one production plant of production 704 can correspond to the input material of a subsequent production plant of production 704. Input material may include recycled material. The input material may comprise or be any input material entering the production 704. The input material may comprise or be any input material provided at any entry point of the production 704.

[0211] The component may be produced via one or more process steps from the input material(s) 702 within production 704. The process steps may involve chemical reactions and / or physical processes and / or assembly processes involving the assembly of different discrete input material(s) and / or processes involving chemical input materials and discrete input materials, such as filling processes. The input material may be used in one or more of such production step(s). The input materials 702 may enter the system boundary 714 of the production 704 at the entry point, such as a production plant or a material storage associated with the production 704. The amount of input material entering the system boundary 714 of the production 704 may be measured, for example using sensor 708a. Sensors 708a include sensors configured to measure an amount of input material, such as a weight and / or a volume. Chemical and / or physical properties of the input material may be measured, for example using sensor 708b, upon passing system boundary 714 of the production 704. The measured data may be used to determine at least one chemical and / or physical property of the respective input material. Examples of chemical properties include heat of combustion, enthalpy of formation, toxicity, chemical stability in a given environment, flammability, oxidation state(s), ability to corrode, combustibility, acidity and basicity, chemical composition, recyclate content used for producing or manufacturing the input material, biobased content used for producing or manufacturing the input material, renewable content used for producing or manufacturing the input material, biodegradability, and / or pH value. Examples of physical properties include absorption, brittleness, boiling point, capacitance, color, concentration, density, ductility, distribution, efficacy, elasticity, electric charge, electrical conductivity, electrical impedance, electric potential, flow rate, fluidity, hardness, heat capacity, inductance, intrinsic impedance, luminance, luminescence, luster, mass, melting point, opacity, permeability, permittivity, plasticity, pressure, radiance, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tension, thermal conductivity, thermal resistance, viscosity, volume and / or wave impedance.

[0212] An operating system 716 of the production 704 may monitor and / or control the production 704 based on operating parameters of the different processes. The operating system 716 may receive production demand data associated with the production planning for the production 704. The production demand data may be produced from target production capacities for one or more component(s) produced by the production 704. The production demand data may be produced from pre-defined production capacities or data-driven models that relate production capacities to market demand data or quantities consumed at the consumption location. The production demand data may include target capacities for components produced by the production 704 . The operating system 716 may further receive a bill of materials associated with components to be produced. The bill of materials may include material data associated with the input materials used to produce the component, process data associated with the production chain for producing the component and / or component data associated with the component, such as a product specification data or data on the amount of component to be produced.

[0213] Based on the received production demand data and the bill of materials, material demand data may be determined. The material demand data may include data on the amount of input material required to produce the target capacities of component. The material demand data may include input material identifiers associated with input materials required to produce the component and data on amounts of input material for respective input materials. The material demand data may include one or more material specifier(s) per input material identifier signifying the material specification. The material demand data may include data on the material amount per input material identifier signifying the amount of material to be supplied. The material demand data may specify the production chain(s) of the production 704. The material demand data may include a bill of materials for one or more production chain(s) of the production 704. The material demand data may include one or more recipe(s) specifying one or more material(s) for production process(es) of the production 704. The determined material demand data may be provided for access by a supplier system associated with a supplier outside the physical system boundary of the production 704. Material supply may be triggered by the supplier system accessing the material demand data.

[0214] The amount of component(s) resulting from processes performed within production 704 may be measured using a sensor, such as sensor 708b. The measured data may be stored in one or more databases associated with operating system 716. Moreover processes performed within production 704 may be monitored using sensors, such as sensors 708b, and the generated monitoring data may be stored in one or more databases associated with operating system 716. The monitoring data may be interrelated with a digital component identifier associated with the respective component. Physical and / or chemical properties of produced components may be measured by sensors, such as sensors 708a. Physical and / or chemical properties may include the properties previously described. The measured and / or determined chemical and / or physical properties of the produced components may be stored in one or more databases associated with operating system 716. The measured and / or determined chemical and / or physical properties of the produced components may be interrelated with a digital component identifier associated with the respective component.

[0215] The produced component 706 may be provided at one or more exit points of the production 704. The component 706 may exit the system boundary 714 of the production 704. The operating system 716 may include asset generation system 646. The operating system 716 may be associated with asset generation system 646 (not shown). Asset generation system 646 may be configured to generate component data set(s) (e.g. asset(s)) associated with component(s) produced by production 704, for example as described in the context of FIG. 9.

[0216] Referring back to FIG. 6A and with continued reference to FIG. 7, the asset generation system 646 may generate component data set(s) in response to receiving a trigger. The trigger may be associated with or may include trigger data. The trigger data may include data associated with component produced by production 704. The trigger may be generated by trigger generator 712. Trigger generator 712 may be part of a packaging line or may be present within a storage location, such as a warehouse. Trigger generator 712 may include sensor(s) configured to detect produced component(s) and / or packaged components. The sensor(s) may be configured to detect an identification element physically attached to the produced component or the packaged component. The sensor data may be used by trigger generator 712 to generate trigger data including data associated with the produced component. Data associated with the produced component may include a digital component identifier associated with the produced component. The trigger may be generated by a user, for example using a front-end application allowing to generate trigger data. The front-end application may display data associated with produced components, such as component name(s), component quantities, component identifiers, etc.. The data associated with the component may be gathered from the one or more databases storing such data. The user may select component(s) displayed by the front-end application. In response to selecting component(s), a back-end application connected to the front-end application may generated the trigger data by collecting digital component identifier(s) associated with the selected component(s). The collected digital component t identifier(s) be used to generate the trigger data.

[0217] The trigger or trigger data may be received by data gathering unit 622 of asset generator service 606. Data gathering unit 622 may be connected to a data source layer 620. The data source layer 620 may include one or more databases, such as DB 1 614, DB 2 616 and DB 3 618. The databases may be distributed data sources. The distributed data source may be a data lake comprising component data from a plurality of distributed data sources. A distributed data source may be a collection of data stored at different sites of a computer network. Each site might expose a degree of autonomy, providing services for the execution of local applications, but also participating in the execution of a global application. For instance, a distributed data source may be a distributed database. A distributed database can be created by splitting and scattering the data of an existing database over different sites or by federating together multiple existing databases. Each data source may contain only a fragment of the data associated with the battery component. This leads to a fragmentation of said data. Two common types of data fragmentation are horizontal fragmentation, wherein (possibly overlapping) subsets of data tuples are stored at different sites; and vertical fragmentation, wherein (possibly overlapping) subtuples of data tuples are stored at different sites. More generally, the data associated with the battery component may be fragmented into a set of relations (tables of a relational database, distributed across multiple sites). The one or more distributed data sources may contain component data associated with produced components. The component data may include at least one measured physical and / or chemical property of produced component(s) and / or at least one physical and / or chemical property determined from collected data associated with the production and / or the use of produced component(s) as previously described. At least one of the distributed data sources may contain data instances that relate to the component for which the system 710 is configured to generate the component data set(s). The data source layer 620 may be owned or controlled by the data owner of the data associated with component data. The data source layer 620 may be associated with the data owner of the component data. Data gathering unit 622 may be configured to gather component data based on received trigger data (e.g. data associated with produced component(s) from the data source layer 620, for example as described in the context of FIG. 9.

[0218] The component data gathered by data gathering unit 622 may be provided to data transforming unit 624. Data transforming unit 624 may be configured to generate component data set(s) by transforming component data gathered by data gathering unit 622 based on one or more rule(s) retrieved from rule DB 612, for example as described in the context of FIG. 6B. Transforming may include filtering the gathered component data, aggregating component data gathered from multiple data sources into a given data structure, attribute construction to create or add new attributes to the component data based on existing attributes, discretization to convert continuous component data values into sets of data intervals with specific values, generalization of gathered component data to convert low-level data attributes into high- level data attributes, manipulation to change or alter gathered component data and / or normalization to converts component data into another data structure to limit the occurrence of duplicated data. The rule(s) may define key-value pair(s) to be included in the generated component. The rule(s) may define value(s) to be included in the generated component. The rule(s) may define unit(s) for data point(s) and / or one or more conversion(s) to convert a unit associated with a data point into another unit. The rule(s) may define key-value pair(s) for component property data, component identifier data, component name data, component producer data, component declaration data, component safety data, emission data, component recyclate content data, component biobased content data, component biodegradability data, component production data, component certificate of analysis data, component certificate data, component life cycle data, component storage instruction data, component assembly instruction data and / or component operating condition data. A rule may define key-value pairs for per data category. A rule may define key-value pairs for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. Gathered data may be aggregated and filtered to extract the value(s) matching the key(s) defined in the rule(s) from the aggregated data The generated component data sets may include one or more data points. The component data sets may include one or more key-value pairs. The generated component data sets may include at least a part of the gathered component data. The generated component data set(s) may include component property data point(s), component identifier data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s). The component data set(s) may include at least a part of the gathered component data in tabular form. Use of rule(s) associated with a battery produced from such component(s) allows to ensure that component data point(s) required according to a data model, such as an aspect model, associated with batteries or battery types are contained in the component data set, hence avoiding missing data point(s) during generation of battery passport associated with batteries using said data model. The transformation allows to aggregate the gathered component into a given data data structure, such as a tabular data structure, without the use of complex data models, hence facilitating generation and sharing of component data set(s) within the battery ecosystem. Such sharing may enable more efficient production and / or recycling processes based on the shared component data, for instance component composition data. The tabular data structure can be readily consumed via a decentral network by a consumer backend configured to verify the consumed data and to persist verified consumed data to data storages for generation of battery passports (see for example FIG. 13A and FIG. 13B). Verification by the consumer side ensures that the battery passport contains all data required by a data model used to generate such passport, hence allowing to reduce the complexity associated with the component data set generation at the provider side by avoiding the use of complex ata models during generation of the component data set(s). This may enable reliable sharing of component data of component(s) irrespective of the existence of data models for such components since the rule(s) required to transform the gathered component data may be readily derived from or generated based on the data model associated with batteries or battery types.

[0219] Data transforming unit 624 may further be configured to provide the generated component data set(s) (hereinafter also referred to as asset(s)) to data provider unit 644. Data provider unit 644 may be configured to provide the received component data set(s) to a database for storage, such as assets DB 604. The asset(s) may include or be associated with the digital component identifier associated with the component. This may allow to retrieve the asset based on the digital component identifier. The asset(s) may be persisted by data transforming unit 624 in assets DB 604. Assets DB 604 may be configured to store component data set(s) generated by data transforming unit 624. Assets DB 604 may be configured to provide component data set(s) to data transfer service 602.

[0220] Data provider unit 644 may further be configured to provide data included in the generated component data set(s), such as the digital component identifier, to asset publisher service 608. Asset publisher service 608 may be configured to generate group access data associated with the respective component data set. The group access data may identify access control groups including decentral participant identifier(s) associated with decentral network participants permitted to access at the respective component data set. The group access data may include a group access data identifier. The group access data may further identify one or more authorization rule(s) defining access to and / or usage of the component data set. Asset publisher service 608 may further be configured to generate a contract template including the digital component identifier and the group access data identifier. The contract template may hence be associated with the component data set as well as respective group access data. The contract template may further include access data associated with assets DB 604. The access data may include a locator or pointer to the assets DB 604 storing the respective component data set. This may allow to access the respective component data set based on data included in the contract template, e.g. the digital component identifier and the access data. The group access data and contract template may be generated by asset publisher service 608 per data included in the component data set, for example per digital component identifier. The generated group access data and contract template may be provided to decentral data providing node 118 connected to asset generation system 646.

[0221] Decentral data providing node 118 may be part of a decentral network, such as decentral network 134 described in the context of FIG. 1 and FIG. 2. Decentral data providing node 118 may be configured to provide component data set(s) in response to a request received from decentral data consuming node(s), for example as described in the context of FIG. 8. Decentral data providing node 118 may be configured to control access to component data set(s) based on associated group access data and contract template generated by asset publisher service 608, for example as described in the context of FIG. 8. Decentral data providing node 118 may be associated with a participant of the battery ecosystem, such as a producer of the component(s).

[0222] Data transfer service 602 may be configured to gather component data set(s) from assets DB 604 in response to a request from decentral data providing node 118. Data transfer service 602 may be configured to fetch asset metadata from assets DB 604 based on data received from decentral data providing node 118. Data transfer service 602 may be configured to parse the fetched metadata to determine group access data associated with the respective component data set and / or the storage location of the respective component data set. Data transfer service 602 may be configured to gather respective component data set(s) from assets DB 604 based on the fetched metadata. Data transfer service 602 may be configured to provide the gathered component data set(s) to decentral data providing node 118.

[0223] The system may not comprise a decentral registry storing access elements allowing access to the component data set(s) stored in assets DB 604. Hence, component data set(s) may not be located by querying the decentral network using the digital component identifier but may only be accessed directly from decentral data providing node 118 using the digital component identifier. Hence, location data pointing to the dedicated storage storing the component data set as well as the component identifier may be required to access the respective component data set. The location data in combination with the component identifier of the component data set may result in a unique identifier allowing to uniquely identify a given component data set within the decentral network.

[0224] FIG. 6B illustrates a diagram showing an example of gathering component data and transforming at least part of the gathered component data using a rule-based engine. Transforming at least a part of the gathered component data may result in generation of component data set(s) as described in the context of FIG. 6A.

[0225] Data transforming unit 624 may include rule based engine 628. The rule based engine 628 may operate on individual data point(s), multiple data point(s) and / or the gathered component data. The rule based engine 628 may operate on data gathered per component identifier individually. This allows to transform gathered component data per component, hence allowing a more granular transformation of the component data. Rule based engine 628 may receive a request to transform gathered component data. The request may contain at least a part of the gathered component data. Component data may be gathered (see operation 626) by data gathering unit 622 from a data source layer 620 as described in the context of FIG. 6A. Rule based engine 628 may be configured to determine component identifier(s) associated with the component data. For instance, rule based engine 628 may parse the received component data to determine the respective component t identifier(s). The rule based engine 628 may have access to one or more rule(s). The rule based engine 628 may include one or more rule(s). The one or more rule(s) may be present within a rule template. The one or more rule(s) may be stored in a data storage, such as rule DB 612. The one or more rule(s) or rule template(s) may be provided to rule DB 612 by a user. The one or more rule(s) may correspond to unstructured data associated with instructions related to transformation operation(s). The rule template(s) may correspond to unstructured data associated with instructions related to transformation operation(s). The one or more rule(s) or the rule template may be included in a file provided by the user. The one or more rule(s) or the rule template(s) may be associated with component type identifier(s) and / or component data identifier(s). Rule based engine 628 may generate a request to obtain one or more rule(s) from rule DB 612. The request may contain the respective component identifier(s).

[0226] One or more rule(s) associated with the component data to be transformed (e.g. one or more applicable rule(s)) may be provided to rule based engine 628 in response to the request. The one or more rule(s) may be associated with batteries produced from the component associated with the component data to be transformed may be used as input material to produce the respective battery. The one or more rule(s) may be associated with or derived from or generated based on a data model associated with at least one of the batteries or battery types. Hence, the one or more rule(s) may ensure that data point(s) for such components required according to the data model may be included in the generated component data set. The one or more rule(s) may be defined by the mandatory component data points present within the data model. The one or more rule(s) may be generated based on the mandatory component data points present within or defined by the data model. This may ensure that component data required by the data model is included in the generated component data set. The one or more rule(s) may be associated with component identifier(s) and / or component type identifier(s). A mapping table may be used to map component identifier(s) to corresponding component type identifier(s). The component type identifier(s) may be associated with component type(s). The mapping table may be stored in a separate database (not shown). Rule based engine 628 may be configured to gather component type identifier(s) based on determined component identifiers) and to request rule(s) based on the gathered component type identifier(s). This may allow to gather rule(s) associated with component type identifier(s) based on component identifier(s), hence avoiding generation of rule(s) per component identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1318..

[0227] The one or more rule(s) may define aggregation rule(s) for aggregating component data gathered from multiple data sources into a given data structure. The given data structure may be a tabular representation. Aggregation may hence result in filling gathered component data into a tabular data structure. The one or more rule(s) may define filters to filter gathered component data. The filters may be associated with or relate to the data model associated with at least one of the batteries or battery types. The filters may define data point(s) to be included in the generated component data set. For instance, a filter may define one for more component property data point(s), component identifier data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s). A filter may define data point(s) per data category. A filter may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. This may ensure that component data required by the data model is included in the generated component data set. The one or more rule(s) may define attribute construction(s) to create or add new attributes to the gathered component data. The one or more rule(s) may define manipulation(s) to convert component data point(s). For instance, data point(s) present within the gathered component data may be converted from one unit into another unit. This may ensure that the generated component data set includes data points associated with a unit required by the data model. The one or more rule(s) may include a trigger condition and a corresponding group of one more actions. The trigger conditions may involve a set of variables, sometimes called “working memory”, which may contain data (sometimes called “facts” or “data tuples”) representing the states of pertinent real-world items. The one or more action(s) may include attribute construction, filters and / or manipulations. A given component identifier and / or component identifier may be associated with rule(s) defining aggregation, rule(s) defining filters, rule(s) defining attribute construction, rule(s) defining manipulations and / or rule(s) including a trigger condition and action(s). The rule(s) may be associated with a given order.

[0228] Rule based engine 628 may be configured to initialize the rule engine (see operation 632). Initialization of the rule engine may include generating rule data executable by a processor included in rule based engine 628. The rule data may include or correspond to executable logic. This may allow to transform rule(s) or rule template(s) present in unstructured data form into code that can be executed by the processor. Execution of the code may result in applying the executable rule data to the gathered component data (see operation 634) to transform the component data according to the obtained rule(s). Execution of the logic may result in matching gathered component data to condition(s) included in the executable logic, evaluating the condition(s) with matched component data and triggering execution of rule actions based on condition evaluation results. Transforming the component data may include filtering gathered component data. Filtering the gathered component data may include comparing individual data points present within the gathered component data to data points defined by the filter(s) to determine component data points to be included in the component data set. Transforming the component data may include comparing attributes of the gathered or filtered component data to attributes defined in rule(s) to determine whether new attributes have to be created or added to the gathered or filtered component data. In addition or alternatively, transforming may include comparing attribute(s) included in the gathered or filtered component data or component data including added or created attribute(s) to attribute(s) included in the modification rule(s). The modification rule(s) may include a trigger condition which may be associated with one or more action(s), for example unit conversion, if the trigger condition is satisfied and / or error handling if application of filters results in empty data points due to lack of data points in the gathered component data. The trigger condition may be satisfied if the attribute(s) included in the gathered or filtered component data or component data including added or created attribute(s) are not matching attribute(s) defined in the modification rule(s). Operations performed by rule based engine 628 may be determined by rule(s) gathered from rule DB 612. For instance, rule(s) gathered from rule DB 612 may determine whether rule based engine 628 operates on individual data point(s) and / or multiple data point(s) and / or the whole gathered component data.

[0229] Rule based engine 628 may be configured to determine whether the gathered component data can be transformed by one or more applied rule(s) (see operation 636). Gathered component data may not be transformed or only partially transformed (e.g. transformation may result in at least one error associated with applying one or more obtained rule(s) to the gathered component data) if the gathered component data does not include data point(s) required according to one or more obtained rule(s). Rule based engine 628 may provide the generated component data set to assets DB 604 responsive to the gathered component data being successfully transformed (e.g. responsive to generation of a component data set by applying one or more obtained rule(s) without resulting in an error. If at least a part of the gathered component data could not be transformed, rule based engine 628 may proceed to operation 638. In operation 638, rule based engine 628 may generate message data indicating that at least part of the gathered component data could not be transformed. The message data may include an indication which data point(s) of the gathered component data could not be transformed. The message data may be provided to a display device configured to display data received from rule based engine 628. The display device may comprise a graphical user interface 640. The display device may display the message in response to receiving message data from rule based engine 628. This allows to trigger correction or updating of data point(s) identified as not matching one or more of the obtained rule(s). After correction or updating of respectively identified data point(s), gathering and transformation of updated or corrected component data may be initiated.

[0230] FIG. 8 illustrates an example of a decentral system for accessing data associated with component(s). The component may be a battery component, such as an electrode, a battery cell, a battery module, a separator, a cell casing, a battery management system, a cooling system, mechanical subsystem or a battery pack housing. The component may be any component produced by upstream production stage(s) with respect to the battery production stage. The decentral system may be a decentral peer-to-peer network 134 as described in the context of FIG. 1 and FIG. 2.

[0231] The component may be associated with component data set(s). component data set(s) may be generated as described in the context of FIG. 6A to FIG. 7. The component data set(s) may be stored in assets DB 604 associated with data transfer service 602. Assets DB 604 may be associated with a decentral provider node 118. The decentral provider node may be associated with a decentral network participant. The decentral network participant may be the producer of the component. The decentral network participant may be the data owner of the component data set(s) stored in assets DB 604. The component data set(s) may represent at least a part of a digital twin of the physical entity of the component. The digital twin may be a digital representation of the physical entity. The digital twin may hence represent a digital version of said physical entity. Once created, the digital twin may be used to represent the physical entity of the component in a digital representation of a real-world system.

[0232] The decentral system may be used to gather component data associated with component(s) used to produce batteries as described in the context of FIG. 13A and FIG. 16. The component data may correspond to component data set(s) stored in assets DB 604. The component data may be gathered by a downstream production stage with respect to the production stage producing the battery.

[0233] The decentral system may include one or more decentral participants, such as a data consumer and a data provider. The data consumer and the data provider may be connected via a decentral network, such as a decentral peer-to-peer network (see for example FIG. 1 and FIG. 2). The data provider may provide data, such as component data set(s), associated with a component to data consumer. The data consumer may request component data, such as the component data set(s), from the data provider. The data provider may correspond to an entity producing components, such as battery components. The data consumer may correspond to an entity using the produced component(s) and / or an entity performing the methods disclosed in FIG. 13A to FIG. 16. The data consumer may correspond to a downstream participant of the production chain used to produce the battery. The data provider may be associated with a data provider environment 808. The data consumer may be associated with a data consumer environment 802. The environments may include one or more node(s). The node(s) may be connected via peer-to-peer communication channels to allow data transfer between the nodes, as described in the context of FIG. 1 and FIG. 2. The decentral system may include more or less environments than illustrated in FIG. 8.

[0234] The participants of the decentral network may be associated with decentral participant identifiers. Each participant of the decentral network may be associated with one or more decentral participant identifier(s). The decentral participant identifier may comprise any identifier uniquely associated with a participant of the decentral network and / or with a production site of the participant of the decentral network. The decentral participant identifier may include letters and / or numbers. The decentral participant identifier may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The decentral participant identifier may be associated with or may include a verifiable claim or credential. The verifiable claim may be issued by a central or decentral identity issuer making one or more claims about a subject, such as an entity being a trustworthy participant of the decentral network. For instance, the issuer may make a claim about a consumer (e.g. the entity operating data consuming network node(s)) or a provider (e.g. the entity operating data providing network node(s)) the decentral participant identifier is associated with. The verifiable claim may include those claim(s) as well as proof instructions to prove that claim(s) have not been tampered with and were indeed issued by the claims issuer. The verifiable claim may also include duration information metadata that defines a period of time that the verifiable claim is valid for use or that defines a specific number of times that the verifiable claim is authorized for use. The verifiable claim may also include a DID of the claims issuer and / or the subject, such as an entity. The verifiable claim may be signed by the claims issuer. The claims issuer may provide the verifiable claim to a claims holder, such as the entity, for presentation to any relying party that relies upon the veracity of those claims, such as a decentral data provider. The signature of the verifiable claim may be validated with a public key associated with the claims issuer to determine that the respective entity is a trusted entity within the decentral network. The verifiable credential may be presented by a decentral data consuming network node and may be used by a decentral data providing network node to verify that the decentral participant associated with the decentral data consuming network node is a trusted entity within the decentral network prior to providing access to data, such as component data, hence ensuring that the component data can be exchanged in a secure and controlled manner within the decentral network.

[0235] Data consumer environment 802 may include a consumer node 122 (e.g. decentral data consuming network node 122) and a consumer backend 804. Consumer backend 804 may include or correspond to the system illustrated in FIG. 13A and FIG. 13B. Consumer node 122 may be configured to communicate with consumer backend 804. Consumer node 122 may be configured to receive data from the consumer backend 804. Consumer node 122 may be configured to receive data from provider node 118. Consumer node 122 may be configured to request data from provider node 118. Consumer node 122 may be configured to receive data from the consumer backend 804 and configured to receive and / or request data from provider node 118. Consumer node 122 may be configured to gather component data (also denoted as component data hereinafter) stored in assets DB 604 associated with the provider node 118 of the data owner. Consumer backend 804 may be configured to send a request for data to consumer node 122, for example as described in the context of FIG. 13A to FIG. 16. Consumer backend 804 may be configured to process component data received from consumer node 122, for example as described in the context of FIG. 13A to FIG. 16.

[0236] Data consumer environment 802 may be associated with a participant of the battery ecosystem, such as the battery ecosystem illustrated in FIG. 1 and FIG. 2. For instance, data consumer environment 802 may be associated with a component producer, such as chemical product user 106, receiving input material(s) and producing component(s) using the input material(s).

[0237] Data consumer environment 802 may be associated with an entity performing the methods illustrated in FIG. 14 to FIG. 17. The entity performing such methods may be a participant of the battery ecosystem. The entity performing such methods may not be a participant of the battery ecosystem but may function as a service provider providing validated component data for generation of battery passports. The service provider may gather component data from various provider environment(s) associated with component data of components used to produce a given battery. The service provider may process the gathered component data as described in the context of FIG. 13A to FIG. 17. The service provider may provide the processed component data for generation of battery passports.

[0238] Data provider environment 808 may include provider node 118, data transfer service 602 and assets DB 604. Data provider environment 808 may include the asset generation system 646 illustrated in FIG. 6A, FIG. 6B and FIG. 7. Data provider environment 808 may be associated with a data owner, such as a manufacturer producing the component(s). Data provider environment 808 may include assets DB 604 storing component data set(s) of produced component(s). Assets DB 604 may be a dedicated storage associated with the data owner. The data owner may own such dedicated storage. The data owner may have access to such dedicated storage. Provider node 118 may be configured to provide data, such as component data set(s) stored in assets DB 604. Provider node 118 may be configured to perform authentication and authorization step(s) prior to providing component data, for example as described with reference to FIG. 9 later on. Provider node 118 may be coupled to data transfer service 602 configured to gather component data set(s) from assets DB 604 in response to a request received from provider node 118 and to provide the gathered component data set(s) to provider node 118.

[0239] FIG. 9 illustrates a flow chart of an example method for generating component data set(s) associated with component(s). The method illustrated in FIG. 9 may be implemented by the system illustrated in FIG. 6A to FIG. 7. The component may be a battery component, such as described in the context of FIG. 8. The component may be used by one or more downstream participants of the battery ecosystem as input material to produce one or more batteries. The component may be produced or producible by a production, such as illustrated in FIG. 7.

[0240] With reference to FIG. 12, data associated with the component may be provided (see block 902). The data may be provided by a computing system connected to the system performing the method of FIG. 9, such as an asset generation system 646. The data may be provided by a user via a communication interface to the system performing the method of FIG. 9, such as an asset generation system 646. The data may be provided to data gathering unit 622 of asset generation system 646. The provided data may be generated in response to receiving a trigger, for example as described in the context of FIG. 7. Data associated with the component may include digital component identifier(s). The digital component identifier(s) may include component name, component number, LOT number, batch number or a combination thereof.

[0241] With continued reference to FIG. 12, component data may be gathered based on the provided data (see block 904). The component data may be gathered from a data source layer, such as data source layer 620 described in the context of FIG. 6A and FIG. 6B. The component data may be gathered from data source layer 620 based on digital component identifier(s) included in the data provided in block 902. The component data may be gathered by data gathering unit 622. The component data may include component identifier(s), property data associated with the component, the component name, the component producer component declaration data, component safety data, emission data associated with the component, recyclate content data associated with the component, biobased content data associated with the component, biodegradability data associated with the component, production data associated with the component, certificate of analysis data associated with the component, certificate data associated with the component, life cycle data associated with the component, storage instruction data associated with the component, assembly instructions associated with the component and / or operating conditions associated with the component as described in the context of FIG. 6A.

[0242] A component data set may be generated by transforming the gathered component data using a rulebased engine including one or more rule(s) associated with at least one of the batteries produced from the component (see block 906). The one or more rule(s) may be associated with or derived from or generated based on a data model associated with the battery or the battery type. The battery may be produced from the component by using the component as input material within at least one production step of the production process of the battery. The production process of the battery may include one or more production steps. The production steps may be performed by one or more entities of the battery ecosystem. The component may be used as input material within at least one of such production step.

[0243] With reference to FIG. 6B, FIG. 10 and FIG. 12, transforming the gathered component data by the rulebased engine may include identifying one or more rule(s) applicable to the gathered component data. The gathered component data may be transformed by data transforming unit 624, The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to a component identifier included in the gathered component data. The identifier associated with each applicable rule may include a component identifier matching the component identifier included in the gathered component data. The identifier associated with each applicable rule may include a component type identifier related to the component identifier included in the gathered component data. The component type identifier related to the component identifier included in the gathered component data may be determined based on mapping data as described in the context of FIG. 6B.

[0244] With continued reference to FIG. 6B, FIG. 10 and FIG. 12, executable logic may be generated from the one or more applicable rule(s). The executable logic may be generated by data transforming unit 624. Executable logic may include machine code, interpretable code, bytecode, and / or code that runs on a virtual machine. The logic included in the applicable rule(s) may be encoded in the executable logic. The logic included in the applicable rule(s) may be mirrored in the executable logic. Upon finalizing the generation of the executable logic, data transforming unit 624 may sent a response to data gathering unit 622 indicating finalizing the generation of the executable logic.

[0245] With continued reference to FIG. 6B, FIG. 10 and FIG. 12, a component data set may be generated by transforming the gathered component data by executing the generated executable logic by the rule-based engine subject to rule execution criteria. Data gathering unit 622 may sent a request to data transforming unit 624 to transform the component data based on the executable logic generated for the applicable rule(s). Rule execution criteria may include rule execution order, exemptions and conditions. For instance, the rule designated in the condition is executed first as it triggers the execution or exemption action in the execution of the rule with which it is associated. The generated component data set(s) may be provided from data transforming unit 624 to data provider unit 644.

[0246] It may be verified whether the gathered component data could be transformed according to one or more applicable rule(s) (e.g. one or more rule(s) gathered from rule DB 612 based on the gathered component data) (see block 908). Verification may be performed as described in the context of FIG. 6B. If the gathered component data could be transformed according to the applicable rule(s), e.g. application of such rule(s) did not result in any error, the method may proceed to block 912. Otherwise message data may be generated and provided, for example as described in the context of FIG. 6B.

[0247] The generated component data set may include at least a part of the gathered component data. The part of the component data may be defined by the one or more applied rule(s). The part of the component data may be in tabular form. The generated component data set may include component property data point(s), component identifier data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s).

[0248] The generated component data set may be provided for access via a decentral network under control of the data owner of the component data set. With reference to FIG. 12, this may include storing the generated component data set in a data storage, such as assets DB 604, for example as described in the context of FIG. 6A. With continued reference to FIG. 12, this may further include generating group access data and a contract template as described in the context of FIG. 6A. The group access data and contract data may be used to control access to the associated component data set, for example as described in the context of FIG. 14.

[0249] Use of rule(s) associated with a battery produced from such component(s) allows to ensure that component data point(s) required according to a data model, such as an aspect model, associated with the battery or battery type are contained in the component data set, hence avoiding missing data point(s) during generation of a battery passport associated with the batter using said data model. The transformation allows to aggregate the gathered component data into a given data data structure, such as a tabular data structure, without the use of complex ata models, hence facilitating generation and sharing of component data set(s) within the product ecosystem. Such sharing may enable more efficient production and / or recycling processes based on the shared component data, for instance component composition data included in the shared component data. The tabular data structure can be readily consumed via a decentral network by a consumer backend configured to validate the consumed data and to persist validated consumed data to data storages for generation of battery passports. Validation by the consumer side ensures that the battery passport contains all data required by a data model used to generate such passport, hence allowing to reduce the complexity associated with the component data set generation at the provider side by avoiding the use of complex data models during generation of the component data set(s). This may enable reliable sharing of component data of component(s) irrespective of the existence of data models for such components since the rule(s) required to transform the gathered component data may be readily derived from the data model associated with the battery or battery type.

[0250] FIG. 11 illustrates a flow chart of a further example method for generating component data set(s) associated with component(s) of a battery. The method illustrated in FIG. 11 may be implemented by the system illustrated in FIG. 6A to FIG. 7. The component may be a battery component described in the context of FIG. 8. The component may be used by one or more downstream participants of the battery ecosystem as input material to produce one or more batteries. The component may be produced by a production, such as illustrated in FIG. 7.

[0251] Incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data may be received via a decentral network (see block 1102). The decentral network may be decentral network 134, 208 described in the context of FIG. 1 and FIG. 2. The incident data may be generated by a consumer environment, for example as described in the context of FIG. 17. The incident data may include the non-validated component data point(s), the component identifier and an indication indicating lack of validation. The indication may be a classifier, such as “validation failed”, “not validated”. The data associated with the rule(s) or rule template may include unstructured data, as described in the context of FIG. 6B. The data associated with the rule(s) or rule template may include executable logic generated from the rule(s) or rule template.

[0252] With reference to FIG. 8, the incident data may be received by a data provider environment 808 associated with the non-validated component data. The data provider environment 808 may include a decentral consumer node configured to consume data provided via the decentral network (not shown in FIG. 8). The data may be provided by a data provider node associated with data consumer environment 802 (not shown in FIG. 8). The incident data may be provided to the consumer node of data provider environment 808 as described in the context of FIG. 17.

[0253] With reference to FIG. 6A, the incident data received by consumer node of data provider environment 808 may be provided by the consumer node to asset generator service 606. The incident data may be provided via data transfer service 602 to asset generator service 606.

[0254] With continued reference to FIG. 6A and based on the received incident data, component data associated with the component may be gathered. The component data may be gathered based on the component identifier included in the incident data. The component data may be gathered from a data source layer by asset generator service 606.

[0255] With continued reference to FIG. 6A and with reference to FIG. 6B, one or more rule(s) associated with the component may be updated based on the received incident data. This may include generating one or more rule(s) or a rule template from the incident data. The generated rule(s) or rule template may be associated with the component identifier or a corresponding component type identifier. The generated rule(s) or the rule template may be stored in a database containing rule(s) and rule template(s), such as rule DB 612 associated with rule based engine 628.

[0256] With continued reference to FIG. 6A and FIG. 6B, an updated component data set may be generated by transforming the gathered component data using a rule-based engine including the updated rule(s). The updated rule(s) may be applicable to the gathered component data, e.g. may be associated with a matching component identifier or corresponding component type identifier. The method may then proceed as described in the context of block 908 to 912 of FIG. 9.

[0257] Use of incident data to update rule(s) applicable to the component data associated with the incident data may allow to generate updated component data set(s) which may no longer fail validation using the rule(s) associated with the incident data. This may allow to provide - in response to a validation error occurring within a consumer environment validating such consumed component data - updated component data passing validation rule(s) which were not passed in the previous validation process. Use of such incident data to update rule(s) may hence allow to ensure that future component data set(s) may not result in the same validation error. This may result in a more efficient validation and ensures that validated component data is available for battery passport generation prior to providing such battery associated with the battery passport to a consumer. This allows the consumer, such as an end product user or recycler, to gather the passport data included in the battery passport associated with the battery and to use the gathered passport data to optimize and / or control production of battery containing products and / or to optimize and / or control recycling processes of battery containing products.

[0258] FIG. 13A illustrates a block diagram of an example system for validating component data associated with component(s) used to produce a battery. The component(s) may be used as production input(s) in one or more process step(s) associated with the production of the battery. The process step(s) may be performed by one or more entities. The asset validation system 1342 may be configured to perform the methods described in the context of FIG. 14, FIG. 15 and FIG. 17. The system may be associated with a battery production. The system may be associated with a component production using the component associated with the component data as production input to produce further components.

[0259] Asset validation system 1342 may include data transfer service 1302, stream storage system 1312 and data transforming unit 1304. Various databases, such as rule DB 1306, storage general 806 and storage application A 810 may be connected to data transforming unit 1304.

[0260] The asset validation system 1342 may be connected to a decentral data consuming node, such as node 122. The decentral data consuming node may be part of a decentral network, such as decentral network 134, 208 described in the context of FIG. 1 and FIG. 2. The decentral data consuming node 122 may be associated with a decentral participant. The decentral participant may be a participant of the product ecosystem associated with the product. The decentral participant may not be a service provider providing validated component data for generation of battery passports, e.g. may not be a participant of the battery ecosystem. With reference to FIG. 8, decentral data consuming node 122 may be configured to request access to component data set(s) at provider node(s) associated with such component data set(s). The component data set(s) may correspond to the component data to be validated by the system. The request may include the component identifier associated with the component data set(s) and a decentral participant identifier associated with the decentral participant operating consumer node 122. The request may be generated in response to data received from the system, for example received from data transfer service 1302. The data received from the system may include the component identifier(s) and associated access data pointing to decentral provider node(s), such as provider node 118. The access data may include endpoint(s) associated with the decentral provider node(s), such as URI(s). The request may be generated per component identifier and associated access data. The request received by the respective provider node(s) may be authenticated. Such authentication may be based on data related to an authentication mechanism. The authentication mechanism may be based on certificate(s) and / or token(s), for example a device certificate (X.509v3), a TLS connection certificate (X.509v3) and a ‘Dynamic Attribute Token’ (OAuth Access Token), associated with the respective decentral participant nodes, e.g. consumer node 122 and provider node 118. If authentication fails, no component data set(s) may be provided by respective data provider(s).

[0261] Provider node(s) may initiate contract negotiations with consumer node 122. Contract negations may be initiated upon successful authentication. Provider node(s) may provide electronic contract(s) to consumer node 122. The electronic contract may include one or more authorization rule(s) associated with the component identifier. The electronic contract may further include the endpoint(s) associated with the component data set(s). The endpoint(s) may point to the dedicated storage storing the respective component data set(s), such as assets DB 604. The electronic contract may be generated by the provider node(s) based on group access data and a contract template associated with the respective component identifier(s). The system may automatically accept the provided electronic contract(s). The system may be configured to parse the provided electronic contract(s) to determine the authorization rule(s) associated with the component data set(s) to be gathered. Consumer node 122 may provide data being indicative of the signature, such as a token, to respective provider node(s). If the electronic contract is not signed, consumer node 122 may likewise forward data being indicative of declining the contract to the respective provider node(s). Upon declining the contract, respective provider node(s) may terminate the connection and may not provide any component data set(s). Signature of such electronic contracts generated from group access data and a contract template associated with respective component identifier(s) ensures that the consumer node 122 and further systems, such as asset validation system 1342, handling the provided component data are complying to at least one authorization rule included in the electronic contract associated with the component data set(s). This may ensure that the component data set(s) may be exchanged in a secure and controlled manner, hence avoiding access to component data set(s) by unauthorized decentral network participants while allowing to provide the component data set(s) to decentral network participants required to use such provided component data set(s), for example to control and / or monitor production of the battery and / or to monitor and / or control recycling operations and / or to generate battery passports associated with the batteries.

[0262] With continued reference to FIG. 8, data providing node(s) may provide component data set(s) associated with component data identifier(s) included in the request received from consumer node 122 upon signature of the electronic contract. The component dataset(s) may be gathered from a dedicated storage, such as assets DB 604 as described in the context of FIG. 6A and FIG. 9.

[0263] Returning to FIG. 13A, consumer node 122 may provide the received component data set(s) to data transfer service 1302. Data transfer service 1302 may be connected to stream storage system 1312. Stream storage system 1312 may be connected to data transforming unit 1304. Data transforming unit 1304 may be positioned upstream from data transfer service 1302. Component data gathered via the decentral network may flow through data transfer service 1302 and stream storage system 1312 to data transforming unit 1304.

[0264] Data transfer service 1302 may be configured to receive component data from consumer node 122. The component data may represent a stream of data. Such a stream may be an ordered sequence of records received from consumer node 122 relatively continuously, i.e. not in accumulated batches or chunks. A record may for example comprise component data associated with a given component via a component identifier. A record may be in a tabular representation. A record maybe in an object representation, e.g. using JSON, an XML document. A record may be defined as data that can be delivered continuously in small chunks or increments. The records may or may not be time-ordered. Data transfer service 1302 may be configured to generate data package(s) including the component data received from consumer node 122. A data package may be generated by received component data set. The data package may include further data, such as a time stamp, a date stamp, the component identifier associated with the component data, the decentral participant identifier associated with the provider node, location data pointing to the dedicated storage storing the component data set or a combination thereof. The data package may represent a message or an event. The generated data package data may be provided to stream storage system 1312.

[0265] Stream storage system 1312 may be configured to store data packages received (e.g. pushed) from data transfer service 1302. The stream storage system 1312 may be configured to provide the stored data to data transforming unit 1304. The stream storage system 1312 may be configured to provide the stored data to data consuming unit 1308 of data transforming unit 1304. Stream storage system 1312 may comprise one or more persistent or non-persistent logs 1314, 1316. In this embodiment, stream storage system 1312 comprises two persistent or non-persistent logs 1314, 1316 (i.e. log 1 1314 and log 2 1316). Records stored in said logs may be ordered, for example by using IDs. This allows to identify a record within a specific log. A record may include a data package generated by data transfer service 1302.

[0266] Stream storage system 1312 may provide a streaming service or stream processing service between one or more streaming sources (e.g. data transfer service 1302) and one or more streaming sinks (e.g. log 1 1314 and log 2 1316). Stream storage system 1312 may act as a persistent or non-persistent stream sink for component data received from consumer node 122. For example, open-source software systems such as Apache Kafka ("Kafka") or Azure Event Hubs may act as a persistent stream sink.

[0267] Stream storage system 1312 may be configured to pull component data from data transfer service 1302. For instance, stream storage system 1312 may be configured to request component data from data transfer service 1302 at regular time intervals.

[0268] Stream storage system 1312 may be configured to determine if the received or pulled component data is already contained in the one or more persistent or non-persistent logs. If said component data is already contained in the one or more persistent or non-persistent logs, stream storage system 1312 may not store the received or pulled component data in said logs. If said component data is not contained in one or more persistent or non-persistent logs or is an update, stream storage system 1312 may be configured to store the received or pulled component data in the one or more persistent or non-persistent logs or to update component data present in the persistent or non-persistent log(s) with the received or pulled updated component data. This may avoid that the same component data is stored multiple times in the persistent or non-persistent log(s), hence avoiding redundant validation operations on the component data stored in stream storage system 1312.

[0269] Data transforming unit 1304 may be connected to the stream storage system 1312. Data consuming unit 1308 of data transforming unit 1304 may be connected to stream storage system 1312. Data consuming unit 1308 may be connected to one or more persistent or non-persistent logs (e.g. in this embodiment in log 1 1314 and log 2 1316) of stream storage system 1312 to ingest and process component data stored within the log(s). The stream storage system 1312 may be in a publisher-subscriber relationship with the data consuming unit 1308. For instance, data in one or more the logs(s) may be periodically read (e.g. pulled) by data consuming unit 1308. To avoid consumption of a data package stored in a log several times, such data package may be marked as consumed by stream storage system 1312. To avoid consumption of a data package stored in a log several times, an integer indicating the offset of the next data package to consume may be used. Such integer may be just one number for each persistent or non- persistent log. Such integer may be periodically checkpointed. Use of such an integer may allow data consuming unit 1308 to re-consume data packages by rewinding the integer to an old offset.

[0270] Data consuming unit 1308 may be connected to data validation unit 1310 of data transforming unit 1304. Data consuming unit 1308 may be configured to provide data packages gathered from stream storage system 1312 to data validation unit 1310 for validation of component data included in said data packages. Data consuming unit 1308 may be configured to extract component data from the data packages and provide the extracted component identifier and component data to data validation unit 1310. Data validation unit 1310 may be configured to validate component data (e.g. data packages received from stream storage system 1312) based on one or more rule(s) retrieved from rule DB 1306, for example as described in the context of FIG. 13A. Validation may include applying one or more rule(s) retrieved from rule DB 1306 to the component data. The component data may be validated if at least a part of the applied rules are fulfilled. Applying the rule(s) to the component data may include comparing the combination of component identifier and location data to a database storing such combinations of component identifier(s) and associated location data. Applying the rule(s) to the component data may include comparing data point(s) present within one or more rule(s) to individual data point(s) present within the component data to be validated. Applying the rule(s) to the component data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the component data to be validated. Applying the rule(s) to component data may include comparing the data defined in one or more rule(s) to the whole component data to be validated. The one or more rule(s) may be associated with a battery produced from the component(s). The one or more rule(s) may be associated with a data model of the battery or battery type. The data model may include a semantic description of the battery passport associated with the battery. The semantic description may include a semantic description of component data and battery data. The semantic description may include the structure of at least a portion of the battery passport, and / or properties of the battery passport. The properties of the battery passport set may include data types. The properties of the battery passport set may include possible or allowable values and / or value ranges. The properties of the battery passport set may be a physical unit of parameter(s) described by values contained in the battery passport. The data type(s) and associated value(s) and / or value range(s) of component data may be included in the one or more rule(s). This may allow to validate whether gathered component data fulfils the data type(s) and associated value(s) and / or value range(s) required for component data according to the data model. By validating the component data against one or more rule(s) generated from the semantic model, it may be ensured that component required by the data model is indeed included in the gathered component data, allowing to ensure that battery passport(s) generated from such validated component data include all required component data. Validation of gathered component data on data point level may allow to reliably perform the validation irrespective of the data structure of the component data. This may allow, in turn, to generate the component data without having to use complex data models. Instead, component data may be generated in a tabular representation by the data providers and may be used by data validation unit 1310 for validation of data point(s) included in the component data. The one or more rule(s) may define one for more component identifier data point(s), component property data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s). The rule may define data point(s) per data category. The rule may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data.

[0271] By validating the component data against one or more rule(s) generated from the data model, it may be ensured that component data required by the data model is indeed included in the gathered component data, allowing to ensure that battery passport(s) generated from such validated component data include all required component data. Validation of gathered component data on data point level may allow to reliably perform the validation irrespective of the data structure of the component data. This may allow, in turn, to generate the component data without having to use complex data models. Instead, component data set(s) may be generated in a tabular representation by the data providers and may be used by data validation unit 1310 for validation of data point(s) included in the component data set(s) received as component data by the data consumer side. The validated component data generated by data validation unit 1310 may include one or more validated component property data point(s), validated component identifier(s), validated component name(s), validated component producer data point(s), validated component declaration data point(s), validated component safety data point(s), validated component emission data point(s), validated component recyclate content data point(s), validated component biobased content data point(s), validated component biodegradability data point(s), validated component production data point(s), validated component certificate of analysis data point(s), validated component certificate data point(s), validated component life cycle data point(s), validated component storage instruction data point(s), validated component assembly instruction data point(s) and / or validated component operating condition data point(s).

[0272] Data validation unit 1310 may further be configured to determine the storage location to which the validated component is to be persisted. The storage location may be determined based on mapping data including a mapping between component identifier(s) and associated storage location data. The storage location data may include endpoint(s) associated with said storage location(s). The storage location(s) may be identified by way of storage location identifier(s) included in the storage location data. Such identifier(s) may be used to gather endpoint(s) associated with such storage location(s). The mapping data may include a first mapping between component identifier and component type identifier and a second mapping between component type identifier and associated storage location data. The mapping data may be stored in a database connected to data validation unit 1310 (not shown). Determining the storage location of validated component data may allow to persist validated component data in storage locations associated with given applications or systems(s). For instance, the validated component data associated with a given battery may be persisted in a storage location associated with a given application processing such validated component data. Processing may, for example include generation of battery passport(s) using such validated component data. Validated component data which may not be mapped to a given application may be persisted in a general storage, such as storage general 806.

[0273] Data validation unit 1310 may further be configured to provide the validated component data to the determined storage location, such as general storage general 806 or storage application A 810, for storage.

[0274] The asset validation system 1342 may further include incident data generator 1344. Incident data generator 1344 may be configured to generate incident data based on non-validated component data stored in a database, such as storage general 806. The non-validated component data may be associated with a classifier indicating non-compliance with one or more applied rule(s). The classifier may include “not validated”, “not valid”, “validation failed” or “failed”. The classifier may be associated with each data point which could not be validated upon application of the one or more rule(s). Each data point which could not be validated may be associated with a respective component identifier. Each data point which could not be validated may be associated with rule data indicating the rule that resulted in non-validation of the respective data point. The rule data may include the rule. The rule data may include the executable logic generated from the rule, for example as described in the context of FIG. 13B. Incident data generator 1344 may be configured to gather data point(s) associated with the classifier per component identifier. Incident data generator 1344 may query the database for component data associated with the classifier. Incident data generator 1344 may assemble gathered component data into incident data based on the component identifier associated with the gathered component data. Incident data generator 1344 may provide the generated incident data to data transfer service 1302. Data transfer service 1302 may be configured to determine the provider node having provided the non-validated incident data. Data transfer service 1302 may be configured to initiate a transfer of the incident data to the determined node associated with asset generator system 606 generating the non-validated component data set via consumer node 122. The incident data may be provided to the node, such as provider node 118, using an endpoint of such node configured to receive data from other nodes of the decentral network. The endpoint may be provided by such node to data transfer service 1302 or a backend connected to data transfer service 1302. The endpoint may be stored in a ledger interrelating consumer node(s) with respective endpoints used for pushing incident data to such consumer nodes. The consumer node(s) may be identified by decentral participant identifier(s). Generation and provision of incident data associated with non-validated data point(s) may allow the data provider providing such non-validated data point(s) to generated updated component data, for example as described in the context of FIG. 11 and to provide the updated component data set. Hence, the use of incident data may ensure that nonvalidated component data point(s) can be corrected by respective data providers such that the updated component data set(s) generated by the asset generator service 606 associated with node 118 pass(es) the validation. This may result in efficient and reliable generation of validated component data required to generate battery passports and hence also in reliable generation of battery passports. The battery passports may allow to improve and / or control production of battery containing products and / or recycling processes of battery containing products or batteries based on passport data contained in the battery passports.

[0275] FIG. 13B illustrates a diagram showing an example of validating component data associated with component(s) used to produce a battery using a rule-based engine. The component data may be gathered via a decentral network as described in the context of FIG. 8. The gathered component data may correspond to component data set(s) stored in a dedicated storage of a data provider environment, such as data provider environment 808 described in the context of FIG. 8.

[0276] Data validation unit 1320 may include rule based engine 1322. The rule based engine 1322 may operate on individual data point(s), multiple data point(s) and / or the gathered component I data. The rule based engine 1322 may operate on data gathered per component identifier individually. This allows to validate component data per component, hence allowing a more granular validation of the component data. Rule based engine 628 may receive a request to validate gathered component data. The request may contain at least a part of the gathered component data. Data packages (e.g. messages or events) may be consumed from one or more log(s) of stream storage system 1312 (see operation 1338) by data consuming unit 1308 as described in the context of FIG. 13A. The consumed data packages may be extracted by data consuming unit 1308 (see operation 1346). The extracted component identifier may be provided to rule based engine 1322. The rule based engine 1322 may have access to one or more rule(s). The rule based engine 1322 may include one or more rule(s). The one or more rule(s) may be present within a rule template. The one or more rule(s) and / or the rule template(s) may be stored in a data storage, such as rule DB 1318. The one or more rule(s) or rule template(s) may be provided to rule DB 1318 by a user. The one or more rule(s) may correspond to unstructured data associated with validation operation(s). The rule template(s) may include unstructured data associated with instructions related to validation operation(s). The one or more rule(s) or the rule template may be included in a file provided by the user. The one or more rule(s) or the rule template(s) may be associated with component type identifier(s) and / or component identifier(s). Rule based engine 1322 may generate a request to obtain one or more rule(s) from rule DB 1318. The request may contain the respective component identifier(s).

[0277] One or more rule(s) associated with the component data to be validated (e.g. one or more applicable rule(s)) may be provided to rule based engine 1322 in response to the request. The one or more rule(s) may define data point(s) and / or combination(s) of data point(s) to be present within the consumed component data, e.g. to be present within a consumed component data set. The one or more rule(s) may be associated with batteries produced from the component associated with the component data to be validated. The one or more rule(s) may be associated with or derived from or generated based on a data model of the battery or battery type. Hence, the one or more rule(s) may ensure that data point(s) associated with component(s) and being required according to the data model may be included in the consumed component data. The one or more rule(s) may be defined by the mandatory component data point(s) present within the data model. The one or more rule(s) may be generated based on the mandatory component data point(s) present within or defined by the data model. This may ensure that component data required by the data model is included in the consumed component data. The one or more rule(s) may define one for more component property data point(s), component identifier data point(s), component name data point(s), component producer data point(s), component declaration data point(s), component safety data point(s), component emission data point(s), component recyclate content data point(s), component biobased content data point(s), component biodegradability data point(s), component production data point(s), component certificate of analysis data point(s), component certificate data point(s), component life cycle data point(s), component storage instruction data point(s), component assembly instruction data point(s) and / or component operating condition data point(s). The rule may define data point(s) per data category. The rule may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. The one or more rule(s) may be associated with component identifier(s) and / or component type identifier(s). A mapping table may be used to map component identifier(s) to corresponding component type identifier(s). The component type identifier(s) may be associated with component type(s). The mapping table may be stored in a separate database (not shown). Rule based engine 1322 may be configured to gather component type identifier(s) based on determined component identifiers) and to request rule(s) based on the gathered component type identifier(s). This may allow to gather rule(s) associated with component type identifier(s) based on component identifier(s), hence avoiding generation of rule(s) per component identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1318.

[0278] Rule based engine 1322 may be configured to initialize the rule engine (see operation 1326). Initialization of the rule engine may include generating rule data executable by a processor included in rule based engine 1322. The rule data may include or correspond to executable logic. This may allow to transform rule(s) or rule template(s) present in unstructured data form into code that can be executed by the processor. Execution of the code may result in applying the executable rule data to the extracted component data (see operation 1328) to validate the consumed component data according to the obtained rule(s). Execution of the logic may result in matching consumed component data to data point(s) and / or combination(s) of data point(s) included in the executable logic, evaluating the data point(s) or combination(s) of data point(s) with matched component data and generating validation result data based on the evaluation results. The validation result data may include a classifier and associated validated or non-validated component data point(s). The classifier may be a binary classifier discriminating validated and non-validated i component data. Consumed component data point(s) may be considered validated if one or more rule(s) applied by rule based engine 1322 are fulfilled. Applying the rule(s) to the consumed component data may include comparing individual data point(s) present within the rule(s) to individual data point(s) present within the component data to be validated to determine whether the component data to be validated includes individual data point(s) required by such rule(s). Applying the rule(s) to the consumed component data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the component data to be validated to determine whether the component data contains data point combinations required by such rule(s). Applying the rule(s) to the consumed component data may include comparing the data defined in the rule(s) to the whole component data set to be validated to determine whether the component data set contains all data required by such rule(s). Operations performed by rule based engine 1322 may be determined by rule(s) gathered from rule DB 1318. For instance, rule(s) gathered from rule DB 1318 may determine whether rule based engine 1322 operates on individual data point(s) and / or multiple data point(s) of the consumed component data and / or the whole component data.

[0279] Rule based engine 1322 may be configured to determine whether the consumed component data fulfills one or more applied rule(s) (see operation 1330). Consumed component data may not be validated or only partially validated (e.g. validation may result in at least one error associated with applying one or more obtained rule(s) to the consumed component data) if the consumed component does not include data point(s) required according to one or more obtained rule(s). Rule based engine 1322 may indicate to data validation unit 1320 successful validation of the consumed component data responsive to the determination that the consumed component data is successfully validated (e.g. fulfils one or more obtained rule(s)). In response to receiving that indication, data validation unit 1320 may determine the target data storage where the validated component data is to be persisted (see operation 1340). The target data storage may be determined as described in the context of FIG. 13A. If data validation unit 1320 determines that the validated component data is not associated with a given application, data validation unit 1320 may provide the validated component data to a storage not being associated with any application processing the validated component data, such as storage general 806. If data validation unit 1320 determines that the validated component data is associated with a given application, data validation unit 1320 may provide the validated component data to a storage being associated with such application processing the validated component data stored therein, for example by generating battery passports.

[0280] If at least a part of the consumed component data could not be validated, rule based engine 1322 may indicate to data validation unit 1320 that at least a part of the consumed component data could not be validated. In response to receiving the indication, data validation unit 1320 may generate message data (operation 1332). The message data may indicate that at least part of the consumed component data could not be validated. The message data may include an indication which data point(s) of the consumed component data could not be validated. The message data may be provided to a display device configured to display data received from data validation unit 1320. The display device may comprise a graphical user interface 1334. The display device may display the message in response to receiving message data from rule based engine 1322. This allows to trigger correction or updating of non-validated data points, for example by generating incident data as described in the context of FIG. 13A.

[0281] Rule based engine 1322 may be configured to provide non-validated component data to a storage not being associated with any application processing the validated component data, such as storage general 806. The non-validated component data may be provided to such storage along with a classifier classifying such component data as non-validated. The non-validated component may be provided to such storage along with the classifier and rule data indicating the applied rule(s) resulting in nonvalidation of at least a part of the component data.

[0282] FIG. 14 illustrates a flow chart of an example method for validating component data associated with component(s) used to produce a battery. The method illustrated in FIG. 14 may be implemented by the system illustrated in FIG. 13A and FIG. 13B. The component(s) may be used as production input(s) in one or more process step(s) associated with the production of the battery. The process step(s) may be performed by one or more entities.

[0283] Battery data including battery identifier(s) and component identifier(s) associated with component(s) used to produce the battery may be provided (see block 1402). The identifier(s) associated with the component(s) may be asset identifiers associated with or included in the component data. The battery data may be provided from one or more database(s) storing such battery data. The one or more database(s) may be associated with the production producing the battery or the production producing a battery containing product. The battery data may be provided by an entity producing the battery to the entity performing the method illustrated in FIG. 14. The battery data may further include battery property data. The battery property data may include at least one measured chemical and / or physical property of the battery and / or at least one chemical and / or physical property determined from collected data associated with the production of the battery. At least a part of the battery data may be stored in one or more databases. The one or more database(s) may be determined based on mapping data. The mapping data may map battery identifier(s) to applications and associated databases. The mapping data may map battery identifier(s) to battery type identifier(s) and associated applications and databases.

[0284] Component data may be gathered via a decentral network based on the component identifier(s) included in the provided battery data (see block 1404). The decentral network may be decentral network 134, 208 described in the context of FIG. 1 and FIG. 2. The component data may be gathered by a decentral data consuming node, such as consumer node 122, from decentral data providing node(s), such as provider node 118, associated with the respective component data as described in the context of FIG. 8. With reference to FIG. 15, gathering component data may include determining decentral data providing node(s) associated with the component data matching the component identifier(s) (e.g. component data associated with the provided component identifier(s)). Determining such provider node(s) may include providing candidate decentral provider nodes associated with component data of component(s) used to produce the battery. The candidate provider node(s) may be provided by providing a database storing candidate provider node data associated with component identifier(s) matching component identifier(s) of component data set(s) associated with such candidate provider node(s) (e.g. accessible via said candidate provider node(s)). The candidate provider node data may include access data associated with the candidate provider node(s). The candidate provider node data may further include candidate provider node identifier(s) and / or decentral participant identifier(s) associated with the candidate provider node(s). The database may include mapping data mapping candidate provider node data to component identifier(s) associated with component data provided by candidate provider nodes associated with the candidate provider node data. The database may be updated upon receiving new candidate provider data and associated component identifier(s). Use of such mapping data allows to efficiently determine target provider node(s) associated with the required component data, hence resulting in a reduced latency associated with the gathering of the component data. This may ensure, that the component data may be validated and the validated component data may be processed, for example by generating battery passports, prior to providing the battery associated with the battery passport or a product including the battery associated with the battery passport to a consumer, such as an end product user. Efficient generation of battery passports may avoid storage of produced batteries or battery containing product(s) prior to providing them to consumers due to the absence of associated battery passports which may need to be generated from a regulatory standpoint prior to providing the associated battery or battery containing product to a consumer. With continued reference to FIG. 15, access data for target decentral provider nodes associated with the component data may be determined based on the provided component identifier(s). Target provider nodes may be identified by matching the provided component identifier(s) to component identifier(s) stored in the mapping data. The candidate provider node data associated with matching component identifier(s) may be gathered from such database as target provider node data. The gathered target provider node data may be parsed to determine access data associated with target decentral provider node(s) (e.g. provider node(s) associated with dedicated storage(s) storing component data associated with provided component identifier(s)).

[0285] With continued reference to FIG. 15, access to component data associated with the provided component identifier(s) may be requested from target data provider node(s) associated with the determined access data. Access to component data may be requested as described in the context of FIG. 13A. The component data may be provided by the target provider node(s) in response to such a request, for example as described in the context of FIG. 8.

[0286] Returning to FIG. 14 and with reference to FIG. 13A and FIG. 16, the gathered component data may be provided to a stream storage system, such as stream storage system 1312 described in the context of FIG. 13A. A data consumer, such as data consuming unit 1308 described in the context of FIG. 13A may consume the gathered component data from the stream storage system. The consumer may extract component identifier(s) and component data from the consumed data package(s). The stream storage system may hence serve as a component data sink and allows to compensate the asynchronous gathering of the component data from the decentral network. Gathered component data set(s) may be provided as messages or events to stream storage system. Stream storage system may publish such received message(s) or event(s), e.g. may persist the received message(s) or event(s) in a persistent or non-persistent log, for example as described in the context of FIG. 13A. The messages or events may be generated by data transfer service 1302, for example as described in the context of FIG. 13A. The data consumer may listen to published messages and / or events (see FIG. 13A) and may consume new messages and / or events. This may ensure that validation may be performed per component data set and avoids validating a given component data set multiple times.

[0287] With continued reference to FIG. 13A and FIG. 16 and with further reference to FIG. 13B, at least a part of the gathered component data may be validated by using a rule-based engine including one or more rule(s) associated with the battery. The component data may be validated by data validation unit 1310. The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to a component identifier included in the extracted component data. The identifier associated with each applicable rule may include a component identifier matching the component identifier included in the extracted component data. The identifier associated with each applicable rule may include a component type identifier related to the component identifier included in the extracted component data. The component type identifier related to the component identifier included in the extracted component data may be determined based on mapping data as described in the context of FIG. 13B.

[0288] With continued reference to FIG. 13B and FIG. 16, executable logic may be generated from the one or more applicable rule(s). The executable logic may be generated by data validation unit 1310. Executable logic may include machine code, interpretable code, bytecode, and / or code that runs on a virtual machine. The logic included in the applicable rule(s) may be encoded in the executable logic. The logic included in the applicable rule(s) may be mirrored in the executable logic. Upon finalizing the generation of the executable logic, data validation unit 1310 may sent a response to data consuming unit 1308 indicating finalizing the generation of the executable logic.

[0289] With continued reference to FIG. 13B and FIG. 16, extracted component data may be provided to data validation unit 1310 by data consuming unit 1308 in response to receiving an indication that the generation of the executable logic has been finalized. The extracted component data may be validated by executing the generated executable logic. The executable logic may be subject to rule execution criteria. Data consuming unit 1308 may sent a request to data validation unit 1310 to transform the extracted component based on the executable logic generated for the applicable rule(s). Rule execution criteria may include rule execution order, exemptions and conditions. Validation data including the result of the validation may be generated by the rule engine. The validation data may include the component data points subject to the validation process and associated classifiers. The classifiers may indicate whether the respective component data point passed or failed the validation process. The validation data may further include rule data associated with data point(s) for which validation failed. The rule data may indicate the applied rule(s) which resulted in a fail of the validation of such data point.

[0290] Returning to FIG. 14 and with continued reference to FIG. 16, it may be verified whether the extracted component data could be validated according to one or more applicable rule(s) (e.g. one or more rule(s) gathered from rule DB 1318 based on the gathered component data (see block 1408). Validation may be performed as described in the context of FIG. 13B. If the extracted component data could be validated according to the applicable rule(s), e.g. application of such rule(s) did not result in any error, the method may proceed to block 1418. If only a part of the extracted component data could be validated, the method may proceed to block 1414. If the extracted component data could not be validated, the method may proceed to block 1410.

[0291] In block 1410, message data may be generated, for example as described in the context of FIG. 13B. The validation data including the non-validated component data may be provided to a storage location, for example as described in the context of FIG. 13B. The validation data including the non-validated component data may be used to generate incident data, for example das described in the context of FIG. 13A and FIG. 17. In block 1414, message data may be generated, for example as described in the context of FIG. 13B. In block 1416, validation data including the non-validated component data may be provided to a storage location as previously described.

[0292] Validated component data may be linked to at least one of the battery identifiers (see block 1418). This may allow to gather the validated component data based on at least one of the battery identifiers, for example upon generating the battery passports.

[0293] With continued reference to FIG. 13A and FIG. 13B, storage location(s) for at least a part of the validated component data may be determined based on component identifier(s) associated with the validated component data (see block 1420). The component identifier(s) may be included in the validated component data. The storage location(s) may be determined as described in the context of FIG. 13A and FIG. 13B. Providing the validated component data to a database used by a defined application to process the validated component data may allow to sort the validated component data according to applications processing or consuming the validated component data. This may improve security since unauthorized data access by applications not processing the validated component data stored in such database is avoided. Moreover, this may reduce latency to generate battery passports since the amount of data stored within a particular database is reduced by selectively providing validated component data to be processed by a given application to database(s) associated with such application.

[0294] With continued reference to FIG. 16, at least a part of the validated component data linked to at least one of the battery identifiers may be provided to determined storage location(s) for generating battery passport(s) associated with the battery including at least a part of the validated component data (see block 1422). The validated component data provided to such storage location(s) may be persisted in such storage location(s).

[0295] By gathering component data directly from respective data provider nodes associated with such component data, e.g. by avoiding a query to the decentral network to locate the data provider node(s) associated with the desired component data, the component data may be gathered via the decentral network reliably and quickly. By validating the gathered component data by a rule-based engine including one or more rule(s) associated with the battery or battery type, such as rule(s) associated with a data model of the battery or battery type, battery passports may be reliably generated from such validated component data since validation allows to ensure that all component data points required according to the semantic model used to generate the battery passport are available (e.g. are stored within a dedicated storage). By validating the gathered component data at the consumer side, the component data can be directly gathered from the provider side without requiring the provider side to provide component data adhering to a defined data structure. Hence, the provider side may not be required to generate the component data gathered by the consumer side by using complex data models resulting in highly defined component data points. Instead, component data may be provided as a tabular representation to the consumer side and such component data may be validated on data point level to ensure that the gathered component data includes all data point(s) mandatory with respect to a data model used to generate battery passports from the validated component data. By validating the component data on consumer side, the effort to generate and provide component data at the provider side is greatly reduced while maintaining security, hence resulting in reliable, quick and secure sharing of component data required to generate battery passports. This in turn may allow to generate battery passports associated with batteries produced from such component in a reliable and efficient way, ensuring a high data quality of the battery passport as well as that such battery passports are available upon providing the battery or battery containing product to a consumer without having to store the battery or battery containing product until generation of the associated battery passport is completed. The high data quality of the battery passport may allow consumers of the associated battery to control and / or monitor production processes using the battery and / or recycling processes involving battery containing end-products and / or the battery, in a more reliable and / or efficient way. In addition, this setup allows to gather component data for various component(s) from various data provider nodes simultaneously while ensuring that gathered component data is correctly validated and persisted to a database associated with an application consuming the validated component data persisted in such database.

[0296] FIG. 17 illustrates a flow chart of a further example method for validating component data associated with component(s) used to produce a battery. The method illustrated in FIG. 17 may be implemented by the system illustrated in FIG. 13A and FIG. 13B. The component(s) may be used as production input(s) in one or more process step(s) associated with the production of the battery. The process step(s) may be performed by one or more entities.

[0297] Incident data including non-validated component data and data associated with rule(s) or a rule template resulting in the non-validation of such component data may be generated (see block 1702). The incident data may be generated by incident data generator 1344, for example as described in the context of FIG. 13A.

[0298] The generated incident data may be provided via a decentral network to the decentral data provider associated with the non-validated component data. The decentral data provider may be determined based on the component identifier included in the generated incident data as described in the context of FIG. 15 using mapping data including candidate provider node data and associated component identifier. For instance, the component identifier included in the incident data may be matched to component identifier(s) included in the mapping data to determine associate provider node data. The associated provider node data may be parsed to determine the access data associated with such provider node. The access data may be used to provide the incident data to the provider node associated with the access data.

[0299] In response to receiving the incident data, a backend system associated with the provider node receiving the incident data, such as asset generation system 646, may generate updated component data set, for example as described in the context of FIG. 11. The updated component data may be provided to the consumer node providing the incident data used to generate the updated component data. The updated component data may be provided to the consumer node by pushing such data to the consumer node without receiving a request for such data, for example as described in the context of FIG. 13A. This may allow to provide the updated component data after generation of such component data, hence reducing a delay in transfer of the updated component data to the consumer node and facilitating timely validation of the updated component data and generation of the battery passport using the updated and successfully validated component data. This may avoid that battery passports may not be generated due to lack of validated component data and may ensure that battery or battery providing product provided to the consumer, such as an end product user or recycler, is associated with a battery passport allowing the consumer to gather passport data included in the battery passport and to use the passport data to control and / or optimize further production processes using the battery and / or recycling processes of battery containing end-products and / or the battery.

[0300] The updated component data may be validated, for example as described in the context of FIG. 14.

[0301] The present disclosure has been described in conjunction with preferred embodiments and examples as well. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the claims.

[0302] Any steps presented herein can be performed in any order. The methods disclosed herein are not limited to a specific order of these steps. It is also not required that the different steps are performed at a certain place or in a certain computing node of a distributed system, i.e. each of the steps may be performed at different computing nodes using different equipment / data processing.

[0303] As used herein ..determining" also includes ..initiating or causing to determine", “generating" also includes ..initiating and / or causing to generate" and “providing” also includes “initiating or causing to determine, generate, select, send and / or receive”. “Initiating or causing to perform an action” includes any processing signal that triggers a computing node or device to perform the respective action.

[0304] In the claims as well as in the description the word “comprising” or “including” or similar wording does not exclude other elements or steps and shall not be construed limiting to the elements or steps lined out. The indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation or further elements may be included.

[0305] Providing in the scope of this disclosure may include any interface configured to provide data. This may include an application programming interface, a human-machine interface such as a display and / or a software module interface. Providing may include communication of data or submission of data to the interface, in particular display to a user or use of the data by the receiving entity.

Claims

1. A method for generating a component data set associated with a battery component, wherein the battery component is used as input material to produce at least one battery, the method comprising: providing data associated with the battery component including at least one component identifier; gathering - based on the provided data associated with the battery component - component data from one or more databases; generating the component data set by transforming the gathered component data using a rule-based engine including one or more rule(s) associated with at least one of the batteries; providing the generated component data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated component data set.

2. The method of claim 1 , wherein the gathered component data includes component identifier data, property data associated with the component, component name data, component producer data, component declaration data, component safety data, emission data associated with the component, recyclate content data associated with the component, biobased content data associated with the component, biodegradability data associated with the component, production data associated with the component, certificate of analysis data associated with the component, certificate data associated with the component, life cycle data associated with the component, storage instruction data associated with the component, assembly instructions associated with the component, operating conditions associated with the component or a combination thereof.

3. The method of claim 1 or 2, wherein the rule-based engine operates on individual data points present within at least part of the gathered component data, multiple data points present within at least part of the gathered component data or the whole gathered component data.

4. The method of any one of the preceding claims, wherein the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to transformation operation(s).

5. The method of any one of the preceding claims, wherein the one or more rule(s) are associated with or are derived from a semantic model associated with at least one of the batteries, in particular wherein the one or more rule(s) are defined by one or more mandatory component data point(s) present within the semantic model.

6. The method of any one of the preceding claims, wherein the one or more rule(s) define aggregation rule(s) for aggregating component data gathered from multiple data sources into a given data structure, define filters to filter gathered component data, define attribute construction(s) to createor add new attributes to the gathered component data and / or include a trigger condition and a corresponding group of one more actions.

7. A method for generating a component data set associated with a battery component, wherein the battery component is used as input material to produce at least one battery, the method comprising: providing battery data including battery identifier(s) and component identifier(s) associated with the battery component(s); obtaining the component data from decentral data providing node(s) associated with component data, wherein the component is gathered by a decentral data consuming node based on the provided component identifier(s); validating at least a part of the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries; linking the validated component data to at least one of the battery identifiers; determining storage location(s) for the validated component data based on component identifier(s) associated with the validated component data; providing the validated component data linked to at least one of the battery identifiers to the determined storage location(s) for generating battery passport(s) associated with at least one of the batteries including at least a part of the validated component data.

8. The method of claim 7, wherein the decentral data providing node(s) are determined from mapping data mapping decentral data providing node data to associated component identifier(s) by matching component identifier(s) included in the battery data to component identifier(s) included in the mapping data.

9. The method of claim 7 and 8, wherein the obtained component data is provided to one or more input node(s) configured to gather the obtained component data and to provide the gathered component data as component data set(s) to one or more downstream node(s), wherein the one or more downstream node(s) are configured to validate at least a part of the data included in the component data set(s) provided by the one or more input node(s), link the validated component data to at least one battery identifiers associated with at least one of the batteries, determine storage location(s) for the validated component data and to provide the validated component data linked to the battery identifier(s) to the determined storage location(s),10. The method of any one of claims 7 to 9, wherein the rule-based engine operates on individual data points present within at least part of the component data, multiple data points present within at least part of the component data or the whole component data.

11. The method of any one of claims 7 to 10, wherein the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to validation operation(s).

12. The method of any one of claims 7 to 11 , wherein the one or more rule(s) define data point(s) and / or combination(s) of data point(s) to be present within component data.

13. The method of any one of claims 7 to 12, wherein the storage location is determined based on mapping data including a mapping between component identifier(s) and associated storage location data or a mapping between component identifier(s) and associated component type identifier(s) and storage location data.

14. An apparatus for validating component data associated with battery component(s), wherein the battery component(s) are used to produce at least one battery by a production, the apparatus comprising: a battery product data providing interface configured to provide battery data including battery identifier(s) and component identifier(s) associated with the battery component(s); a decentral network interface configured to obtain the component data from decentral data providing node(s) associated with the component data, wherein the component data is gathered by a decentral data consuming node based on the provided component identifier(s); a data validator configured to validate at least a part of the gathered component data by using a rule-based engine including one or more rule(s) associated with at least one of the batteries; a linking unit configured to link the validated component data to at least one of the battery identifiers; a storage determinator configured to determine storage location(s) for the validated component data based on component identifier(s) associated with the validated component data; a validated data providing interface configured to provide the validated component data linked to the battery identifier(s) to the determined storage location(s) for generating battery passport(s) associated with at least one of the batteries including at least a part of the validated component data.

15. Use of the validated component data associated battery component(s) as generated by the methods claimed in any one of claims 7 to 13 or by the apparatus of claim 14 for generating battery passports associated with batteries produced at least in part from the battery component(s).

Images