Generation and processing of data associated with materials 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 an output product data set associated with an output product. The disclosure further relates to methods, apparatuses, systems, and computer elements for validating input material data associated with input material(s). The disclosure further relates to the use of validated input material data associated with input material(s) as generated herein to generate product passports associated with products produced at least in part from such input material(s).

Description

[0001] GENERATION AND PROCESSING OF DATA ASSOCIATED WITH MATERIALS 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 an output product data set associated with an output product. The disclosure further relates to methods, apparatuses, systems, and computer elements for validating input material data associated with input material(s). The disclosure further relates to the use of validated input material data associated with input material(s) as generated herein to generate product passports associated with products produced at least in part from such input material(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 an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the method comprising:

[0008] • providing data associated with the output product including at least one output product identifier;

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

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

[0011] • providing the generated output product 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 output product data set. In a further aspect disclosed is an apparatus for generating an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the apparatus comprising:

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

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

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

[0015] • a decentral network interface configured to provide the generated output product 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 output product data set.

[0016] In yet a further aspect disclosed is a system for generating an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the system comprising:

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

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

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

[0020] • a connector layer to a decentral network configured to provide the generated output product 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 output product data set.

[0021] In yet a further aspect disclosed is a method, in particular a computer-implemented method, for generating an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the method comprising:

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

[0023] • gathering - based on the received incident data - output product data associated with the output product;

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

[0025] • generating an updated output product data set by transforming the gathered output product data by using a rule-based engine including one or more rule(s) associated with at least one of the product(s), wherein at least one of the rule(s) is an updated rule; • providing the generated updated output product 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 output product data set.

[0026] In yet a further aspect disclosed is an apparatus for generating an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the apparatus comprising:

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

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

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

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

[0031] • a decentral network interface configured to provide the generated updated output product 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 output product data set.

[0032] In yet a further aspect disclosed is a system for generating an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the system comprising:

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

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

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

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

[0037] • a data transformer layer configured to generate an updated output product data set by transforming the gathered output product data by using a rule-based engine including one or more rule(s) associated with at least one of the product(s), 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 output product 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 output product data set. In yet a further aspect disclosed is a method, in particular a computer-implemented method, for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the method comprising:

[0039] • providing product data including product identifier(s) and input material identifier(s) associated with the input material(s);

[0040] • obtaining the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on the provided input material identifier(s), in particular wherein the input material 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 input material data by using a rule-based engine including one or more rule(s) associated with at least one of the products;

[0042] • linking the validated input material data to at least one of the product identifiers;

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

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

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

[0046] • providing product data including product identifier(s) and input material identifier(s) associated with the input material(s);

[0047] • obtaining the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on the provided input material identifier(s), in particular wherein the input material 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 input material data by using a rule-based engine including one or more rule(s) associated with at least one of the products;

[0049] • linking the validated input material data to at least one of the product identifiers;

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

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

[0052] • a decentral network interface configured to obtain the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on the provided input material identifier(s);

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

[0054] • a linking unit configured to link the validated input material data to at least one of the product identifiers;

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

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

[0057] In yet a further aspect disclosed is an apparatus for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the apparatus comprising:

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

[0059] • a decentral network interface configured to obtain the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on the provided input material identifier(s);

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

[0061] • a linking unit configured to link the validated input material data to at least one of the product identifiers;

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

[0063] In yet a further aspect disclosed is a system for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the system comprising:

[0064] • a connector layer to a decentral network configured to obtain the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on input material identifier(s) associated with the input material(s); • a service layer including one or more input node(s) configured to gather the input material data provided by the connector layer and to provide the gathered input material data as input material 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 input material 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 products, o link the validated input material data to at least one of the product identifiers, o determine storage location(s) for the validated input material data based on input material identifier(s) associated with the validated input material data, o provide the validated input material data linked to the product identifier(s) to the determined storage location(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material data,

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

[0067] In yet a further aspect disclosed is a system for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the system comprising:

[0068] • a connector layer to a decentral network configured to obtain the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on input material identifier(s) associated with the input material(s);

[0069] • a service layer including one or more input node(s) configured to gather the input material data provided by the connector layer and to provide the gathered input material data as input material 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 input material 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 products, o link the validated input material data to at least one of the product identifiers, o provide the validated input material data linked to the product identifier(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material data,

[0071] • a storage layer comprising one or more databases and configured to store the provided validated input material data. In yet a further aspect disclosed is a method in particular a computer-implemented method, for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the method comprising:

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

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

[0074] • receiving updated input material data from the decentral data providing node(s) via the decentral network;

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

[0076] • linking the validated input material data to at least one associated product identifier;

[0077] • determining storage location(s) for the validated input material data based on input material identifier(s) associated with the validated input material data;

[0078] • providing the validated input material data linked to the product identifier(s) to the determined storage location(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material data.

[0079] In yet a further aspect disclosed is an apparatus for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the apparatus comprising:

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

[0081] • 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 input material data,

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

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

[0084] • a linking unit configured to link the validated input material data to at least one associated product identifier;

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

[0086] • a data providing interface configured to provide the validated input material data linked to the product identifier(s) to the determined storage location(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material data. In yet a further aspect disclosed is a system for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the system comprising:

[0087] • 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 input material data, o receive updated input material data from the decentral data providing node(s) via the decentral network;

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

[0089] • a data validation layer comprising the one or more downstream node(s) and configured to o generate the incident data including non-validated input material data and data associated with rule(s) or a rule template resulting in the non-validation of such input material data, o validate at least a part of the updated input material 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 products, o link the validated input material data to at least one associated product identifier, o determine storage location(s) for the validated input material data based on input material identifier(s) associated with the validated input material data, o provide the validated input material data linked to the product identifier(s) to the determined storage location(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material data,

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

[0091] In yet a further aspect disclosed is a use of the validated input material data associated with input material(s) as generated by the methods disclosed herein or by the apparatuses disclosed herein or by the systems disclosed herein for generating product passports associated with products produced at least in part from the input material(s).

[0092] 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. 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.

[0094] Embodiments

[0095] 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.

[0096] To enable or improve the exchange of output product data associated with output product(s) used as input material to produce one or more product(s), simple and efficient generation of such output product data is crucial. However, sharing of output product 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 semantic models makes the generation of output product data set(s) a complicated and tedious effort. Such effort may not be feasible for small supplier companies, hence posing a hurdle for sharing output product data associated with output products produced by such companies within the decentral network.

[0097] By using a rule-based engine including rule(s) associated with a product produced from such output product(s) as input material(s), in particular associated with data model(s) of the product or a product type the product is associated with, it can be ensured that output product data point(s) required according to the data model, such as an aspect model, associated with products produced from such output products or product types are contained in the output product data set, hence avoiding missing data point(s) during generation of a product passport associated with the product using said semantic model. Since the rule(s) are derived from the data model of the product, suppliers producing input material(s) used in the production of such product are do not necessarily have to use complex data models to generate the output product data set(s). Instead, existing data models for such products may be used to generate rule(s) used during creation of output product data set(s), hence avoiding costly and cumbersome generation of such models for the produced output products.

[0098] By transforming the gathered output product data using such rule-based engine, aggregation of the gathered output product 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 output product data set(s) by output product producers within the product ecosystem. The output product 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 output product data set(s), such as the tabular representation, may be stored within a dedicated storage associated with the data owner of the data set(s) for consumption of such data set(s) by a decentral data consuming node associated with a data consumer under the control of the data owner, such as the output product producer. Hence, the output product data sets can be directly consumed based on identifier(s) associated with such data set(s) 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 output product 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 output product data set(s) based on given rule template(s) and rule(s), resulting in a further simplification of the generation of the output product data set(s).

[0100] By enabling simple generation of output product data set(s), such output product data set(s) can be reliably shared within a decentral network by supply chain participants who are not familiar with semantic data 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 output product data, for instance based on output product composition data included in the shared output product data sets. By using a decentral network, the generated output product data set(s) may be shared in a secure and yet 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 output products 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 output product data set include(s) all output product data point(s) required by the data model associated with the product or a product type (e.g. product class) the product is associated with. This ensures that product passports associated with such products can be reliably generated from data gathered via the decentral network, without a risk that required data point(s) are missing, hence resulting in the product passport having a low data quality. Since it may be required that products sold to customers are associated with such product passports, lack of generation of such passports due to missing output product data may result in increased storage times of products and may negatively influence downstream participants of the supply chain due to lack of product supply. In addition, low data quality of the product passports may negatively influence the processing of the product and / or the production of further products using the product based on the data included in the product passports.

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

[0103] By generating incident data during generation of the output product 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 output product data may be generated and provided to the consumer side. This allows to ensure that the generated output product 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 output product data (e.g. input material data) at the consumer side, data providers may be enabled to generate updated output product 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 output product data ensures that output product 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 product 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.”

[0105] 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.

[0106] The method for generating the output product data set may be executed by one or more computing node(s) associated with an output product production producing the output product. The method for generating the output product data set may be executed by one or more computing node(s) associated with an output product producer. The output product producer may operate the output product production. The method for validating the input material data may be executed by one or more computing node(s) associated with a production producing the product. The method for validating the input material data may be executed by one or more computing node(s) associated with a product producer. The product producer may operate the production.

[0107] Input material may refer to any good which is bought from suppliers and brought to the respective production plant. The input material may include starting material used in the production process of the production plant to produce the product. An input material can be used in any production step used to produce the product. This means, the product of the one production plant can be the input material of the other production plant. Likewise, the output product of one supply chain participant may be used as input material to produce a further output product by a downstream participant. Input material may include recycled material. The input material may comprise or be any input material entering a production. The input material may comprise or be any input material provided at any entry point of the production. The input material may be any material produced by upstream production stages with respect to the output product production stage.

[0108] Output product may include any product produced from one or more input materials. The output product may be produced via one or more process steps. The process steps may involve chemical reactions and / or physical processes and / or assembly processes. The input material may be used in one or more of such production step(s). The output product may comprise or be any product produced by a production and provided at any exit point of the production. The output product may be used as input material to produce one or more product(s). The product(s) may be produced by one or more downstream participants which may use the output product(s) produced by one or more upstream participants as input material(s). The output product may be associated with an output product identifier. The output product identifier may be a digital or virtual output product identifier. The output product identifier may uniquely identify the output product within the entity producing the output product. The output product identifier may uniquely identify the output product within the decentral network. The output product identifier may be associated with an identifier element physically connected to the output product. The identifier element may encode the digital output product identifier. The output product identifier may include an output product name, an output product number, a LOT number, a batch number, a serial number, etc..

[0109] The output product / input material and the product may be part of a product ecosystem. The product ecosystem may include chemical products. The product ecosystem may include production chains to produce a product. The product may be a chemical product, an intermediate chemical product, a component, a component assembly or an end-product. The product ecosystem may include processing chains to process used products resulting from the use of produced products. Processing chains may include recycling chains to recycle at least part of the used product or a component thereof. Processing chains may include re-use chains to re-use the used product. The product ecosystem may include various participants, such as raw input material producers, chemical product producers, chemical product users, end-product producers, end-product users, EOL product collectors and recyclers. The product ecosystem may allow to use of recycled materials resulting from recycling of end-of-life end products to produce new products, such as chemical products. The product ecosystem may be associated with the production and / or re-use and / or recycling of physical products.

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

[0111] The participants of the product 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 product 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.

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

[0113] The decentral data consuming network node may comprise computer-executable instructions for accessing and / or processing data within a decentral network, such as input material 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 input material data (e.g. the entity generating the product passport). The consumer may be any entity processing the input material data. The consumer may be any entity operating a production configured to process the output products associated with the output product data as input material(s) Processing may include using the output products as input materials to produce further products. Processing may include performing one or more recycling step(s) on the output products as input material. The consumer may be an upstream participant of the output product producer in the product ecosystem.

[0114] A rule-based engine may be used to transform at least part of the gathered output product data associated with output product(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 output product 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 output product data may include one or more rule(s) associated with product(s) produced from the output product(s) (e.g. by using the output products as input materials). The one or more rule(s) may be associated with or derived from the data model of the product or the product type. Hence, the one or more rule(s) may ensure that data point(s) for such output products required according to the data model may be included in the generated output product data set. The one or more rule(s) may be defined by the mandatory output product data points present within the data model. The one or more rule(s) may be generated based on the mandatory output product data points present within or defined by the data model. This may ensure that output product data required by the data model is included in the generated output product data set. The one or more rule(s) may hence be generated or defined by the data model associated with the product produced from the output product(s) as input materials or the product type. The one or more rule(s) may hence not be derived or generated based on a data model associated with the produced output products. This may allow to avoid generation of complex data models for produced output products but may instead allow to use existing data models of product(s) or product type(s) for generation of rule(s) to transform gathered output product data to output product data set(s).

[0115] The rule-based engine may operate on individual data point level, combination of data points or the whole gathered output product 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 output product data. Use of such rule(s) allows to ensure that data point(s) required by the data model associated with the product are contained in the generated output product 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 the product or product type are contained within the generated output product data sets.

[0116] A rule-based engine may be used to validate at least part of the input material 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 input material data. The rule-based engine used to validate at least part of the gathered input material data may include one or more rule(s) associated with product(s). The one or more rule(s) may be associated with or derived from or generated based on the data of the product or product type. Hence, the one or more rule(s) may ensure that data point(s) for such input materials required according to the data model may be included in the gathered input material data. The one or more rule(s) may be defined by the mandatory input material data points present within the data model. The one or more rule(s) may be generated based on the mandatory input material data points present within or defined by the data model. This may ensure that input material data required by the data model is included in the gathered input material data, hence ensuring reliable and efficient generation of product passports using such validated input material data.

[0117] The rule-based engine may operate on individual data point level, combination of data points or the whole gathered input material 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 input material data. Use of such rule(s) allows to ensure that data point(s) required by the data model associated with the product are contained in the consumed input material 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 the product or product type are contained within the consumed input material data.

[0118] The product 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 input material data and product data associated with the respective product. The product passport may include a at least one decentral identifier and passport data. The passport data may include a product identifier, validated input material data and product data. The product passport may include one or more authentication mechanisms associated with the decentral identifier(s) and the passport data. The product passport may relate to one or more authorization mechanisms associated with the decentral identifier(s) and the passport data. The one or more authorization mechanisms may include authorization rules determining if access to the at least a part of the validated input material data and / or product data is granted. The product passport may be associated with one or more digital representations of the passport data or a part thereof. The digital representations may be regarded as access element(s) providing access to the product passport, e.g. the passport data, or parts thereof. The digital representation may include a decentral identifier and access data for accessing the passport data or the part 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 product 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 product passport. The decentral registry may be part of the decentral network but may not be associated with a particular participant of the product ecosystem, e.g. may be regarded as infrastructure node of the decentral network.

[0119] In an embodiment, the one or more databases are distributed databases, wherein at least one of the databases stores instance(s) of the output product 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 output product. 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 output product may be fragmented into a set of relations (tables of a relational database, distributed across multiple sites).

[0120] In an embodiment, the output product is a chemical intermediate product, a chemical product, a part, a component or a component assembly. The chemical intermediate product and / or the chemical product may be produced from virgin input material(s) and / or recycled input material(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, a mechanical subsystem or a battery pack housing.

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

[0122] Output product identifier data may include a batch number, a serial number, a LOT number or a combination thereof.

[0123] Property data may include at least one measured chemical and / or physical property of the produced output product and / or at least one chemical and / or physical property determined from collected data associated with the production of the output product. The data may be collected before, during and / or after production of the output product. The collected data may be used to determine at least one physical and / or chemical property of the produced output product. 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 output product 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 output product. 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 output product that is measurable. Hence, the value of a physical property describes a state of the output product. 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.

[0124] 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 output product.

[0125] Emission data may comprise any data related to environmental footprint. The environmental footprint may refer to the output product and its associated environmental footprint. The environmental footprint may be output product specific. For instance, the environmental footprint may relate to the output product or additional output product-specific relations. Emission data may include data relating to the carbon footprint of the output product or a Product Carbon Footprint (PCF). Emission data may include data relating to greenhouse gas emissions e.g. released in production of the output product. 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.

[0126] 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 product. 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 product 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 output product. Production data may include monitoring and / or control data associated with the production of the output product. Production data may be acquired prior to, during and / or after production of the output product.

[0127] In an embodiment, the rule-based engine operates on individual data points present within at least part of the gathered output product data, multiple data points present within at least part of the gathered output product data or the whole gathered output product data. The rule-based engine may be configured to transform gathered output product 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 output product 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 output product data set.

[0128] 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 output product data gathered from multiple data sources into a given data structure, filters to filter gathered output product data, attribute construction(s) to create or add new attributes to the gathered output product 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 product(s) produced by using the output product as input material or the product type. 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 output product data sets and to lower the entry barrier for input material suppliers to generate and provide output product data sets via a decentral network to allow data consumers access to such data for generation of product passports.

[0129] 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. data model, associated with at least one of the products, in particular wherein the one or more rule(s) are defined by one or more mandatory output product data point(s) present within the semantic model. The data model may be associated with a product type the product is associated with. This may allow to avoid the use of complex data models associated with output products and instead may allow to use existing data models of product(s) which are produced from such output products. This allows to significantly reduce the complexity of the generation of output product data sets for producers of such output product(s), hence ensuring reliable and efficient provision of such output product data set(s) within the decentral network for access by consuming entities for generation of product passports.

[0130] In an embodiment, the one or more rule(s) define aggregation rule(s) for aggregating output product data gathered from multiple data sources into a given data structure, define filters to filter gathered output product data, define attribute construction(s) to create or add new attributes to the gathered output product 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 output product 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 an output product identifier included in such tabular representation. Filters may define data point(s) to be included in the generated output product data set. For instance, a filter may define one for more output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product 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.

[0131] In an embodiment, transforming the gathered output product data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered output product 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 output product identifier included in the gathered output product data. The applicable rule(s) may be included in a rule template. Hence transforming the gathered output product 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 rulebased engine. The identifier associated with each applicable rule or rule template may correspond to a digital output product identifier included in the gathered output product 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 output product identifier(s) and optionally output product type identifier(s). In an embodiment, transforming the gathered output product data includes

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

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

[0134] 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 output product 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 product passports to reliably consume all required input material data via the decentral network, hence ensuring efficient and reliable generation of product passports using the gathered input material data. This way, the data quality of the product passports may be improved, allowing more reliable processing of the product and / or the production of further products using the product based on the data included the product passports.

[0135] In an embodiment, the output product data set is generated responsive to fulfilment of one or more rule(s) applied to the gathered output product data by the rule-based engine. This may ensure that generation of output product data set(s) is only performed if at least a part of 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 only output product 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 product passports. This may in turn have a negative influence on the provision of such products for example if certain data must be included in the product passport from a regulatory standpoint for products sold to downstream participants of the product ecosystem or end product users. The delayed provision of such products 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 product based on the data included in the product passport.

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

[0137] In an embodiment, the generated output product data set includes at least a part of the data included in the gathered output product data. The output product data set may further include a digital output product identifier, e.g. asset identifier, associated with the output product data set. For instance, the generated output product data set may include data point(s) defined by the one or more rule(s) used to generate the output product data set. Such rule(s) may define one or more data point(s) to be included in the generated output product data set(s).

[0138] In an embodiment, the generated output product data set includes output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product operating condition data point(s). For instance, the generated output product data set may include output product emission data point(s).

[0139] In an embodiment, the method further includes a step of generating group access data associated with the generated output product data set and optionally one or more authorization rule(s) defining access to and / or usage of the generated output product 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 output product 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 output product data sets are only shared with such data consumers that require such data, for example for the generation of product passports.

[0140] In an embodiment, the method further includes a step of generating a contract template including the digital output product identifier and the group access data identifier. The method may further include a step of linking the group access data to the digital output product 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 output product 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 output product data set. This may allow the decentral data consumer node to use such endpoint within the request for such output product data upon accepting the electronic contract. The electronic contract may include authorization rule(s) associated with the usage of the output product data set(s). This may avoid unauthorized use of the provided output product data by the data consumer, hence improving data security.

[0141] In an embodiment, the access to the generated output product 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 output product data set. This may allow to configure access to the output product data set such that access to such data by unauthorized data consumers is avoided. Access to the generated output product data set may be controlled based on the digital output product identifier associated with the output product data set and the output product.

[0142] 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 output product 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 output product data set. Use of such incident data may allow to avoid provision of output product data sets which may not be validated by the consumer side, thus resulting in delay of generation of product passport(s) since such generation must be delayed until output product data set(s) including valid data are available from the provider side.

[0143] In an embodiment of the method for validating input material data associated with input material(s), the product data further includes product property data including at least one measured chemical and / or physical property of the product and / or at least one chemical and / or physical property determined from collected data associated with the production of the product. 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 product.

[0144] In an embodiment of the method for validating input material data associated with input material(s), the decentral data providing node(s) are determined from mapping data mapping decentral data providing node data to associated input material identifier(s) by matching input material identifier(s) included in the product data to output product 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 output product identifier(s) and associated data providing node data may be provided by respective decentral data providing node(s) to the consuming entity consuming such output product data from such data providing node(s). Data providing node data may include location data pointing to the location of the output product 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 output product data set(s), hence the database may not be regarded as a central repository of output product data set(s). Instead, the control over access to the output product data set(s) is retained by the respective data providers, while such database only allows to locate output product data set(s) required to generate respective product passports.

[0145] In an embodiment of the method for validating input material data associated with input material(s), the obtained input material data is provided to one or more input node(s) configured to gather the obtained input material data and to provide the gathered input material data as input material 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 input material data set(s) provided by the one or more input node(s), link the validated input material data to at least one of the product identifiers, determine storage location(s) for the validated input material data and to provide the validated input material data linked to product identifier(s) to the determined storage location(s). An input node may represent a computing node gathering input material 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 input material 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.

[0146] In an embodiment of the method for validating input material data associated with input material(s), the rule-based engine operates on individual data points present within at least part of the input material data, multiple data points present within at least part of the input material data or the whole input material data. The rule-based engine may be configured to validate input material 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 input material 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 input material data passed the one or more applied rule(s). Validating the input material data on data point level may ensure that all input material data point(s) required by the data model associated with the product or product type are contained in the gathered input material data. Validation on data point level may compensate for the simplified output product data set generation at the provider side which does not require the use of data models ensuring that the generated output product data set(s) include all required data point(s).

[0147] In an embodiment of the method for validating input material data associated with input material(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 input material 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 product(s) or product type(s).

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

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

[0150] In an embodiment of the method for validating input material data associated with input material(s), the one or more rule(s) are associated with or derived from a data model of the product or product type, in particular wherein the one or more rule(s) are defined by the mandatory input material 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 product passport. The data model may define the value(s) and / or value range(s) for data point(s) to be included in the product passport. The data model may define mandatory and optional data point(s) to be included in the product passport. The data model may define relationships between different data point(s).

[0151] In an embodiment of the method for validating input material data associated with input material(s), validating the gathered input material data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered input material data and providing the applicable rule(s) to the rulebased 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 input material identifier included in the gathered input material data as previously described. The applicable rule(s) may be included in a rule template. Hence validating the gathered input material 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 input material identifier included in the gathered input material 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 input material identifier(s) and optionally input material type identifier(s).

[0152] In an embodiment of the method for validating input material data associated with input material(s), transforming the gathered input material data includes

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

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

[0155] In an embodiment of the method for validating input material data associated with input material(s), the input material data is validated responsive to fulfilment of one or more rule(s) applied to the input material data by the rule-based engine. This may ensure that the gathered input material 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 product passport may be generated by applying the respective data model to the validated input material data and respective product data without any errors due to missing or wrong input material data, hence avoiding a delay in generation of the product passports.

[0156] In an embodiment of the method for validating input material data associated with input material(s), the storage location is determined based on mapping data including a mapping between input material identifier(s) and associated storage location data or a mapping between input material identifier(s) and associated input material 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 input material data to be used for the generation of product passports associated with a specific product type, such as a battery, may be stored within a particular dedicated storage accessible only by the application generating the passports for such specific product type but not for other applications generating passports for other product types.

[0157] In an embodiment of the method for validating input material data associated with input material(s), the validated input material data includes one or more validated input material property data point(s), validated input material identifier data point(s), validated input material name data point(s), validated input material producer data point(s), validated input material declaration data point(s), validated input material safety data point(s), validated input material emission data point(s), validated input material recyclate content data point(s), validated input material biobased content data point(s), validated input material biodegradability data point(s), validated input material production data point(s), validated input material certificate of analysis data point(s), validated input material certificate data point(s), validated input material life cycle data point(s), validated input material storage instruction data point(s), validated input material assembly instruction data point(s) and / or validated input material operating condition data point(s). In an embodiment of the method for validating input material data associated with input material(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 input material 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 material data was received, hence allowing the data provider to generated updated input material data and to provide such updated input material data for repeated validation.

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

[0159] 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.

[0160] 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).

[0161] 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).

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

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

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

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

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

[0167] FIG. 7 illustrates an example system and associated methods for generating output product data set(s) associated with produced output product(s) and providing access to the generated output product data set(s). FIG. 8 illustrates an example of a decentral system for accessing output product data set(s) associated with output product(s).

[0168] FIG. 9 illustrates a flow chart of an example method for generating output product data set(s) associated with output product(s).

[0169] FIG. 10 illustrates an embodiment of the method illustrated in FIG. 9.

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

[0171] FIG. 12 illustrates a sequence diagram of an example method for generating output product data set(s) associated with produced output product(s).

[0172] FIG. 13A illustrates a block diagram of an example system for validating input material data associated with input material(s) used to produce a product.

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

[0174] FIG. 14 illustrates a flow chart of an example method for validating input material data associated with input material(s) used to produce a product.

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

[0176] FIG. 16 illustrates a sequence diagram of an example method for validating input material data associated with input material(s) used to produce a product.

[0177] FIG. 17 illustrates a flow chart of a further example method for validating input material data associated with input material(s) used to produce a product.

[0178] DETAILED DESCRIPTION

[0179] 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.

[0180] 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.

[0181] 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 input material data, for example as described in the context of FIG. 14 and may generate product passports using at least a part of the gathered input material 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.

[0182] 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.

[0183] 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.

[0184] 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 output product. 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 an output product data set associated with the product, for example as described in the context of FIG. 9.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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). 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.

[0189] 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.

[0190] 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 input material data, for example as described in the context of FIG. 14 and may generate battery passports using at least a part of the gathered input material 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.

[0191] 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.

[0192] 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.

[0193] 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 output product. 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 input material data associated with input materials, for example as described in the context of FIG. 14.

[0194] 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 .

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

[0196] 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).

[0197] The decentral network 134 may include further decentral network nodes as described in the context of

[0198] FIG. 1. FIG. 3A and FIG. 3B illustrate a schematic block diagram of a production process of a battery. 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).

[0199] 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.

[0200] 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).

[0201] 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).

[0202] 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.

[0203] 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.

[0204] 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.

[0205] 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 product 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 input material 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.

[0206] 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.

[0207] 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. With reference to FIG. 4, an identification element 404, 406 may be physically associated with the battery 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.

[0208] 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 input material 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.

[0209] 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 recycler(s) processing the battery. The identification element 404, 406 may be configured to provide the decentral battery identifier for accessing battery data.

[0210] 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 data relating to 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 material or component production producing the material or component, the battery production producing the battery or the production producing product(s) containing the battery. Via the decentral identifier and its unique association with the data owner and data relating to the product identified, access to the respective data may be controlled by the data owner. The data relating to the product identified may be accessible for the data owner. The data owner may hence directly or indirectly own or control the data relating to the product identified. The data relating to the product identified 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 data relating to the product identified via the data providing service of the data owner. The data owner may control access to the data relating to the product identified. . The data owner may control access to the battery passport via the decentral battery identifier The data relating to the product identified may be associated with the data owner. The data owner may be the owner or controller of the data relating to the product identified or the data relating to the product identified owner. The data relating to the product identified 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 data relating to the product identified or parts thereof and controlling access by decentral data providing network nodes of the decentral computing environment to the data relating to the product identified or parts thereof.

[0211] In particular, the decentral identifier may relate to 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.

[0212] 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.

[0213] Use of battery production in FIG. 3A to FIG. 5 shall not be understood limiting with respect to the underlying concepts outlined in this figures. The concepts illustrated in FIG. 3A to FIG. 5 are likewise applicable to the production of other discrete product(s) from one or more chemical material(s) and / or components and the use of such discrete products to produce component assemblies and / or end products. The concepts illustrated in FIG. 3A to FIG. 5 are likewise applicable to the production of chemical product(s) from one or more input materials.

[0214] FIG. 6A illustrates a block diagram of an example system for generating output product data set(s) associated with output product(s) and for providing the generated output product data set(s) for access by decentral data consuming nodes. The output product may be a chemical product, an intermediate chemical product, a component or a component assembly. The output product may be a component of a battery, such as a battery cell, a battery module or a battery pack. The output product may be any output product produced by upstream production stage(s) with respect to the product 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 an output product production, producing the output product(s). The output product may be produced or producible by the production. Produced output products may include physical entities of output products having been produced by the production. Producible output products may include output products not yet having been produced by the production. Producible output products may be producible by one or more production processes performed within the production.

[0215] With reference to FIG. 7, the output product 706 may be produced or producible using one or more input material(s) 702. The output product may comprise or be any product produced by the production 704 and provided at any exit point of the production 704. The production 404 may be a chemical production. The chemical production may be a chemical production network. The production 404 may be a discrete production. The input material may include starting material used in a production process performed within production 704 to produce the output product. 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.

[0216] The output product 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.

[0217] 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 output product(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 output products produced by the production 704. The operating system 716 may further receive a bill of materials associated with output products to be produced. The bill of materials may include material data associated with the input materials used to produce the output product, process data associated with the production chain for producing the output product and / or output product data associated with the output product, such as a product specification data or data on the amount of output product to be produced.

[0218] 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 output product. The material demand data may include input material identifiers associated with input materials required to produce the output product 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.

[0219] The amount of output product(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 output product identifier associated with the respective output product. Physical and / or chemical properties of produced output products 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 output products 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 output products may be interrelated with a digital output product identifier associated with the respective output product.

[0220] The produced output products 706 may be provided at one or more exit points of the production 704. The output product 706 may exit the system boundary 714 of the production 704.

[0221] 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 output product data set(s) (e.g. asset(s)) associated with output product(s) produced by production 704, for example as described in the context of FIG. 9.

[0222] Referring back to FIG. 6A and with continued reference to FIG. 7, the asset generation system 646 may generate output product 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 the output product 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 output product(s) and / or packaged output products. The sensor(s) may be configured to detect an identification element physically attached to the produced output product or the packaged output product. The sensor data may be used by trigger generator 712 to generate trigger data including data associated with the produced output product. Data associated with the produced output product may include a digital output product identifier associated with the produced output product. 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 output products, such as output product name(s), output product quantities, output product identifiers, etc.. The data associated with the output product may be gathered from the one or more databases storing such data. The user may select output product(s) displayed by the frontend application. In response to selecting output product(s), a back-end application connected to the frontend application may generated the trigger data by collecting digital output product identifier(s) associated with the selected output product(s). The collected digital output product identifier(s) be used to generate the trigger data.

[0223] 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 output product 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 chemical product. 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 output product 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 output product data associated with produced output products. The output product data may include output product identifier(s), property data associated with the output product, the output product name, the output product producer, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificates associated with the output product, life cycle data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product or a combination thereof. At least one of the distributed data sources may contain data instances that relate to the output product for which the system 710 is configured to generate the output product data set(s). The data source layer 620 may be owned or controlled by the data owner of the data associated with output product data. The data source layer 620 may be associated with the data owner of the output product data. Data gathering unit 622 may be configured to gather output product data based on received trigger data (e.g. data associated with produced output products) from the data source layer 620, for example as described in the context of FIG. 9. The gathered output product data may include property data associated with the output product, the output product name, the output product producer, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificates associated with the output product, life cycle data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product or a combination thereof.

[0224] The output product data gathered by data gathering unit 622 may be provided to data transforming unit 624. Data transforming unit 624 may be configured to generate output product data set(s) by transforming output product 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 output product data, aggregating output product data gathered from multiple data sources into a given data structure, attribute construction to create or add new attributes to the output product data based on existing attributes, discretization to convert continuous output product data values into sets of data intervals with specific values, generalization of gathered output product data to convert low-level data attributes into high-level data attributes, manipulation to change or alter gathered output product data and / or normalization to converts output product 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 output product data. The rule(s) may define value(s) to be included in the generated output product data. 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 property data, output product identifier data, output product name data, output product producer data, output product declaration data, output product safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, life cycle data, storage instruction data, assembly instruction data and / or 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 output product data sets may include one or more data points. The output product data sets may include one or more key-value pairs. The generated output product data sets may include at least a part of the gathered output product data. The generated output product data set(s) may include output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product operating condition data point(s). The output product data set(s) may include at least a part of the gathered output product data in a tabular data structure. Use of rule(s) associated with a product produced from such output product(s) allows to ensure that output product data point(s) required according to a data model, such as an aspect model, associated with the product or product type are contained in the output product data set, hence avoiding missing data point(s) during generation of a product passport associated with the product using said data model. The transformation allows to aggregate the gathered output product into a given data structure, such as a tabular data structure, without the use of complex data models, hence facilitating generation and sharing of output product data set(s) within the product ecosystem. Such sharing may enable more efficient production and / or recycling processes based on the shared output product data, for instance based on output product composition data included in the shared output product data sets. 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 product passports (see for example FIG. 13A and FIG. 13B). Verification by the consumer side ensures that the product passport contains all data required by a data model used to generate such passport, hence allowing to reduce the complexity associated with the output product data set generation at the provider side by avoiding the use of data semantic models during generation of the output product data set(s). This may enable reliable sharing of output product data of output product(s) irrespective of the existence of data models for such output products since the rule(s) required to transform the gathered output product data may be readily derived from or generated based on existing data model associated with the product or product type.

[0225] Data transforming unit 624 may further be configured to provide the generated output product 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 output product data set(s) to a database for storage, such as assets DB 604. The asset(s) may include or be associated with the digital output product identifier associated with the output product. This may allow to retrieve the asset based on the digital output product identifier. The asset(s) may be persisted by data transforming unit 624 in assets DB 604. Assets DB 604 may be configured to store output product data set(s) generated by data transforming unit 624. Assets DB 604 may be configured to provide output product data set(s) to data transfer service 602.

[0226] Data provider unit 644 may further be configured to provide data included in the generated output product data set(s), such as the digital output product identifier, to asset publisher service 608.

[0227] Asset publisher service 608 may be configured to generate group access data associated with the respective output product 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 output product 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 output product data set. Asset publisher service 608 may further be configured to generate a contract template including the digital output product identifier and the group access data identifier. The contract template may hence be associated with the output product 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 output product data set. This may allow to access the respective output product data set based on data included in the contract template, e.g. the digital output product 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 output product data set, for example per digital output product identifier. The generated group access data and contract template may be provided to decentral data providing node 118 connected to asset generation system 646.

[0228] 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 output product 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 output product 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 product ecosystem, such as a producer of the output product(s).

[0229] Data transfer service 602 may be configured to gather output product 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 output product data set and / or the storage location of the respective output product data set. Data transfer service 602 may be configured to gather respective output product data set(s) from assets DB 604 based on the fetched metadata. Data transfer service 602 may be configured to provide the gathered output product data set(s) to decentral data providing node 118.

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

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

[0232] 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 output product data. The rule based engine 628 may operate on data gathered per digital output product identifier individually. This allows to transform gathered output product data per output product, hence allowing a more granular transformation of the output product data. Rule based engine 628 may receive a request to transform gathered output product data. The request may contain at least a part of the gathered output product data. Output product 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 output product identifier(s) associated with the output product data. For instance, rule based engine 628 may parse the received output product data to determine the respective output product 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 output product type identifier(s) and / or output product 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 output product identifier(s).

[0233] One or more rule(s) associated with the output product 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 product(s) produced from the output product associated with the output product data to be transformed, e.g. the output product associated with the output product data to be transformed may be used as input material to produce the product. The product may be a component. The product may be a component-assembly. The product may be an end product. The product may be a chemical product. The one or more rule(s) may be associated with or derived from a data model of the product or product type. Hence, the one or more rule(s) may ensure that data point(s) for such output products required according to the data model may be included in the generated output product data set. The one or more rule(s) may be defined by the mandatory output product data points present within the data model. The one or more rule(s) may be generated based on the mandatory output product data points present within or defined by the data model. This may ensure that output product data required by the data model is included in the generated output product data set. The one or more rule(s) may be associated with output product identifier(s) and / or output product type identifier(s). A mapping table may be used to map output product identifier(s) to corresponding output product type identifier(s). The output product type identifier(s) may be associated with output product type(s). The mapping table may be stored in a separate database (not shown). Rule based engine 628 may be configured to gather output product type identifier(s) based on determined output product identifiers) and to request rule(s) based on the gathered output product type identifier(s). This may allow to gather rule(s) associated with output product type identifier(s) based on output product identifier(s), hence avoiding generation of rule(s) per output product identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1318. The one or more rule(s) may define aggregation rule(s) for aggregating output product 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 output product data into a tabular data structure. The one or more rule(s) may define filters to filter gathered output product data. The filters may be associated with or relate to the semantic data of the product or product type. The filters may define data point(s) to be included in the generated output product data set. For instance, a filter may define one for more output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product 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 output product data required by the data model is included in the generated output product data set. The one or more rule(s) may define attribute construction(s) to create or add new attributes to the gathered output product data. The one or more rule(s) may define manipulation(s) to convert output product data point(s). For instance, data point(s) present within the gathered output product data may be converted from one unit into another unit. This may ensure that the generated output product data set includes data points associated with a unit required by the data model of the product. 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 output product identifier and / or output type 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.

[0234] 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 output product data (see operation 634) to transform the output product data according to the obtained rule(s). Execution of the logic may result in matching gathered output product data to condition(s) included in the executable logic, evaluating the condition(s) with matched output product data and triggering execution of rule actions based on condition evaluation results. Transforming the output product data may include filtering gathered output product data. Filtering the gathered output product data may include comparing individual data points present within the gathered output product data to data points defined by the filter(s) to determine output product data points to be included in the output product data set. Transforming the output product data may include comparing attributes of the gathered or filtered output product data to attributes defined in rule(s) to determine whether new attributes have to be created or added to the gathered or filtered output product data. In addition or alternatively, transforming may include comparing attribute(s) included in the gathered or filtered output product data or output product 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 output product data. The trigger condition may be satisfied if the attribute(s) included in the gathered or filtered output product data or output product 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 output product data.

[0235] Rule based engine 628 may be configured to determine whether the gathered output product data can be transformed by one or more applied rule(s) (see operation 636). Gathered output product 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 output product data) if the gathered output product data does not include data point(s) required according to one or more obtained rule(s). Rule based engine 628 may provide the generated output product data set to assets DB 604 responsive to the gathered output product data being successfully transformed (e.g. responsive to generation of an output product data set by applying one or more obtained rule(s) without resulting in an error.

[0236] If at least a part of the gathered output product 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 output product data could not be transformed. The message data may include an indication which data point(s) of the gathered output product 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 output product data may be initiated. FIG. 8 illustrates an example of a decentral system for accessing data associated with produced output product(s). The output product may be a battery component, such as a battery cell, a battery module or a battery pack. The output product may be a chemical product or an intermediate chemical product. The output product may be any output product produced by upstream production stage(s) with respect to the chemical product production stage. The decentral system may be a decentral peer-to-peer network 134, 208 as described in the context of FIG. 1 and FIG. 2.

[0237] The output product may be associated with output product data set(s). The output product data set(s) may be generated as described in the context of FIG. 6A to FIG. 7. The output product 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 output product. The decentral network participant may be the data owner of the output product data set(s) stored in assets DB 604. The output product data set(s) may represent at least a part of a digital twin of the physical entity of the output product. 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 output product in a digital representation of a real-world system.

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

[0239] 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 output product data, associated with an output product to data consumer. The data consumer may request input material data, such as the output product data, from the data provider. The data provider may correspond to an entity producing output products, such as chemical products or discrete products. The data consumer may correspond to an entity using the produced output product(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 product. 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. 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 output product data, hence ensuring that the output product data can be exchanged in a secure and controlled manner within the decentral network.

[0240] 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 output product data (also denoted as input material 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 output product data received from consumer node 122, for example as described in the context of FIG. 13A to FIG. 16.

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

[0242] 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 product ecosystem. The entity performing such methods may not be a participant of the product ecosystem but may function as a service provider providing validated input material data for generation of product passports. The service provider may gather input material data from various provider environment(s) associated with input material data of input materials used to produce a given product, such as an end-product or a component thereof. The service provider may process the gathered input material data as described in the context of FIG. 13A to FIG. 17. The service provider may provide the processed input material data for generation of product passports.

[0243] 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 output product(s). Data provider environment 808 may include assets DB 604 storing output product data set(s) of produced output product(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 output product data set(s) stored in assets DB 604. Provider node 118 may be configured to perform authentication and authorization step(s) prior to providing output product 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 output product data set(s) from assets DB 604 in response to a request received from provider node 118 and to provide the gathered output product data set(s) to provider node 118.

[0244] FIG. 9 illustrates a flow chart of an example method for generating output product data set(s) associated with output product(s). The method illustrated in FIG. 9 may be implemented by the system illustrated in FIG. 6A to FIG. 7. The output product may be a chemical product or a chemical intermediate product. The output product may be a discrete product. The discrete product may be a component or part or a part-assembly. The discrete product may be a battery or a battery component, such as a battery cell, a battery module or a battery pack. The output product may be used by one or more downstream participants of the product ecosystem as input material to produce one or more products. The output product may be any output product produced by upstream production stage(s) with respect to the product production stage. The output product may be produced or producible by a production, such as illustrated in FIG. 7.

[0245] With reference to FIG. 12, data associated with the output product 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 output product may include digital output product identifier(s). The digital output product identifier(s) may include output product name, output product number, LOT number, batch number or a combination thereof.

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

[0247] An output product data set may be generated by transforming the gathered output product data using a rule-based engine including one or more rule(s) associated with a product produced from the output product (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 product or the product type. The product may be produced from the output product by using the output product as input material within at least one production step of the production process of the product. The production process of the product may include one or more production steps. The production steps may be performed by one or more entities of the product ecosystem. The output product may be used as input material within at least one of such production step.

[0248] With reference to FIG. 6B, FIG. 10 and FIG. 12, transforming the gathered output product data by the rule-based engine may include identifying one or more rule(s) applicable to the gathered output product data. The gathered output product 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 an output product identifier included in the gathered output product data. The identifier associated with each applicable rule may include an output product identifier matching the output product identifier included in the gathered output product data. The identifier associated with each applicable rule may include an output product type identifier related to the output product identifier included in the gathered output product data. The output product type identifier related to the output product identifier included in the gathered output product data may be determined based on mapping data as described in the context of FIG. 6B.

[0249] 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.

[0250] With continued reference to FIG. 6B, FIG. 10 and FIG. 12, an output product data set may be generated by transforming the gathered output product 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 output product 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 output product data set(s) may be provided from data transforming unit 624 to data provider unit 644.

[0251] It may be verified whether the gathered output product 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 output product data) (see block 908). Verification may be performed as described in the context of FIG. 6B. If the gathered output product 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.

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

[0253] The generated output product data set may be provided for access via a decentral network under control of the data owner of the output product data set. With reference to FIG. 12, this may include storing the generated output product 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 output product data set, for example as described in the context of FIG. 14.

[0254] Use of rule(s) associated with a product produced from such output product(s) allows to ensure that output product data point(s) required according tothe data model, such as an aspect model, associated with the product or product type are contained in the output product data set, hence avoiding missing data point(s) during generation of a product passport associated with the product using said data model. The transformation allows to aggregate the gathered output product data 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 output product data set(s) within the product ecosystem. Such sharing may enable more efficient production and / or recycling processes based on the shared output product data, for instance based on output product composition data included in the shared output product data sets. 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 product passports. Validation by the consumer side ensures that the product passport contains all data required by a data model used to generate such passport, hence allowing to reduce the complexity associated with the output product data set generation at the provider side by avoiding the use of complex data models during generation of the output product data set(s). This may enable reliable sharing of output product data of output product(s) irrespective of the existence of data models for such output products since the rule(s) required to transform the gathered output product data may be readily derived from or generated based on the data model associated with the product or product type.

[0255] FIG. 11 illustrates a flow chart of a further example method for generating output product data set(s) associated with output product(s). The method illustrated in FIG. 11 may be implemented by the system illustrated in FIG. 6A to FIG. 7. The output product may be a chemical product or a chemical intermediate product. The output product may be a discrete product. The discrete product may be a component or part or a part-assembly. The discrete product may be a battery or a battery component, such as a battery cell, a battery module or a battery pack. The output product may be any output product produced by upstream production stage(s) with respect to the product production stage. The output product may be used by one or more downstream participants of the product ecosystem as input material to produce one or more products. The output product may be produced or producible by a production, such as illustrated in FIG. 7.

[0256] Incident data including non-validated output product data and data associated with rule(s) or a rule template resulting in the non-validation of such output product 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 output product data point(s), the output product 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.

[0257] With reference to FIG. 8, the incident data may be received by a data provider environment 808 associated with the non-validated output product 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.

[0258] 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.

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

[0260] With continued reference to FIG. 6A and with reference to FIG. 6B, one or more rule(s) associated with the output product 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 output product identifier or a corresponding output product 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.

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

[0262] Use of incident data to update rule(s) applicable to the output product data associated with the incident data may allow to generate updated output product 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 output product data - updated output product 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 output product data set(s) may not result in the same validation error. This may result in a more efficient validation and ensures that validated input material data is available for product passport generation prior to providing such product associated with the product passport to a consumer. This allows the consumer, such as an end product user or recycler, to gather the passport data included in the product passport associated with the product and to use the gathered passport data to optimize and / or control production of further products using the product and / or to optimize and / or control recycling processes of end products produced from the product.

[0263] FIG. 13A illustrates a block diagram of an example system for validating input material data associated with input material(s) used to produce a product. The input material(s) may be used as production input(s) in one or more process step(s) associated with the production of the product. The process step(s) may be performed by one or more entities. The product may be a discrete product, such as a component, a part, a component-assembly, an end product or a recycled material. The product may be a battery. The product may be a chemical product or a chemical intermediate product. Input material(s) may include chemical input materials and / or discrete input material(s). Discrete input material(s) may include part(s), component(s) and / or component assembly / ies. Chemical input material(s) may include raw materials, such as virgin material(s) and / or recycled material(s). 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 the product production.

[0264] 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.

[0265] 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 be a service provider providing validated input material data for generation of product passports, e.g. may not be a participant of the product ecosystem. With reference to FIG. 8, decentral data consuming node 122 may be configured to request access to output product data set(s) at provider node(s) associated with such output product data set(s). The output product data set(s) may correspond to the input material data to be validated by the system. The request may include the output product identifier associated with the output product 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 output product 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 output product 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 output product data set(s) may be provided by respective data provider(s).

[0266] 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 output product identifier. The electronic contract may further include the endpoint(s) associated with the output product data set(s). The endpoint(s) may point to the dedicated storage storing the respective output product 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 output product 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 output product 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 output product data set(s). Signature of such electronic contracts generated from group access data and a contract template associated with respective output product identifier(s) ensures that the consumer node 122 and further systems, such as asset validation system 1342, handling the provided output product data are complying to at least one authorization rule included in the electronic contract associated with the output product data set(s). This may ensure that the output product data set(s) may be exchanged in a secure and controlled manner, hence avoiding access to output product data set(s) by unauthorized decentral network participants while allowing to provide the output product data set(s) to decentral network participants required to use such provided output product data set(s), for example to control and / or monitor production of the product and / or to monitor and / or control recycling operations and / or to generate product passports associated with the products. With continued reference to FIG. 8, data providing node(s) may provide output product data set(s) associated with output product data identifier(s) included in the request received from consumer node 122 upon signature of the electronic contract. The output product data set(s) may be gathered from a dedicated storage, such as assets DB 604 as described in the context of FIG. 6A and FIG. 9.

[0267] Returning to FIG. 13A, consumer node 122 may provide the received output product data set(s) (e.g. input material data) 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. Input material data gathered via the decentral network may flow through data transfer service 1302 and stream storage system 1312 to data transforming unit 1304.

[0268] Data transfer service 1302 may be configured to receive input material data from consumer node 122. The input material 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 input material data associated with a given input material via an input material 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 input material data received from consumer node 122. A data package may be generated by received input material data set. The data package may include further data, such as a time stamp, a date stamp, the input material identifier associated with the input material data, the decentral participant identifier associated with the provider node, location data pointing to the dedicated storage storing the output product 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.

[0269] 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.

[0270] 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 input material 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.

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

[0272] Stream storage system 1312 may be configured to determine if the received or pulled input material data is already contained in the one or more persistent or non-persistent logs. If said input material 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 input material data in said logs. If said input material 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 input material data in the one or more persistent or non- persistent logs or to update input material data present in the persistent or non-persistent log(s) with the received or pulled updated input material data. This may avoid that the same input material data is stored multiple times in the persistent or non-persistent log(s), hence avoiding redundant validation operations on the input material data stored in stream storage system 1312.

[0273] 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 input material 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.

[0274] 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 input material data included in said data packages. Data consuming unit 1308 may be configured to extract input material data from the data packages and provide the extracted input material identifier and input material data to data validation unit 1310. Data validation unit 1310 may be configured to validate input material 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 input material data. The input material data may be validated if at least a part of the applied rules are fulfilled. Applying the rule(s) to the input material data may include comparing the combination of input material identifier and location data to a database storing such combinations of input material identifier(s) and associated location data. Applying the rule(s) to the input material data may include comparing data point(s) present within one or more rule(s) to individual data point(s) present within the input material data to be validated. Applying the rule(s) to the input material data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the input material data to be validated. Applying the rule(s) to the input material data may include comparing the data defined in one or more rule(s) to the whole input material data to be validated. The one or more rule(s) may be associated with a product produced from the input material(s). The one or more rule(s) may be associated with a data model of the product or product type. The data model may include a semantic description of the product passport associated with the product. The semantic description may include a semantic description of input material data and product data. The semantic description may include the structure of at least a portion of the product passport, and / or properties of the product passport. The properties of the product passport set may include data types. The properties of the product passport set may include possible or allowable values and / or value ranges. The properties of the product passport set may be a physical unit of parameter(s) described by values contained in the product passport. The data type(s) and associated value(s) and / or value range(s) of input material data may be included in the one or more rule(s). This may allow to validate whether gathered input material data fulfils the data type(s) and associated value(s) and / or value range(s) required for input material data according to the data model. By validating the input material data against one or more rule(s) generated from the data model, it may be ensured that input material required by the data model is indeed included in the gathered input material data, allowing to ensure that product passport(s) generated from such validated input material data include all required input material data. Validation of gathered input material data on data point level may allow to reliably perform the validation irrespective of the data structure of the input material data. This may allow, in turn, to generate the input material data without having to use complex data models. Instead, input material data may be generated in a tabular representation by the data providers and may be used by the data validation unit for validation of data point(s) included in the input material data. The one or more rule(s) may define one for more input material property data point(s), input material identifier data point(s), input material name data point(s), input material producer data point(s), input material declaration data point(s), input material safety data point(s), input material emission data point(s), input material recyclate content data point(s), input material biobased content data point(s), input material biodegradability data point(s), input material production data point(s), input material certificate of analysis data point(s), input material certificate data point(s), input material life cycle data point(s), input material storage instruction data point(s), input material assembly instruction data point(s) and / or input material 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.

[0275] By validating the input material data against one or more rule(s) generated from the data model, it may be ensured that input material data required by the data model is indeed included in the gathered input material data, allowing to ensure that product passport(s) generated from such validated input material data include all required input material data. Validation of gathered input material data on data point level may allow to reliably perform the validation irrespective of the data structure of the input material data. This may allow, in turn, to generate the input material data (denoted as output product data in FIG. 6A, FIG. 6B) without having to use complex data models. Instead, output product 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 output product data set(s) received as input material data by the data consumer side.

[0276] The validated input material data generated by data validation unit 1310 may include one or more validated input material property data point(s), validated input material identifier data point(s), validated input material name data point(s), validated input material producer data point(s), validated input material declaration data point(s), validated input material safety data point(s), validated input material emission data point(s), validated input material recyclate content data point(s), validated input material biobased content data point(s), validated input material biodegradability data point(s), validated input material production data point(s), validated input material certificate of analysis data point(s), validated input material certificate data point(s), validated input material life cycle data point(s), validated input material storage instruction data point(s), validated input material assembly instruction data point(s) and / or validated input material operating condition data point(s).

[0277] Data validation unit 1310 may further be configured to determine the storage location to which the validated input material is to be persisted. The storage location may be determined based on mapping data including a mapping between input material 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 input material identifier and input material type identifier and a second mapping between input material 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 input material data may allow to persist validated input material data in storage locations associated with given applications or systems(s). For instance, the validated input material data associated with a given product, such as a battery or a given chemical product, may be persisted in a storage location associated with a given application processing such validated input material data. Processing may, for example include generation of product passport(s) using such validated input material data. Validated input material data which may not be mapped to a given application may be persisted in a general storage, such as storage general 806.

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

[0279] 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 input material data stored in a database, such as storage general 806. The non-validated input material 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 input material 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 input material identifier. Incident data generator 1344 may query the database for input material data associated with the classifier. Incident data generator 1344 may assemble gathered input material data into incident data based on the input material identifier associated with the gathered input material 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 nonvalidated input material 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 nonvalidated input material data (e.g. output product 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 generate updated output product data set(s), for example as described in the context of FIG. 11 , and to provide the updated output product data set(s). Hence, the use of incident data may ensure that non-validated input material data point(s) can be corrected by respective data providers such that the updated output product 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 input material data required to generate product passports and hence also in reliable generation of product passports. The product passports may allow to improve and / or control production of further products using the product and / or recycling processes of end products produced from the product based on passport data contained in the product passports.

[0280] FIG. 13B illustrates a diagram showing an example of validating input material data associated with input material(s) used to produce a product using a rule-based engine. The input material data may be gathered via a decentral network as described in the context of FIG. 6A. The gathered input material data may correspond to output product 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.

[0281] 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 input material data. The rule based engine 1322 may operate on data gathered per input material identifier individually. This allows to validate input material data per input material, hence allowing a more granular validation of the input material data. Rule based engine 628 may receive a request to validate gathered input material data. The request may contain at least a part of the gathered input material 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 input material 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 input material type identifier(s) and / or input material 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 input material identifier(s).

[0282] One or more rule(s) associated with the input material 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 input material data, e.g. to be present within a consumed input material data set. The one or more rule(s) may be associated with product(s) produced from the input material associated with the input material data to be validated. The product may be a component. The product may be a component-assembly. The product may be a chemical product. The one or more rule(s) may be associated with or derived from or generated based on a data model of the product. Hence, the one or more rule(s) may ensure that data point(s) associated with input material(s) and being required according to the data model may be included in the consumed input material data. The one or more rule(s) may be defined by the mandatory input material data point(s) present within the data model. The one or more rule(s) may be generated based on the mandatory input material data point(s) present within or defined by the data model. This may ensure that input material data required by the data model is included in the consumed input material data. The one or more rule(s) may define one for more input material property data point(s), input material identifier data point(s), input material name data point(s), input material producer data point(s), input material declaration data point(s), input material safety data point(s), input material emission data point(s), input material recyclate content data point(s), input material biobased content data point(s), input material biodegradability data point(s), input material production data point(s), input material certificate of analysis data point(s), input material certificate data point(s), input material life cycle data point(s), input material storage instruction data point(s), input material assembly instruction data point(s) and / or input material 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 input material identifier(s) and / or input material type identifier(s). A mapping table may be used to map input material identifier(s) to corresponding input material type identifier(s). The input material type identifier(s) may be associated with input material type(s). The mapping table may be stored in a separate database (not shown). Rule based engine 1322 may be configured to gather input material type identifier(s) based on determined input material identifiers) and to request rule(s) based on the gathered input material type identifier(s). This may allow to gather rule(s) associated with input material type identifier(s) based on input material identifier(s), hence avoiding generation of rule(s) per input material identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1318.

[0283] 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 input material data (see operation 1328) to validate the consumed input material data according to the obtained rule(s). Execution of the logic may result in matching consumed input material 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 input material 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 input material data point(s). The classifier may be a binary classifier discriminating validated and non-validated input material data. Consumed input material 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 input material data may include comparing individual data point(s) present within the rule(s) to individual data point(s) present within the input material data to be validated to determine whether the input material data to be validated includes individual data point(s) required by such rule(s). Applying the rule(s) to the consumed input material data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the input material data to be validated to determine whether the input material data contains data point combinations required by such rule(s). Applying the rule(s) to the consumed input material data may include comparing the data defined in the rule(s) to the whole input material data set to be validated to determine whether the input material 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 input material data and / or the whole input material data.

[0284] Rule based engine 1322 may be configured to determine whether the consumed input material data fulfills one or more applied rule(s) (see operation 1330). Consumed input material 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 input material data) if the consumed input material 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 input material data responsive to the determination that the consumed input material 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 input material 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 input material data is not associated with a given application, data validation unit 1320 may provide the validated input material data to a storage not being associated with any application processing the validated input material data, such as storage general 806. If data validation unit 1320 determines that the validated input material data is associated with a given application, data validation unit 1320 may provide the validated input material data to a storage being associated with such application processing the validated input material data stored therein, for example by generating product passports.

[0285] If at least a part of the consumed input material data could not be validated, rule based engine 1322 may indicate to data validation unit 1320 that at least a part of the consumed input material 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 input material data could not be validated. The message data may include an indication which data point(s) of the consumed input material 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.

[0286] Rule based engine 1322 may be configured to provide non-validated input material data to a storage not being associated with any application processing the validated input material data, such as storage general 806. The non-validated input material data may be provided to such storage along with a classifier classifying such input material data as non-validated. The non-validated input material 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 input material data.

[0287] FIG. 14 illustrates a flow chart of an example method for validating input material data associated with input material(s) used to produce a product. The method illustrated in FIG. 14 may be implemented by the system illustrated in FIG. 13A and FIG. 13B. The input material(s) may be used as production input(s) in one or more process step(s) associated with the production of the product. The process step(s) may be performed by one or more entities. The product may be a discrete product, such as a component, a part, a component-assembly, an end product or a recycled material. The product may be a battery. The product may be a chemical product or a chemical intermediate product. Input material(s) may include chemical input materials and / or discrete input material(s). Discrete input material(s) may include part(s), component(s) and / or component assembly / ies. Chemical input material(s) may include raw materials, such as virgin material(s) and / or recycled material(s). The product may be produced by a production.

[0288] Product data including product identifier(s) and input material identifier(s) associated with input material(s) used to produce the product may be provided (see block 1402). The identifier(s) associated with the input material(s) may be asset identifiers associated with or included in the input material data. The product data may be provided from one or more database(s) storing such product data. The one or more database(s) may be associated with the production. The product data may be provided by an entity producing the product to the entity performing the method illustrated in FIG. 14. The product data may further include product property data. The product property data may include at least one measured chemical and / or physical property of the product and / or at least one chemical and / or physical property determined from collected data associated with the production of the product. At least a part of the product 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 product identifier(s) to applications and associated databases. The mapping data may map product identifier(s) to product type identifier(s) and associated applications and databases.

[0289] Input material data may be gathered via a decentral network based on the input material identifier(s) included in the provided product data (see block 1404). The decentral network may be decentral network 134, 208 described in the context of FIG. 1 and FIG. 2. The input material 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 input material data as described in the context of FIG. 8. With reference to FIG. 15, gathering input material data may include determining decentral data providing node(s) associated with the input material data matching the input material identifier(s) (e.g. input material data associated with the provided input material identifier(s)). Determining such provider node(s) may include providing candidate decentral provider nodes associated with input material data of input material(s) used to produce the product. The candidate provider node(s) may be provided by providing a database storing candidate provider node data associated with input material identifier(s) matching output product identifier(s) of output product 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 input material identifier(s) associated with input material 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 input material identifier(s). Use of such mapping data allows to efficiently determine target provider node(s) associated with the required input material data, hence resulting in a reduced latency associated with the gathering of the input material data. This may ensure, that the input material data may be validated and the validated input material data may be processed, for example by generating product passports, prior to providing the product associated with the product passport to a consumer, such as an end product user. Efficient generation of product passports may avoid storage of produced product(s) prior to providing them to consumers due to the absence of associated product passports which may need to be generated from a regulatory standpoint prior to providing the associated product to a consumer.

[0290] With continued reference to FIG. 15, access data for target decentral provider nodes associated with the input material data may be determined based on the provided input material identifier(s). Target provider nodes may be identified by matching the provided input material identifier(s) to input material identifier(s) stored in the mapping data. The candidate provider node data associated with matching input material 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 input material data associated with provided input material identifier(s)).

[0291] With continued reference to FIG. 15, access to input material data associated with the provided input material identifier(s) may be requested from target data provider node(s) associated with the determined access data. Access to input material data may be requested as described in the context of FIG. 13A. The input material 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. Returning to FIG. 14 and with reference to FIG. 13A and FIG. 16, the gathered input material 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 input material data from the stream storage system. The consumer may extract input material identifier(s) and input material data from the consumed data package(s). The stream storage system may hence serve as an input material data sink and allows to compensate the asynchronous gathering of the input material data from the decentral network. Gathered input material 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 input material data set and avoids validating a given input material data set multiple times.

[0292] With continued reference to FIG. 13A and FIG. 16 and with further reference to FIG. 13B, at least a part of the gathered input material data may be validated by using a rule-based engine including one or more rule(s) associated with the product. The input material 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 an input material identifier included in the extracted input material data. The identifier associated with each applicable rule may include an input material identifier matching the input material identifier included in the extracted input material data. The identifier associated with each applicable rule may include an input material type identifier related to the input material identifier included in the extracted input material data. The input material type identifier related to the input material identifier included in the extracted input material data may be determined based on mapping data as described in the context of FIG. 13B.

[0293] 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.

[0294] With continued reference to FIG. 13B and FIG. 16, extracted input material 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 input material 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 input material 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 input material data points subject to the validation process and associated classifiers. The classifiers may indicate whether the respective input material 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.

[0295] Returning to FIG. 14 and with continued reference to FIG. 16, it may be verified whether the extracted input material 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 output product data) (see block 1408). Validation may be performed as described in the context of FIG. 13B. If the extracted input material 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 input material data could be validated, the method may proceed to block 1414. If the extracted input material data could not be validated, the method may proceed to block 1410.

[0296] 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 input material 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 input material data may be used to generate incident data, for example das described in the context of FIG. 13A and FIG. 17.

[0297] 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 input material data may be provided to a storage location as previously described.

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

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

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

[0301] By gathering input material data directly from respective data provider nodes associated with such input material data, e.g. by avoiding a query to the decentral network to locate the data provider node(s) associated with the desired input material data, the input material data may be gathered via the decentral network reliably and quickly. By validating the gathered input material data by a rule-based engine including one or more rule(s) associated with the product or product type, such as rule(s) associated with a data model of the product or product type, product passports may be reliably generated from such validated input material data since validation allows to ensure that all input material data points required according to the data model used to generate the product passport are available (e.g. are stored within a dedicated storage). By validating the gathered input material data at the consumer side, the input material data can be directly gathered from the provider side without requiring the provider side to provide input material data adhering to a defined data structure. Hence, the provider side may not be required to generate the input material data gathered by the consumer side by using complex data models resulting in highly defined input material data points. Instead, input material data may be provided as a tabular representation to the consumer side and such input material data may be validated on data point level to ensure that the gathered input material data includes all data point(s) mandatory with respect to a data model used to generate product passports from the validated input material data. By validating the input material data on consumer side, the effort to generate and provide input material data at the provider side is greatly reduced while maintaining security, hence resulting in reliable, quick and secure sharing of input material data required to generate product passports. This in turn may allow to generate product passports associated with products produced from such input materials in a reliable and efficient way, ensuring a high data quality of the chemical product passport as well as that such product passports are available upon providing the product to a consumer without having to store the product until generation of the associated product passport is completed. The high data quality of the product passport may allow consumers of the associated product to control and / or monitor production processes using the product and / or recycling processes involving the end-products or parts thereof produced from the product, in a more reliable and / or efficient way. In addition, this setup allows to gather input material data for various input material(s) from various data provider nodes simultaneously while ensuring that gathered input material data is correctly validated and persisted to a database associated with an application consuming the validated input material data persisted in such database. FIG. 17 illustrates a flow chart of a further example method for validating input material data associated with input material(s) used to produce a product. The method illustrated in FIG. 17 may be implemented by the system illustrated in FIG. 13A and FIG. 13B. The input material(s) may be used as production input(s) in one or more process step(s) associated with the production of the product. The process step(s) may be performed by one or more entities. The product may be a discrete product, such as a component, a part, a component-assembly, an end product or a recycled material. The product may be a battery. The product may be a chemical product or a chemical intermediate product. Input material(s) may include chemical input materials and / or discrete input material(s). Discrete input material(s) may include part(s), component(s) and / or component assembly / ies. Chemical input material(s) may include raw materials, such as virgin material(s) and / or recycled material(s).

[0302] Incident data including non-validated input material data and data associated with rule(s) or a rule template resulting in the non-validation of such input material 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.

[0303] The generated incident data may be provided via a decentral network to the decentral data provider associated with the non-validated input material data. The decentral data provider may be determined based on the input material 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 input material identifier. For instance, the input material identifier included in the incident data may be matched to input material 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.

[0304] 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 output product data set (corresponding to updated input material data), for example as described in the context of FIG. 11. The updated input material data may be provided to the consumer node providing the incident data used to generate the updated input material data. The updated input material 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 input material data after generation of such input material data, hence reducing a delay in transfer of the updated input material data to the consumer node and facilitating timely validation of the updated input material data and generation of the product passport using the updated and successfully validated input material data. This may avoid that product passports may not be generated due to lack of validated input material data and may ensure that product provided to the consumer, such as an end product user or recycler, is associated with a product passport allowing the consumer to gather passport data included in the product passport and to use gathered passport data to control and / or optimize further production processes using the product and / or recycling processes of end-products or parts thereof produced from the product.

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

[0306] 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.

[0307] 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.

[0308] 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.

[0309] 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.

[0310] 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 an output product data set associated with an output product, wherein the output product is used as input material to produce one or more product(s), the method comprising: providing data associated with the output product including at least one output product identifier; gathering - based on the provided data associated with the output product - output product data from one or more databases; generating the output product data set by transforming the gathered output product data using a rule-based engine including one or more rule(s) associated with at least one of the product(s); providing the generated output product 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 output product data set.

2. The method of claim 1 , wherein the gathered output product data includes output product identifier data, property data associated with the output product, output product name data, output product producer data, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, biodegradability data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificate data associated with the output product, life cycle data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product 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 output product data, multiple data points present within at least part of the gathered output product data or the whole gathered output product 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 products, in particular wherein the one or more rule(s) are defined by one or more mandatory output product 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 output product data gathered from multiple data sources into a given data structure, define filters to filter gathered output product data, define attribute construction(s) to create or add new attributes to the gathered output product data and / or include a trigger condition and a corresponding group of one more actions.

7. A method for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the method comprising: providing product data including product identifier(s) and input material identifier(s) associated with the input material(s); obtaining the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on the provided input material identifier(s); validating at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with at least one of the products; linking the validated input material data to at least one of the product identifiers; determining storage location(s) for the validated input material data based on input material identifiers associated with the validated input material data; providing validated input material data linked to at least one of the product identifier(s) to the determined storage location(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material 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 input material identifier(s) by matching input material identifier(s) included in the product data to output product identifier(s) included in the mapping data.

9. The method of claim 7 and 8, wherein the obtained input material data is provided to one or more input node(s) configured to gather the obtained input material data and to provide the gathered input material data as input material 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 input material data set(s) provided by the one or more input node(s), link the validated input material data to at least one product identifier associated with at least one of the products, determine storage location(s) for the validated input material data and to provide the validated input material data linked to the product 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 input material data, multiple data points present within at least part of the input material data or the whole input material 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 the input material 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 input material identifier(s) and associated storage location data or a mapping between input material identifier(s) and associated input material type identifier(s) and storage location data.

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

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

Images