Systems and methods for validating and generating battery passports

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 validating an amount of data accessible for generating and / or updating a battery passport associated with a battery. The disclosure further relates to methods, apparatuses, systems, and computer elements for generating or updating a battery passport associated with a battery. The disclosure further relates to a battery associated with a battery passport generated and / or updated as disclosed herein and to a battery passport associated with a data completeness metric generated as disclosed herein. The disclosure further relates to a use of the data completeness metric generated as disclosed for generating and / or updating battery passports and to a use of the battery passport generated and / or updated as disclosed herein to further process a battery associated with the battery passport.

Description

[0001] SYSTEMS AND METHODS FOR VALIDATING AND GENERATING BATTERY PASSPORTS

[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 validating an amount of data accessible for generating and / or updating a battery passport associated with a battery. The disclosure further relates to methods, apparatuses, systems, and computer elements for generating or updating a battery passport associated with a battery. The disclosure further relates to a battery associated with a battery passport generated and / or updated as disclosed herein and to a battery passport associated with a data completeness metric generated as disclosed herein. The disclosure further relates to a use of the data completeness metric generated as disclosed for generating and / or updating battery passports and to a use of the battery passport generated and / or updated as disclosed herein to further process a battery associated with the battery passport.

[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, battery passports may need to be generated for such batteries. The battery passports contain various data including data associated with input material(s) used to produce the battery. Such data needs to be provided by input material producer(s) producing such input material(s) for generation and / or updating of the battery passport. The lack of transparency with respect to data accessible for the generation and / or updating of battery passports may hamper provision of accurate and reliable battery passports required for efficient further processing and / or recycling of the battery.

[0006] SUMMARY OF THE INVENTION

[0007] Disclosed is in one aspect a computer-implemented method for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising:

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

[0009] • providing data associated with data sources indicating data accessible for generating and / or updating battery passports associated with batteries;

[0010] • gathering data related to a data model associated with the battery passport based on at least one of the digital battery identifiers;

[0011] • generating a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the data associated with the data sources and the data related to the data model,

[0012] • providing the generated data completeness metric. In a further aspect disclosed is a computer-implemented method for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising:

[0013] • providing data associated with the battery including at least one digital battery identifier associated with the battery,

[0014] • providing validated data associated with the production of the battery based on the at least one digital battery identifier, wherein the validated data is generated by gathering - based on the provided digital battery identifier(s) - data associated with the production of the battery from decentral data providing node(s) associated with the data associated with the production by a decentral data consuming node and validating at least a part of the gathered data using a rulebased engine including one or more rule(s) related to a data model associated with the battery passport,

[0015] • gathering data related to the data model associated with the battery passport based on at least one of the digital battery identifiers;

[0016] • generating a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the validated data and the data related to the data model,

[0017] • providing the generated data completeness metric.

[0018] In yet a further aspect disclosed is an apparatus for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the apparatus comprising:

[0019] • a data providing interface configured to provide data associated with the battery including at least one digital battery identifier associated with the battery,

[0020] • a data storage configured to provide data associated with data sources indicating data accessible for generating and / or updating battery passports associated with batteries;

[0021] • a data gathering unit configured to gather data related to a data model associated with the battery passport based on at least one of the digital battery identifiers;

[0022] • a metric generator configured to generate a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the data associated with the data sources and the data related to the data model,

[0023] • a data providing interface configured to provide the generated data completeness metric.

[0024] In yet a further aspect disclosed is an apparatus for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the apparatus comprising:

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

[0026] • a data validation unit configured to provide validated data associated with the production of the battery based on the at least one digital battery identifier, wherein the validated data is generated by gathering - based on the provided digital battery identifier(s) - data associated with the production of the battery from decentral data providing node(s) associated with the data associated with the production by a decentral data consuming node and validating at least a part of the gathered data using a rule-based engine including one or more rule(s) related to a data model associated with the battery passport;

[0027] • a data gathering unit configured to gather data related to the data model associated with the battery passport based on at least one of the digital battery identifiers;

[0028] • a metric generator configured to generate a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the data associated with the data sources and the data related to the data model,

[0029] • a data providing interface configured to provide the generated data completeness metric.

[0030] In yet a further aspect disclosed is a computer-implemented method for generating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising:

[0031] • providing data associated with the battery including at least one digital battery identifier associated with the battery,

[0032] • generating a data completeness metric associated with data being accessible for generating the battery passport according to the methods disclosed herein or by the apparatuses disclosed herein,

[0033] • validating the determined data completeness metric by comparing the data completeness metric to given data completeness threshold(s),

[0034] • based on the validated data completeness metric, gathering data associated with the production of the battery based on the data associated with the battery and / or the generated data completeness metric, generating the battery passport based on the gathered data associated with the production of the battery and providing the generated battery passport and optionally the data completeness metric for access, optionally wherein the battery passport and optionally the generated data completeness metric is provided for access under control of the data owner of the battery passport.

[0035] In yet a further aspect disclosed is an apparatus for generating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the apparatus comprising:

[0036] • a data providing interface configured to provide data associated with the battery including at least one digital battery identifier associated with the battery,

[0037] • a metric generator configured to generate a data completeness metric associated with data being accessible for generating the battery passport according to the methods disclosed herein or by the apparatuses disclosed herein,

[0038] • a validation engine configured to validate the determined data completeness metric by comparing the data completeness metric to given data completeness threshold(s), and

[0039] • a passport generator configured to gather - based on the validated data completeness metric - data associated with the production of the battery based on the data associated with the battery and / or the generated data completeness metric, configured to generate the battery passport based on the gathered data associated with the production of the battery and configured to provide the generated battery passport and optionally the data completeness metric for access, optionally wherein the battery passport and optionally the generated data completeness metric is provided for access under control of the data owner of the battery passport.

[0040] In yet a further aspect disclosed is a computer-implemented method for updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising:

[0041] • providing data associated with the battery including at least one digital battery identifier associated with the battery, • providing the battery passport including a decentral identifier and at least one of the digital battery identifiers,

[0042] • generating a data completeness metric associated with data being accessible for updating the battery passport according to the methods disclosed herein or by the apparatuses disclosed herein,

[0043] • gathering data associated with the production of the battery based on the data associated with the battery and / or the data completeness metric,

[0044] • updating the battery passport based on the gathered data associated with the production of the battery and providing the updated battery passport and optionally the data completeness metric for access, optionally wherein the battery passport and optionally the generated data completeness metric is provided for access under control of the data owner of the battery passport.

[0045] In yet a further aspect disclosed is an apparatus for updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the apparatus comprising:

[0046] • a data providing interface configured to provide data associated with the battery including at least one digital battery identifier associated with the battery,

[0047] • a passport provider configured to provide the battery passport including a decentral identifier and at least one of the digital battery identifiers,

[0048] • a metric generator configured to generate a data completeness metric associated with data being accessible for updating the battery passport according to the methods disclosed herein or by the apparatuses disclosed herein,

[0049] • a data gathering unit configured to gather data associated with the production of the battery based on the data associated with the battery and / or the data completeness metric,

[0050] • a passport updater configured to update the battery passport based on the gathered data associated with the production of the battery and providing the updated battery passport and optionally the data completeness metric for access, optionally wherein the battery passport and optionally the generated data completeness metric is provided for access under control of the data owner of the battery passport.

[0051] In yet a further aspect disclosed is a battery associated with a battery passport as generated and / or updated by the methods disclosed herein or by the apparatuses disclosed herein.

[0052] In yet a further aspect disclosed is a battery passport including a decentral identifier and passport data associated with the battery, wherein the battery passport is associated with a data completeness metric as generated by the methods disclosed herein or by the apparatuses disclosed herein.

[0053] In yet a further aspect disclosed is a use of the data completeness metric as generated by the methods disclosed herein or by the apparatus disclosed herein for generating and / or updating battery passports associated with batteries produced from one or more input material(s).

[0054] In yet a further aspect disclosed is a use of the battery passport as generated and / or updated for a battery by the methods disclosed herein or by the apparatuses disclosed herein to further process the battery associated with the battery passport. 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.

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

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

[0057] EMBODIMENTS

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

[0059] To enable efficient further processing and / or recycling of batteries, battery passports associated with such batteries may be provided. Such battery passports may be generated and / or updated by gathering data associated with the production of the battery from multiple participants of the production chain associated with the production of the battery. However, the completeness and accuracy of such gathered data needs to be ensured since a low degree of completeness and accuracy negatively impacts the further processing and / or recycling of such batteries based on incomplete and / or inaccurate data contained in battery passports generated from such gathered data and / or updated using such gathered data.

[0060] By validating the completeness of the data accessible for generating and / or updating battery passports associated with batteries, the degree of completeness of passport data included in the battery passports and hence the reliability of such passport data can be made transparent to battery passport generators and / or to battery passport users. Determining the degree of completeness based on data associated with the data sources allows to efficiently provide transparency on the degree of available data for generating and / or updating battery passports without having to gather any data associated with the production of the battery via a decentral network. Hence, the degree of completeness may be efficiently determined without involving data traffic via the decentral network, hence reducing the overall data transfer rates and improving the stability of the decentral network. Determining the degree of completeness based on validated data allows a more granular transparency on the completeness of the data available for passport generation and / or updating of existing battery passports. This transparency allows to generate or update battery passports based on a given or predefined degree of completeness, hence ensuring that the passport data included in the battery passports has a sufficient degree of completeness and thereof a sufficient degree of reliability. This way, it can be ensured that passport data required to ensure efficient further processing of the battery, such as efficient recycling of an end-of-life battery or a component thereof, is included in the generated and / or updated battery passports. Efficient further processing may enable a reduced environmental impact of the battery ecosystem and / or a higher circularity of materials and products used within the battery ecosystem. The transparency further allows to identify participants of the production chain of the battery not yet having generated and / or provided access to data to be included in the battery passports according to the data model associated with the battery passports. This way, participants can be requested to generate and / or provide access to such data to ensure a high degree of completeness of the generated and / or updated battery passports.

[0061] By generating and providing requests indicating missing data to participants of the production chain, missing data can be requested without requiring full transparency on the production chain. Instead, only transparency on at least a part of the participant(s) of the production chain is required via input material identifier(s) associated with input material data provided by such participants without having to know each individual participant of the production chain and the identity of the participants of the production chain. This ensures that missing data can be requested in a reliable manner without requiring full knowledge of the production chain, hence avoiding privacy concerns of data providers which may result in lack of data provision by such data providers due to privacy concerns.

[0062] By generating a battery passport based on a given or defined degree of completeness of the data required for the generation (e.g. the data defined by a data model used for the generation of the battery passport), it can be ensured that the data included in the battery passport fulfils a certain degree of completeness. This allows to generate and provide battery passports containing at least the data required for efficient further processing and / or recycling of the battery and avoids provision of battery passports containing no data or less data than required for further processing and / or recycling.

[0063] By generating and providing a data completeness metric indicating the degree of completeness of the passport data with respect to the data defined by the data model used for its generation, a stream of batteries associated with the battery passports to a downstream production using the batteries to produce one or more further product(s) can be monitored and / or controlled based on the data completeness metric associated with the battery passports. The stream of batteries may be controlled and / or monitored by validating the battery passports based on the associated data completeness metric. Validation may include comparing the data completeness metric associated with the battery passports with target data completeness metrics. Based on validated battery passports, the batteries associated with the validated battery passports may be provided to the downstream production for producing the further product(s). Based on non-validation of the battery passports, the batteries associated with the non-validated battery passports may be rejected, e.g. may not be provided to the downstream production. This way, a more efficient and reliable production of the further products based on data included in the battery passports can be ensured.

[0064] By updating the battery passport, data accessible for updating and being provided after generation of the battery passport may be included in such battery passport. This allows to “fill up” the passport data after generation of the battery passport when data providers, such as input material producer(s), start to provide data for such battery passport.. Based on the data completeness metric, a stream of batteries associated with battery passports to a downstream production using the batteries to produce one or more further product(s) can be monitored and / or controlled. This way, a more efficient and reliable production of the further products based on data included in the battery passports may be ensured. In addition, the degree of updating and the progress of data provision can be made transparent, for example to the entity generating the battery passport. This allows the entity generating the battery passport to request provision of missing data to achieve a higher quality and reliability of the passport data.

[0065] The methods or any step of the methods may for instance be performed, carried-out, executed and / or controlled by an / the computing apparatus, for instance a server, a server cloud, a computer-system, or a part thereof. The computing apparatus may be included in a local compute and storage environment associated with a participant of the production chain. The computing apparatus may be included in a local compute and storage environment associated with an entity generating the battery passport.

[0066] 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.”

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

[0068] Data accessible for generation and / or updating of the battery passport may include data being accessible at one or more data source(s) and including at least one data point defined by the data model associated with the battery passport. The data accessible for generation and / or updating may be gathered from such data sources upon generation and / or updating of the battery passport. The data accessible for generation and / or updating may be stored in dedicated storage(s) associated with the data source(s). The data accessible for generation and / or updating may be provided under control of the data owner of such data. The data owner may be input material producer(s) producing input material(s) used to produce the battery and / or the battery producer producing the battery. This may allow to exchange such data in a secure yet reliable manner for the generation and / or updating of the battery passports.

[0069] The battery passport may be a data set having a defined semantic structure. The battery passport may be a data set organized in a data format based on a defined semantic structure. The battery passport may be a single data set. The product battery may not be a database containing multiple data sets. The semantic structure may be defined by a data model associated with the battery passport. The data model may define one or more data points included in the battery passport. The data model may define such data points as mandatory data points or as optional data points. The data model may define a semantic description of the respective battery passport. The semantic description may include the structure of at least a portion of the battery passport, and / or properties of the battery passport. The properties of the battery passport may include data types. The properties of the battery passport may include possible or allowable values and / or value ranges. The properties of the battery passport may be a physical unit of parameter(s) described by values contained in the battery passport. The properties of the battery passport set may include one or more attribute(s). The data model may define data points, such as data types and values and / or value ranges, to be included in the battery passport.

[0070] The battery passport may include at least one decentral identifier and passport data. The decentral identifier may comprise any unique identifier uniquely associated with the battery. The decentral identifier may include one or more Universally Unique Identifier(s) (UUID) or a Digital Identifier(s) (DID). The decentral identifier may be issued by a central or decentral identity issuer. The decentral identifier may include authentication information. Via the decentral identifier and its unique association with the battery access to passport data may be controlled by the data owner of the passport data, such as the battery producer, the entity generating the battery passport including the passport data or the entity on behalf of which the battery passport including the passport data is generated. This contrasts with central authority schemes, where identifiers are provided by such central authority and access to data is controlled by such central authority. Decentral in this context refers to the usage of the decentral identifier(s) as controlled by the data owner of the passport data.

[0071] The passport data may include data points defined by the data model used to generate the respective battery passport. The passport data may include data associated with the production of the battery and battery identifier(s) associated with the battery. This way, the battery passport may be uniquely linked to the battery.

[0072] The battery passport may include one or more authentication mechanisms associated with the decentral identifier(s) and the passport data. The battery 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 passport data is granted. The battery passport and / or the decentral identifier(s) may be associated with one or more digital representations of the passport data. The digital representations may be regarded as access element(s) providing access to the battery passport or parts thereof. The digital representation may include decentral identifier(s) and access data. The decentral identifier(s) included in the digital representation may correspond to or be associated with the decentral identifier(s) included in the battery passport. The access data may include a locator or pointer, such as am url or uri, to a dedicated storage, such as a dedicated storage address, associated with the data owner of the battery passport. The pointer or locator may point directly to the dedicated storage storing the battery passport. The pointer or locator may point to a data providing network node associated with the dedicated storage storing the battery passport. 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. 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 battery ecosystem. The decentral registry may be associated with the data owner of the chemical battery passport. The decentral registry may be part of the decentral network but may not be associated with a particular participant of the production chain, e.g. may be regarded as infrastructure node of the decentral network. Updating the battery passport may include modifying the passport data included in such battery passport. The passport data may be modified by adding data point(s), deleting data point(s) and / or modifying data point(s) present within the passport data. The passport data may be modified by adding, deleting and / or modifying value(s) and / or value range(s).

[0073] The data model associated with the battery passport may be a data model used to generate and / or update the battery passport. The data model may be associated with a battery type identifier. The battery type identifier may be associated with a battery type the battery is associated with. Based on the battery type identifier the battery is associated with, such data model as well as data related to such data model may be gathered, for example from database(s) storing such data. A mapping table may be used to determine the battery type identifier of the battery type the battery is associated with. The mapping table may include battery identifier(s) interrelated with a respective battery type identifier of the battery type the battery is associate with. The battery type identifier may be determined based on data included in the battery identifier(s). For instance, the battery identifier(s) may include a battery type or a battery name indicating the battery type.

[0074] The production chain used to produce the battery may include one or more production step(s). At least some production step(s) of the production chain may be performed by different participants of a battery ecosystem. The battery ecosystem may be associated with the production, use and / or recycling of the battery. One or more input material(s) may be used to produce one or more intermediate product(s) or the battery in a production step. The input material(s) used within a production step may correspond to intermediate product(s) produced by an upstream participant of the participant performing said production step.

[0075] Input material may refer to any good which is bought from suppliers and brought to a production plant of a participant of the production chain. The input material may include starting material used in the production process of the production plant to produce the battery. The input material may include starting material used in the production chain to produce the battery. An input material can be used in any production step of the production chain used to produce the battery. This means, the product of the one production step can be used as input material of the subsequent production step. Input material may include recycled material. The input material may comprise or be any input material entering a production associated with a production step of the production chain. The input material may comprise or be any input material provided at any entry point of the production associated with a production step of the production chain.

[0076] The battery may be produced from one or more different input material(s). The input material(s) may be component(s) and / or chemical product(s). The component may be a discrete component. The component may be an electrode, a battery cell, a battery module, a battery management system, a cooling system, a housing, a separator or a mechanical subsystem. The component may be used in at least one of the production steps associated with the production of the battery. The component may be produced from one or more chemical product(s). The battery may be produced via one or more production steps. The production 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 battery may be used as input material to produce one or more further product(s), such as end products. The battery / batteries may be produced by one or more downstream participants which may use material(s) produced by one or more upstream participants as input material(s). The battery may be associated with a battery identifier(s). The battery identifier(s) may be digital or virtual battery identifier(s). The battery identifier may uniquely identify the battery within the entity producing the battery. The battery identifier may uniquely identify the battery within the decentral network. The battery identifier may be associated with an identifier element physically connected to the battery. The identifier element may encode the digital battery identifier. The battery identifier may include a battery name, a battery number, a LOT number, a batch number, a serial number, an identification number or the like.

[0077] The data completeness metrics may indicate the degree of correlation between the data associated with the data sources (e.g. data indicating the amount of data accessible for the generating and / or updating the battery passport) and the data related to the data model associated with the respective battery passport (e.g. data indicating the amount of data defined by the data model). The data completeness metrics may indicate the degree of correlation between the validated data (e.g. the amount of data accessible for generating and / or updating the battery passport) and the data related to the data model associated with the respective battery passport. A high degree of correlation may indicate a high amount of data being accessible for generating and / or updating the battery passport and hence a high degree of completeness of the passport data contained in the generated and / or updated battery passport while a low degree of correlation may indicate a low amount of data being accessible for generating and / or updating the battery passport and hence a low degree of completeness of the passport data. The data completeness metrics may hence indicate the reliability of the passport data included in the battery passport and may allow battery passport users or consumers to judge the quality or reliability of the passport data from the associated data completeness metric. The data completeness metric may indicate a total degree of completeness (e.g. a fraction of the amount of data available for generating and / or updating the battery passport compared to the amount of data defined by the data model associated with such battery passport). The data completeness metric may indicate a degree of completeness per participant required to provide data according to the data model and optionally a total degree of completeness.

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

[0079] The participants of the battery ecosystem may be connected via a decentral network. The decentral network may include one or more decentral network node(s) configured to perform data transactions. At least a part of the decentral network node(s) may be associated with participant(s) of the battery ecosystem. The data transactions may be based on a transaction protocol including authentication and / or authorization mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer network between decentral network node(s) of the decentral network may be established. The one or more authentication mechanism(s) may be associated with or linked to decentral identifier(s), such as decentral identifier(s) included in the battery passports and / or decentral identifier(s) included in digital representations associated with such battery passports. 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 data associated with the respective decentral identifier.

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

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

[0082] A rule-based engine may be used to validate at least part of the data associated with the production of the battery 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 data associated with the production of the battery. The rule-based engine used to validate at least part of the gathered data associated with the production of the battery may include one or more rule(s) related to a data model associated with the battery passport. The one or more rule(s) may be associated with or relate to one or more data point(s) defined by the data model. Hence, the one or more rule(s) may allow to determine whether the gathered data includes one or more data point(s) defined according to the data model. The one or more rule(s) may be associated with data point(s) defined as mandatory according to the data model. The one or more rule(s) may be generated based on the mandatory data points defined by the data model. This allows to validate whether data point(s) required by the data model is / are included in the gathered data, hence ensuring reliable generation of the data completeness metric based on such validated data. The rule-based engine may operate on individual data point level, combination of data points or the whole gathered 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 data. Use of such rule(s) allows to validate whether data point(s) required by the data model associated with the battery passport are contained in the gathered 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 validate whether combination(s) of data point(s) required by the data model associated with the battery passport are contained within the gathered data.

[0083] A rule-based engine may be used to validate the generated data completeness metric. The rule-based engine may be a software or software component that applies one or more rules to the generated data completeness metric. The rule-based engine used to validate the generated data completeness metric may include one or more rule(s) related given completeness threshold(s). The one or more rule(s) may be associated with or relate to a total degree of completeness. Hence, the one or more rule(s) may allow to determine whether the generated data completeness metric fulfils a given or predefined total degree of completeness. The one or more rule(s) may be associated with or relate to a degree of completeness per participant of the production chain required to provide data associated with the production according to the data model associated with the battery passport. This allows to validate whether the degree of completeness of the amount of data provided by a given participant fulfils given or predefine completeness thresholds. This way, the relevance of data provided by different participants may be considered during validation of the generated data completeness metric. The rule-based engine may operate on individual data point level, combination of data points or the whole data completeness metric. 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 generated data completeness metric. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points.

[0084] A rule-based engine may be used to validate the data associated with data sources or the validated data. The rule-based engine may be a software or software component that applies one or more rules to the data associated with data sources or the validated data. The rule-based engine used to validate the data associated with data sources or the validated data may include one or more rule(s) configured to validate the data associated with data sources or the validate data based on data related to the data model associated with the battery passport. The one or more rule(s) may relate to input material producer(s) producing input material(s) associated with input material data defined by the data model. The one or more rule(s) may relate to data point(s) defined by the data model. The one or more rule(s) may relate to data point(s) associated with at least a part of the input material(s) and the battery as defined by the data model. The one or more rule(s) may relate to data point(s) to be provided per input material producer and / or battery producer according to the data model. The rulebased engine may operate on individual data point level, combination of data points or the whole 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 data. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points.. The rule-based engine may operate on individual data point level, combination of data points or the whole data completeness metric. The operation of the rulebased 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 generated data completeness metric. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points.

[0085] In an embodiment the amount of data accessible for generating and / or updating the battery passport includes input material data associated with at least a part of the input material(s) used to produce the battery and / or battery data associated with the battery. The input material data may include at least one measured chemical and / or physical property of the respective input material and / or at least one chemical and / or physical property determined from data collected during production and / or use of the respective input material. The battery data may include at least one measured chemical and / or physical property of the battery and / or at least one chemical and / or physical property determined from data collected during production and / or use of the battery. 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, bio-based content, renewable content, carbon footprint, 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, luminescence, 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.

[0086] In an embodiment the data associated with the battery further includes a battery type associated with the battery and optionally input material identifier(s) associated with at least a part of the input material(s). The battery type may define the category or classification the battery falls under based on the property / ies of the battery, the purpose of the battery and / or the usage of the battery. The battery type may allow to categorize or group defined physical entities of batteries into battery types, hence allowing to reduce the dimensionality and avoiding multiplication of data for each individual battery.

[0087] In an embodiment the data associated with data sources includes data set identifiers associated with data sets including data associated with the production of the battery and data sources data indicating the data sources associated with such data set identifiers. The data sets may include input material data associated with input material(s) used to produce the battery and / or battery data associated with the battery. The data set identifier(s) may be stored in a storage associated with a system performing the validation of the amount of data accessible for generating and / or updating the battery passport. The data set identifier(s) may be stored within registry / ies of a decentral network. The registry / ies may be associated with provider node(s) configured to provide such data sets. The data sources associated with such data set identifier(s) may provide data set(s) associated with such data set identifier(s) upon request from a data consuming node. Data source data may include endpoints associated with such data sources. Data source data may further include a decentral participant identifier related to the data source and / or a participant role associated with the participant of the battery ecosystem being associated with or controlling the data source. Data sources may include network node(s) configured to provide data, such as data accessible for generating and / or updating the battery passports, upon request of a further network node (e.g. a consumer node). The data sources may be associated with a dedicated storage storing the provided data. The data sources may be configured to exchange data based on a transaction protocol including authentication and / or authorization mechanism(s) as previously described. Based on the authentication and / or authorization mechanism(s) a peer-to-peer network between a data sources and a consumer node may be established. The data source(s) may be configured to provide data based on an identifier associated with such data (e.g. the data set identifier). The data source(s) may be decentral network providing node(s). The data source(s) may be associated with input material producer(s) producing the input material(s) and / or with the battery producer producing the battery.

[0088] The data associated with data sources may not contain data set(s) associated with the data set identifier(s) included in such data associated with data sources. Hence the database storing such data may not be regarded as a central repository of data set(s). Instead, the control over access to the data set(s) is retained by the respective data owners of such data sets, while such database only allows to locate data set(s) and to request access to such data set(s) for generating and / or updating the battery passport.

[0089] The data associated with data sources may further include relationship representation(s) specifying relationship(s) between a given data set identifier (e.g. parent identifier) and further data set identifier(s) (e.g. child identifier(s)) associated with data set(s) of input material(s) used to produce the intermediate battery or battery the given data set identifier (e.g. parent identifier) is associated with. Such relationship representation(s) may allow to resolve the production chain and to determine the data set identifier(s) associated with input material(s) used to produce a given battery based on the data set identifier associated with such battery. Hence, the number of child identifier(s) associated with data being accessible for generating and / or updating the battery passport may be determined using such relationship representation(s) based on a given battery identifier, such as a data set identifier associated with a battery data set.

[0090] In an embodiment the data related to the data model includes participant role(s) of participants of the production chain producing the battery and a number of data points to be provided by such participant role(s) according to the data model. The data related to the data model may further include a digital battery identifier, such as a battery type identifier. This way, the data related to the data model may be linked to a battery or a battery type. Participants associated with the production of the battery may include participants performing at least one production step of the production chain used to produce the battery. The number of data points to be provided by such participant role(s) according to the data model may be determined by assigning a participant role to at least a part of the data points defined by the data model and accumulating the data points per assigned participant role. The data points defined by the data model may be assigned to participant role(s) based on properties of the intermediate battery or battery produced by such participant role. For instance, data points defining the battery properties within the data model may be assigned to the participant role “battery producer”. Likewise, data points defining the properties of cathode active material contained within the electrode of the battery may be assigned to the participant role “cathode active material (CAM) producer”.

[0091] In an embodiment providing the data related to the data model may include providing one or more rule(s) (also denoted as validation rule(s) in this disclosure) including such data associated with the data model. In an embodiment data associated with the production of the battery includes input material data associated with input material(s) used to produce the battery and / or battery data associated with the battery. Input material data may be present in the form of input material data set(s) associated with respective input materials. Likewise, the battery data may be present in the form of a battery data set.

[0092] In an embodiment the decentral data providing node(s) are determined from data associated with data sources indicating data accessible for generating and / or updating the battery passports by determining data set identifier(s) associated with input material(s) used to produce the battery based on at least one of the battery identifier(s) using relationship representation(s) included in the data associated with the data sources. The relationship representation(s) may define a parent identifier and associated child identifier(s). Based on such relationship representation(s), the relationship between a given battery identifier and all child identifier(s) associated with such battery identifier may be resolved.

[0093] In an embodiment the gathered data associated with the production of the battery is provided to one or more input node(s) configured to gather the data and to provide the gathered data as 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 data set(s) provided by the one or more input node(s). Validation may be performed using a rule-based engine including one more rule(s) associated with or related to data associated with the data model associated with the battery passport. The one or more downstream node(s) may further be configured to link the validated data to at least one of the battery identifiers, determine storage location(s) for the validated data and to provide the validated data linked to battery 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 gathered data. The generated data packages may be sent downstream from the input node(s) 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.

[0094] In an embodiment the rule-based engine operates on individual data points present within at least part of the gathered data or data sets, multiple data points present within at least part of the gathered data or data sets or the whole data set. The rule-based engine may be configured to validate data based on one or more rule(s) included in the rule-based engine. 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 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 data passed the one or more applied rule(s). Validating the data on data point level may allow to determine the number of data point(s) defined by the data model associated with the battery passport which are included in the gathered data.

[0095] In an embodiment 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 gathered 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 the data model associated with the battery.

[0096] In an embodiment the one or more rule(s) define data point(s) and / or combination(s) of data point(s) to be present within the gathered data. This may allow to determine the number of data point(s) defined by the data model which are included in the gathered data, hence allowing to determine the completeness of the gathered data by comparing the determined number of data points to a target number of data points defined by the data model. The one or more rule(s) may define data point(s) and / or combination(s) of data point(s) based on data defined by the data model. Hence the one or more rule(s) may be generated based on the data model associated with the battery passport.

[0097] In an embodiment the one or more rule(s) are associated with or derived from the data model associated with the battery passport, in particular wherein the one or more rule(s) are associated with data point(s) defined as mandatory by the data model.

[0098] In an embodiment validating the gathered data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered 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 identifier included in the gathered data. The applicable rule(s) may be included in a rule template. Hence validating the gathered 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 identifier included in the gathered 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 data set identifier(s) and optionally type identifier(s).

[0099] In an embodiment the gathered data is validated responsive to fulfilment of one or more rule(s) applied to the gathered data by the rule-based engine. This may ensure that the gathered 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 allow to reliably determine the number of data point(s) being accessible for generating and / or updating the battery passport and to generate the data completeness metric indicating a degree of completeness of the validated data with respect to the data defined by the data model.

[0100] In an embodiment the degree of correlation is determined by a further rule based-engine including one or more validation rules configured to validate a completeness of the data accessible for generating and / or updating the battery passport based on the data related to the data model associated with the battery passport. In another embodiment the degree of correlation is determined by the rule based-engine, wherein the rule-based engine further includes one or more validation rules configured to validate a completeness of the data accessible for generating and / or updating the battery passport based on the data related to the data model associated with the battery passport. The further rule-based engine or the rule-based engine may operate on individual data point(s) included in the validated data, combination of data point(s) included in the validated data or the validated data.

[0101] In an embodiment the degree of correlation is determined by

[0102] • determining - based on the digital battery identifier and the data associated with the data sources - data sources data indicating data sources providing data sets associated with the digital battery identifier,

[0103] • determining - based on the digital battery identifier and the data associated with the data sources - input material identifier(s) and associated data sources data indicating data sources providing data sets associated with the input material identifier(s),

[0104] • mapping the determined data source data indicating data sources providing data sets associated with the input material identifier(s) to the data related to the data model associated with the battery passport.

[0105] Mapping the determined data source data to the data related to the data model associated with the battery may include mapping the participant role(s) included in the determined data source data to participant role(s) included in the data associated with the data model. The degree of matching participant role(s) may signify the degree of correlation. Hence, a higher degree of matching participant role(s) may indicate a higher degree of correlation and hence a higher degree of completeness of the amount of data accessible for generating and / or updating the battery passport as compared to a lower degree of matching participant role(s). The degree of correlation may correspond to the fraction of matching participant role(s) with respect to the total number of participant role(s) included int the data associated with the data model. Determining the degree of correlation based on participant role(s) allows an efficient determination of the completeness of the amount of data accessible for generating and / or updating the battery passport without accessing such data.

[0106] In an embodiment the degree of correlation is determined by comparing the number of validated data points with a number of data points included in the data related to the data model associated with the battery passport. Comparing the number of validated data points with a number of data points included in the data related to the data model may include

[0107] • determining the participant role(s) associated with the validated data points based on data associated with data sources,

[0108] • mapping the determined participant role(s) and associated number of validated data point(s) to participant role(s) and associated number of data points included in the data related to the data model.

[0109] The participant role(s) associated with the validated data points may be determined using data set identifier(s) associated with the validated data points. For instance, data set identifier(s) associated with the validated data point(s) may be compared to data set identifiers included in the data associated with data sources. The validation allows to determine the amount of accessible data points that are matching data points defined in the data model. Determining the degree of correlation based on the number of validated data points allows a more accurate determination of the completeness of the data accessible for generating and / or updating the battery passport since the data points have been validated against the data model associated with the battery passport. In an embodiment the data completeness metric includes the digital battery identifier(s) and a total degree of completeness of the data being accessible for generating and / or updating the battery passport. The total degree of completeness may correspond to the fraction of the amount of data accessible for generating and / or updating the battery passport compared to the amount of data defined by the data model. The total degree of completeness may be given in percent based on the total amount of data defined by the data model. Hence, a degree of completeness of 100% indicates that all data defined by the data model is accessible for generating and / or updating the battery passport while a degree of 0% indicates that no data defined by the data model is accessible for generating and / or updating the battery passport.

[0110] In another embodiment the data completeness metric includes the digital battery identifier(s), input material identifier(s) associated with input material(s) used to produce the battery, participant role(s) associated with the input material identifier(s) and / or the battery identifier(s), and the degree of completeness of the data being accessible for generating and / or updating the battery passport for at least a part of the input material identifier(s) and / or the digital battery identifier(s). The degree of completeness per digital battery identifier(s) may correspond to the total degree of completeness as previously described. The degree of completeness for a given input material identifier may correspond to the degree of completeness of the data set associated with such input material identifier. The degree of completeness of the data set may be determined based on the participant role defined for the data set (e.g. by comparing the participant role defined for the accessible data set with the participant role(s) defined by the data model). The degree of completeness of the data set may be determined based on the number of validated data points included in such data set (e.g. by comparing the number of validated data points for a participant role associated with such validated data points to the number of data points defined by the data mode for such participant role). The degree of completeness per input material identifier allows to identify participant role(s) associated with missing data, e.g. participant(s) of the production chain not yet having provided data for access. Based on such data, a request to provide missing data may be generated and provided. Since only participant role(s) are provided by the data completeness metric to ensure sufficient privacy with respect to the production chain participant(s), the request to provide missing data cannot be directly provided to the participant(s) not yet having provided data for access. Instead, the request may be provided to the participant(s) associated with upstream participants not yet having provided data for access. The participant(s) associated with the upstream participant(s) may be identified using the data completeness metric by determining the participant(s) providing data set(s) associated with child identifier(s) for which no data accessible for generating and / or updating of the battery passport has been provided. Since such participant has information on its upstream participant(s), such participant may forward the request to such upstream participant(s).

[0111] In an embodiment the data completeness metric further includes the number of accessible data point(s) for at least a part of the input material identifier(s) and / or the digital battery identifier(s), the number of data points per input material identifier and digital battery identifier as defined by the data model and optionally the total degree of completeness of the data being accessible for generating and / or updating the battery passport. This may allow to provide a more granular transparency on the amount of data accessible for generating and / or updating the battery passport. In addition, this allows to determine missing data and to request such missing data as previously described.

[0112] In an embodiment the given completeness threshold(s) define one or more degree(s) of correlation between the data being accessible for generating the battery passport and data points defined by a data model associated with the battery passport. The degree of correlation may be defined for the total degree of correlation between the data being accessible for generating the battery passport and the data points defined by the data model associated with the battery passport. The degree of correlation may be defined for data point(s) to be provided by one or more participants of the production chain producing the battery according to the data model. The degree of correlation may be defined for at least a part of the participants of the production chain producing the battery and required to provide data according to the data model associated with the battery passport. This may allow to define different degrees of correlation for different participants of the production chain. This way, a differentiation with respect to a relevance of data points provided by different production chain participants for generating and / or updating the battery passport may be mirrored in the threshold(s). Hence, data points being relevant for downstream participants of the battery producer using the battery to produce further products, such as data points being relevant for treatment and / or handling of end-of-life (EoL) batteries, e.g. sorting and / or collecting and / or recycling EoL batteries or components thereof, may be associated with a higher threshold concerning the degree of correlation than data point(s) being of less relevance for such downstream participants.

[0113] In an embodiment validation includes acceptance of the degree of correlation indicated by the determined data completeness metric. Acceptance of a degree of correlation may indicate that a sufficient amount of data is accessible for generating the battery passport such that the battery passport generated from such accessible data is sufficiently accurate to control further processing of the battery based on passport data included in such generated battery passport.

[0114] In an embodiment validation includes rejection of the degree of correlation indicated by the determined data completeness metric and triggering of a request to provide at least a part of the data missing according to the generated data completeness metric. Rejection of the degree of correlation may indicate that the amount of data accessible for the generation of the battery passport is not sufficient and a battery passport generated from such accessible data may not be considered reliable.

[0115] In an embodiment generating the battery passport includes providing a decentral identifier associated with the gathered data and a data model associated with the battery passport, applying the data model to the gathered data to generate passport data and generating the battery passport including the decentral identifier and the passport data. The generated battery passport may be stored on a dedicated storage associated with or under control by the data owner of the battery passport. The generated battery passport may be associated with a digital representation pointing to the storage location storing the battery passport. The digital representation may be stored in a decentral registry of a decentral network associated with or under control by the data owner of the battery passport. This enables further participants of decentral network authorized to query the decentral registry to gather the digital representation and to access the battery passport based on such digital representation.

[0116] In an embodiment the battery passport and optionally the generated data completeness metric is provided for access under control of the data owner of the battery passport and associated data completeness metric. The data owner may include an entity generating and / or updating the battery passport. The data owner may include an entity on behalf of which the battery passport is generated and / or updated. The data owner may be the battery producer. The data owner may be the battery user, e.g. an entity using the battery to produce further products. For example the data owner may be the end product producer using the battery to produce the end product. The battery passport may be stored in a data base of or associated with the data owner. The battery passport may be stored in a data base of or under control by the data owner. The battery passport may be stored in a data base accessible by the data owner. The battery passport may be associated with the data owner. The data owner may be the owner of the battery passport or the battery passport data owner. In this sense, the data owner is to be construed broadly as the entity having access to the battery passport controlling access by decentral data consuming network nodes of the decentral network to the battery passport or parts thereof. Access to the digital twin or parts thereof may hence be under control of the data owner. This allows to retain full control over the battery passport by the data owner but at the same time enabling sharing of the battery passport or parts thereof under controlled conditions, for example by using appropriate authorization and authentication mechanisms or schemes.

[0117] Providing the battery passport under control of the data owner may include gathering access policy data associated with the battery passport based on a request to access the battery passport from a data consumer and applying the access policy data to the battery passport based on the data included in the received request. The request may include a consumer identifier. The request may further include one or more actions to be performed on data point(s) included in the battery passport, such as read action(s).

[0118] The access policy data may be generated by

[0119] • generating group access data associated with the battery passport, the group access data identifying access control groups including data consumer identifier(s) associated with data consumer(s) permitted to access at the battery passport,

[0120] • generating consumer access data associated with one or more data point(s) present within the battery passport based on the generated group access data, the consumer access data identifying the data consumer(s) permitted to access the one or more data point(s) and one or more actions allowed to be performed on the one or more data point(s) by data consumer(s) associated with the data consumer identifier(s),

[0121] • generating access policy data associated with the battery passport based on the generated group access data and the generated consumer access data, the access policy data identifying the group access data and the associated consumer access data.

[0122] The access policy data may be generated by

[0123] • generating group access data associated with the battery passport, the group access data identifying access control groups including data consumer identifier(s) associated with data consumer(s) permitted to access at the battery passport,

[0124] • generating consumer access data associated with the battery passport based on the generated group access data, the consumer access data identifying one or more actions allowed to be performed on the passport data by data consumer(s) associated with the data consumer identifier(s),

[0125] • generating access policy data associated with the battery passport based on the generated group access data and the generated consumer access data, the access policy data identifying the group access data and the associated consumer access data.

[0126] The group access data includes a gathering of one or more data consumer identifier(s) associated with the data consumer(s) permitted to access the battery passport.

[0127] Applying the access policy data to the battery passport may include validating whether the data consumer is permitted to access the battery passport, responsive to validating access to the battery passport for the data consumer validating whether the data consumer is permitted to perform the requested action(s) on the battery passport.

[0128] The access policy data and / or the group access data may be linked to the battery passport, for example via the decentral identifier(s) and / or the battery identifier. This way, the access policy data and / or the group access data may be obtained based on one of the decentral identifier(s) and / or the battery identifier.

[0129] Validating whether the data consumer is permitted to perform the requested action(s) on the battery passport may include

[0130] • obtaining access control list data associated with one or more data point(s) present within the battery passport,

[0131] • identifying one or more actions to be performed on the one or more data point(s) present within the battery passport based on data contained in the received request,

[0132] • determining whether the data consumer is permitted to perform the one or more actions requested to be performed on the one or more data point(s) by comparing access control list entries present within the access control list data with the data included in the received request, and, in response,

[0133] • performing the one or more actions requested to be performed on the one or more data point(s) or providing the battery passport according to the one or more requested actions to the data consumer.

[0134] By filtering data consumer(s) requesting access to the battery passport based on a group-based policy for accessing the battery passport, the battery passport can be securely exchanged and shared under the sovereignty of the data owner of the battery passport and unauthorized access to the battery passport can be avoided. This allows for controlled access to the battery passport or parts thereof by participants of the battery ecosystem, such as upstream participants of the battery producer, the passport generator or the entity on behalf of which the passport is generated. Moreover, access to the battery passport or a part thereof by multiple data consumers can be controlled by the data owner using the group-based policy and the decentral identifier(s) included in the battery passport. Use of a group-based access in combination with fine-grained access controls on data point level allows to avoid the generation of multiple copies of the battery passport customized to the access rights associated with each data consumer permitted to access the battery passport. Hence, the amount of data associated with the battery passport may be reduced since access may be controlled on data point level of the battery passport, making generation of multiple copies of the battery passport redundant.

[0135] The access policy data may identify access control group(s) including data consumer identifier(s) associated with data consumer(s) permitted to access at the battery passport. Applying the access policy data may include

[0136] • determining consumer identifier(s) based on user data contained in the received request,

[0137] • determine whether the determined consumer identifier(s) are permitted to access the battery data based on group access data identifying access control groups including data consumer identifier(s) associated with data consumer(s) permitted to access at the battery passport,

[0138] • if the determined consumer identifier(s) are permitted to access the battery data, determine usage data associated with validated data used to generate the battery passport, apply the determined usage data based on the determined consumer identifier(s) to the battery passport and provide the battery passport according to the applied usage data. In another example, applying the access policy data may include

[0139] • determining consumer identifier(s) based on user data contained in the received request,

[0140] • determine group access data associated with the battery passport and identifying consumer identifier(s) associated with data consumer(s) permitted to access at the battery passport,

[0141] • apply the determined group access data based on the determined consumer identifier(s) to the battery passport and provide the battery passport according to the applied group access data.

[0142] The consumer identifier(s) may be determined from data indicting relationships between consumer identifier(s) and user data. User data may include a username. Such relationships may indicate the user data associated with given consumer identifier(s). Such relationships may be stored within the data associated with data sources. This way, users can be related to data source data including consumer identifier(s).

[0143] Usage may include rule(s) and / or condition(s) associated with the usage of the input material data for passport generation and passport usage. Passport usage may include providing the generated battery passport to passport consumers. Usage rule(s) may include rule(s) restricting access to the input material data to defined data consumer(s). The rule(s) may restrict the access based on consumer identifier(s).

[0144] In an embodiment updating the battery passport includes generating a data set by applying a data model associated with the battery passport to the gathered data and updating the battery passport with the generated data set.

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

[0146] 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. The description of drawings is provided for illustrative purposes and shall not be considered limiting. The embodiments and examples are illustrative embodiments and examples to further line out the concepts lined out herein. The figures include schematic illustrations and shall not be considered limiting. Other embodiments and examples that fall under the concepts lined out herein are possible and may not be explicitly described herein.

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

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

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

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

[0151] FIG. 6 illustrates an example architecture of a system configured to validate completeness of data accessible for generating and / or updating a battery passport associated with a battery.

[0152] FIG. 7A illustrates an example block diagram of an asset generation system configured to generate data associated with the production of a battery and to provide the generated data for access within a decentral network.

[0153] FIG. 7B illustrates a diagram showing an example of a system configured to gather output product data and to transform at least part of the gathered output product data using a rule-based engine.

[0154] FIG. 8 illustrates an example of a system and associated methods for generating data associated with the production of a battery and to provide the generated data for access within a decentral network.

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

[0156] FIG. 10 illustrates an embodiment of the method illustrated in FIG. 9 in accordance with one embodiment.

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

[0158] FIG. 12 illustrates a decentral system for accessing data associated with produced output product(s).

[0159] FIG. 13 illustrates an example of a battery passport service configured to validate a completeness of data accessible for generating and / or updating a battery passport associated with a battery.

[0160] FIG. 14A illustrates an example of a data structure stored in a database of the battery passport service illustrated in FIG. 13.

[0161] FIG. 14B illustrates examples of relationship representations stored in the database of the battery passport service illustrated in FIG. 13.

[0162] FIG. 14C illustrates an example of a user interface for providing asset data and associated data source to the battery passport service illustrated in FIG. 13 for storage.

[0163] FIG. 15 illustrates an example of a data quality analyzer illustrated in FIG. 13.

[0164] FIG. 16 illustrates an example of a metrics generator illustrated in FIG. 15.

[0165] FIG. 17A illustrates a first example of a data completeness metric. FIG. 17B illustrates a further example of a data completeness metric.

[0166] FIG. 17C illustrates yet a further example of a data completeness metric.

[0167] FIG. 18 illustrates a flow chart of an example of a method for validating a completeness of data accessible for generating and / or updating a battery passport associated with a battery.

[0168] FIG. 19A illustrates a block diagram of an example system for verifying data associated with the production of a battery.

[0169] FIG. 19B illustrates a diagram showing an example of validating data associated with the production of a battery using a rule-based engine included in the data validation unit described in the context of FIG. 19A.

[0170] FIG. 20 illustrates a flow chart of a further example of a method for validating a completeness of data accessible for generating and / or updating a battery passport associated with a battery.

[0171] FIG. 21 illustrates an embodiment of the method illustrated in FIG. 20.

[0172] FIG. 22 illustrates a flow chart of an example method for verifying data associated with the production of the battery.

[0173] FIG. 23 illustrates a sequence diagram of an example method for verifying data associated with the production of the battery.

[0174] FIG. 24 illustrates a system for generating a battery passport associated with a battery.

[0175] FIG. 25 illustrates an example of a method for generating a battery passport associated with a battery.

[0176] FIG. 26 illustrates an example of a method for updating a battery passport associated with a battery.

[0177] DETAILED DESCRIPTION

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

[0179] The participant network 130 of the product ecosystem associated may be associated with a decentral peer-to-peer network 134 for exchange of data associated with raw material(s), chemical product(s), discrete product(s), end product(s), recycled material(s) and / or their respective production. The participant network 130 may include one or more network participants, such as decentral participants 102 to 114. The 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 product ecosystem illustrated in FIG. 1 is a mere example and may include more or less network participants. For example, the product ecosystem may include a chain of chemical product producers instead of only one chemical product producer 102. 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] The 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 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 network participant may be associated with a participant node 116 to 128 and a decentral participant identifier related to an associated participant node(s) 116 to 128. The decentral participant identifier may uniquely identify the decentral network participant and its associated decentral participant node within the decentral peer-to-peer network 134.

[0181] Participant(s) of the participant network 130 may be associated with or involved in the generation of battery passport(s) and / or the updating of existing battery passports. Battery passports may be generated and / or updated by an entity on behalf of participants of the product ecosystem, for example as described in the context of FIG. 24 to FIG. 27. Generation and / or updating of battery passports may include validation of completeness of data to be used for the generation and / or updating of a battery passport, for example as described in the context of FIG. 13 to FIG. 23. The generated battery passports may be provided for access via the decentral network 130. For instance, recycler 114 may access such battery passports to determine the composition of the end-of-life product, allowing adaption of the recycling process to the composition determined based on the accessed battery passports. The generated or updated battery passports may be provided under control of the data owner of the battery passport. The data owner of the battery passport may be the entity generating the battery passport. The data owner of the battery passport may be the entity on behalf of which the battery passport is generated. The data owner of the battery passport may be the product producer. The data owner of the battery passport may be an end product producer using the product to produce the end-product.

[0182] The participant(s) of the 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). 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. 12. 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. 12. The decentral configuration allows for more efficient use of computing resources and strengthens control by the data owners of the decentral network by allowing for data sovereignty.

[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. 12. 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 associated with further identifier(s), such as identifier(s) of production input(s) (e.g. input materials) used to produce the product (hereinafter denoted as child identifier(s)). This may allow to track the product input(s) used to produce a product, such as a chemical product, a component, a component assembly or 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. The child identifier(s) associated with the identifier may be provided, for example, as described in the context of FIG. 13 to FIG. 14C.

[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. 12.

[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. 12).

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

[0190] The participant network 226 may include one or more network participants, such as network participants 202, 204 and 214 to 224. 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 214, a refiner 216, a precursor cathode active material (PCAM) and cathode active material (CAM) producer 218, a battery producer 220, an end-product producer 202, an EOL product collector 204, a black mass producer 222 and a metal extractor 224. 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.

[0191] The participant(s) of the participant network 226 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 214, refiner 216, PCAM & CAM producer 218, battery producer 220, end-product producer 202 and / or a participant of a recycling chain associated with the end-of-life batteries or components thereof, such as EOL product collector 204, black mass producer 220 and metal extractor 224. For instance, the metal extractor 224 and the PCAM & CAM producer 218 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 network participant may be associated with a decentral participant identifier. The decentral participant identifier may uniquely identify the network participant within the participant network 226.

[0192] At least a part of the participant(s) of the participant network 226 may be associated with the generation of battery passport(s). Such 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 participants may gather input material data, for example as described in the context of FIG. 19A 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 134. For instance, black mass producer 222 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.

[0193] The participant(s) of the participant network 226 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 216 for refinement. The refined metals may be provided to PCAM & CAM producer 218 for the production of cathode active material. The CAM may be used, for example by battery producer 220, 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 202 to produce battery containing end products, such as electric vehicles. Scrape from battery production may be provided to black mass producer 222.

[0194] At least a part of the participants of the participant network 226 may be associated with decentral participant network nodes 228 to 242 as described in the context of FIG. 1. The decentral participant nodes 228 to 242 may form decentral network 134. The decentral network 134 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.

[0195] 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. 12. 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. 19A.

[0196] The data flow 206 (e.g. transactions) between network participant nodes may be directly or indirectly associated with the material flow 210, 212 between the network participants as described in the context of FIG. 1.

[0197] The decentral participant nodes 228 to 242 may be decentral computing nodes as described in the context of FIG. 1.

[0198] At least part of the decentral participant nodes 228 to 242 may be decentral data providing network nodes. At least part of the participant nodes 228 to 242 may be decentral data consuming network nodes. A participant of the decentral participant network 134 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).

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

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

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

[0202] 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 aluminium or copper foil. The CAM 342 may contain layered oxides (Li MO2 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 (UMPO4 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 N iSO4, 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).

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

[0204] 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 (LIPFe), 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.

[0205] With continued reference to FIG. 4, the separator 320, 420 may include microporous membranes, coated separators, nonwoven mats, solid inorganic or polymeric materials. Coated separators may include polyolefin-based membranes coated e.g., with PVDF or ceramics. The polyolefine-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.

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

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

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

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

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

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

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

[0213] 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 identification element 404, 406 may be configured to provide the decentral battery identifier for accessing battery data.

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

[0215] In particular, the decentral identifier may relate to material data specifying the material composition of one or more component(s) of the product. The decentral product 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.

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

[0217] 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 product(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.

[0218] FIG. 6 illustrates an example architecture of a system configured to validate completeness of data accessible for generating and / or updating a battery passport associated with a battery. The completeness of the data accessible for generating and / or updating the battery passport may be validated as described in the context of FIG. 13 to FIG. 23. The completeness may signify a degree of correlation between the accessible data and data defined by a data model associated with the battery passport. The higher the degree of correlation, the lower the deviation between the accessible data and the data defined by the data model and hence the higher the completeness of the accessible data and the passport data generated from such accessible data. The data may include data associated with the production of the battery from one or more input material(s). The data associated with the production may include input material data associated with at least a part of the input material(s) used to battery the battery and battery data associated with the battery. The system may further be configured to generate battery passports and / or to update existing battery passports, for example as described in the context of FIG. 24 to FIG. 26. Generation of battery passports may be based on the result of the validation of the completeness of the data accessible for generating the battery passport.

[0219] The battery may be produced from one or more input material(s) by a production step, for example as described in the context of FIG. 3A and FIG. 3B. The battery may be produced from the input material(s) via a production chain including one or more production step(s). At least some production step(s) of the production chain may be performed by different participants of the battery ecosystem. For instance and with reference to FIG. 2, the battery production chain may involve several production steps (e.g. mining of raw metals, refinery of raw metals, production of PCAM and CAM, production of battery cells and production of the battery). The production step(s) may be performed by different participants of the battery ecosystem, such as the participants shown in FIG. 2. The output product produced by one participant of the battery ecosystem may be used as input material by a downstream participant of the battery ecosystem. For instance and with reference to FIG. 2, the raw metals produced by miner 214 as output product may be used by the downstream participant, e.g. refiner 216, as input material to produce refined metals or metal products, such as metal salts. The battery passport may be a data set having a defined semantic structure. The defined semantic structure may be obtained by applying a semantic model, such as a data model, to data associated with the production of the battery. The data model may define a semantic description of the respective battery passport. The semantic description may include the structure of at least a portion of the battery passport, and / or properties of the battery passport. The properties of the battery passport may include data types. The properties of the battery passport may include possible or allowable values and / or value ranges. The properties of the battery passport may be a physical unit of parameter(s) described by values contained in the battery passport. The properties of the battery passport set may include one or more attribute(s). The data model may define data points, such as data types and values and / or value ranges, to be included in the battery passport.

[0220] The battery passport may include at least one decentral identifier and passport data. The decentral identifier may comprise any unique identifier uniquely associated with the battery. The decentral identifier may include one or more Universally Unique Identifier(s) (UUID) or a Digital Identifier(s) (DID). The decentral identifier may be issued by a central or decentral identity issuer. The decentral identifier may include authentication information. Via the decentral identifier and its unique association with the battery access to passport data may be controlled by the data owner of the passport data, such as the battery producer, the entity generating the battery passport including the passport data or the entity on behalf of which the battery passport including the passport data is generated. This contrasts with central authority schemes, where identifiers are provided by such central authority and access to data is controlled by such central authority. Decentral in this context refers to the usage of the decentral identifier(s) as controlled by the data owner of the passport data.

[0221] The passport data may include data points defined by the data model used to generate the respective battery passport. The passport data may include data associated with the production of the battery and battery identifier(s) associated with the battery. This way, the battery passport may be uniquely linked to the battery. Data associated with the production of the battery may include input material data associated with at least a part of the input material(s) used to produce the battery. Input material(s) used to produce the battery may include input material(s) used in one or more production step(s) of the production chain used to produce the battery. Data associated with the production of the battery may include battery data associated with the battery.

[0222] Input material data and / or battery data may include one or more chemical and / or physical property / ies associated with the input material or battery, respectively. The chemical and / or physical property / ies may include at least one measured chemical and / or physical property of the input material and / or at least one chemical and / or physical property determined from collected data associated with the production and / or the use of the input material. The chemical and / or physical property / ies may include at least one measured chemical and / or physical property of the battery and / or at least one chemical and / or physical property determined from collected data associated with the production and / or the use of the battery. The collected data may be used to determine the at least one physical and / or chemical property. 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 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. The battery passport may include one or more authentication mechanisms associated with the decentral identifier(s) and the passport data. The battery 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 passport data is granted. The battery passport and / or the decentral identifier(s) may be associated with one or more digital representations of the passport data. The digital representations may be regarded as access element(s) providing access to the battery passport or parts thereof. The digital representation may include decentral identifier(s) and access data. The decentral identifier(s) included in the digital representation may correspond to or be associated with the decentral identifier(s) included in the battery passport. The access data may include a locator or pointer, such as am url or uri, to a dedicated storage, such as a dedicated storage address, associated with the data owner of the battery passport. The pointer or locator may point directly to the dedicated storage storing the battery passport. The pointer or locator may point to a data providing network node associated with the dedicated storage storing the battery passport. 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. 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 chemical battery passport. The decentral registry may be part of the decentral network but may not be associated with a particular participant of the production chain, e.g. may be regarded as infrastructure node of the decentral network.

[0223] The architecture may connect participants of the battery ecosystem via a decentral network 134 to a battery passport service 628. The participants of the battery ecosystem may provide access to data for generating and / or updating battery passports, for example as described in the context of FIG. 19A to FIG. 26. The data may be provided via one or more decentral participant nodes, such as nodes 228 to 232. The data may be provided via an asset generation service, such as asset generation service 1 604 to asset generation service 3 636. The asset generation service may be configured to generate input material data or battery data and to provide such generated data for access via a decentral network 134 under control of the data owner of the input material data or battery data, such as the input material producer or the battery producer, respectively. The input material data or battery data may be generated by the asset generation service 1 604, the asset generation service 2 606 and / or the asset generation service 3 636 from data stored in databases associated with the respective participant, such as databases 612 to 622. The databases may store respective input material data or battery data and may be accessible by respective data providing nodes, such as nodes 228 to 232. Access to the database may be controlled by the data owner of the data stored in such data bases, for example via respective data providing nodes 228 to 232. The participants may use the asset generation service to provide input material data or battery data. Alternatively, participants may generate input material data or battery data without the use of such asset generation service.

[0224] The battery passport service 628 may be configured to store data associated with data sources providing data accessible for generating and / or the updating battery passports. Such data associated with data sources may relate to or be associated with provider nodes 228 to 232 providing data generating and / or updating battery passports associated with batteries, for example as described in the context of FIG. 13. The data associated with data sources may include endpoints of such data sources, such as endpoints of provider nodes 228 to 232, decentral participant identifier(s) related to the data sources, participant role(s) related to the data sources and identifiers of input material data or battery data provided by such data sources, for example as illustrated in FIG. 14A. Participant role(s) may indicate the role of a respective participant within the battery ecosystem. The data associated with data sources may hence indicate data accessible for generating and / or updating battery passports. The decentral participant identifier(s) may uniquely identify the respective participant within the decentral network, such as decentral network 134. The decentral participant identifier may include an identifier as described in the context of FIG. 12. The decentral participant identifier may be associated with a verifiable credential as described in the context of FIG. 12. The verifiable credential may include the decentral participant identifier. The verifiable credential may further include data indicating the role of the participant within the battery ecosystem.

[0225] The identifiers of the input material data and / or the battery data may be associated with respective child identifier(s) indicating input materials used to produce a given intermediate product or the product, for example as illustrated in FIG. 14B. Linking of identifiers allows to determine input materials used to produce a given battery based on the battery identifier associated with the battery, for example as illustrated in FIG. 14B. This way, it can be determined which participants have not provided data required for the battery passport according to data related to the data model associated with the respective battery passport.

[0226] The data associated with data sources may be provided by the participants of the decentral network, such as participants illustrated in FIG. 1 and FIG. 2. Data associated with data sources may be provided by participants as described in the context of FIG. 13 to FIG. 14C.

[0227] The battery passport service 628 may be configured to validate input material data or battery data gathered from data providing nodes according to the data associated with the data sources, for example as described in the context of FIG. 13 and FIG. 19A to FIG. 23. Validation ensures that data defined by the data model associated with such battery passport is included in the gathered data, hence allowing to reduce the complexity associated with the data set generation at the provider side by avoiding the use of complex data models during generation of such data set(s). This may enable reliable sharing of such data irrespective of the existence of data models for such intermediate products since the rule(s) required to transform the gathered data may be readily derived from the data model associated with the battery passport.

[0228] The battery passport service 628 may be configured to generate data completeness metrics based on the data associated with the data sources or the validated data (e.g. the validated input material data and the validated battery data), for example as described in the context of FIG. 13 and FIG. 15 to FIG. 23. The battery passport service 628 may be configured to provide the generated data completeness metrics. The data completeness metrics may indicate the degree of correlation between the data stored in the data associated with the data sources and the data related to the data model associated with the respective battery passport. The data completeness metrics may indicate the degree of correlation between the validated data and the data related to the data model associated with the respective battery passport. A high degree of correlation may indicate a high amount of data being accessible for generating and / or updating the battery passport while a low degree of correlation may indicate a low amount of data accessible for generating and / or updating the battery passport. The data completeness metric may hence indicate the reliability of the passport data included in the battery passport and may allow battery passport users or consumers to judge the quality or reliability of such passport data from the associated data completeness metric. In addition, the data completeness metric may be used by the entity generating the battery passport or by a third party on behalf of which the battery passport is generated to determine the amount of data accessible for generating and / or updating particular battery passports. This way, the data completeness metric may be used by such entity or third party to identify participants not yet having provided data defined by the data model associated with the battery passport and to request to provide such data for access. In addition, the data completeness metric may be used by such entity or third party to control generation of battery passports to ensure that the generated battery passports contain a minimum amount of passport data. This allows to ensure a high degree of completeness of battery passports and hence a high reliability of the passport data included therein, resulting in efficient further processing of batteries associated with such battery passports based on processing data generated using passport data included in such battery passports.

[0229] The battery passport service 628 may be configured to generate battery passports and / or to update existing battery passports based on input material data and battery data gathered from data providing nodes for example as described in the context of FIG. 24 to FIG. 26. The generated and / or updated battery passports may be persisted in an archive to allow retrieval of such battery passports without having to regenerate such battery passports. Alternatively, the generated battery passports may be provided to a user requesting such battery passport without persisting the generated battery passport. Battery passport service 628 may be configured to generate one or more digital representations of the passport data and to provide such representations to a decentral registry for access by data consuming nodes under control of a decentral node associated with the entity operating the battery passport service 628 or on behalf of which the battery passport service 628 is operated.

[0230] Use of participants of the battery ecosystem shall not be understood limiting with respect to the underlying concepts outlined in this figure. The concepts illustrated in FIG. 6 are likewise applicable to further battery ecosystems associated with other products than batteries and battery containing products.

[0231] By validating the completeness of the data accessible for generating and / or updating battery passports associated with batteries, the degree of completeness of passport data included in the battery passports and hence the reliability of such passport data can be made transparent to battery passport generators and / or to battery passport users. Determining the degree of completeness based on data associated with the data sources allows to efficiently provide transparency on the degree of available data for generating and / or updating battery passports without having to gather any data associated with the production of the battery via a decentral network. Hence, the degree of completeness may be efficiently determined without involving data traffic via the decentral network, hence reducing the overall data transfer rates and improving the stability of the decentral network. This transparency allows to generate or update battery passports based on a given or predefined degree of completeness, hence ensuring that the passport data included in the battery passports has a sufficient degree of completeness and thereof a sufficient degree of reliability. This way, it can be ensured that passport data required to ensure efficient further processing of the battery, such as efficient recycling of an end-of-life battery or a component thereof, is included in the generated and / or updated battery passports. Efficient further processing may enable a reduced environmental impact of the battery ecosystem and / or a higher circularity of materials and products used within the battery ecosystem. The transparency further allows to identify participants of the production chain of the battery not yet having generated and / or provided access to data to be included in the battery passports according to the data model associated with the battery passports. This way, participants can be requested to generate and / or provide access to such data to ensure a high degree of completeness of the generated and / or updated battery passports.

[0232] FIG. 7A illustrates a block diagram of an example of an asset generation system configured to generate data associated with the production of a battery and to provide the generated data for access within a decentral network. The battery may be a battery described in the context of FIG. 3A to FIG. 5. The decentral network may be a decentral network as described in the context of FIG. 1 and FIG. 2. The asset generation system may be configured to perform the methods illustrated in FIG. 9 and FIG. 10. The data associated with the production of the battery may include input material data associated with input material(s) used to produce the battery and / or battery data associated with the battery. At least a part of the input material(s) may include output products described in the context of FIG. 7A.

[0233] With reference to FIG. 8, the output product 806 may be produced using one or more input material(s) 802. The output product may comprise or be any product produced by the production 804 and provided at any exit point of the production 804. The output product may correspond to the battery. The output product may correspond to an intermediate product used to produce the battery. The input material may include starting material used in a production process performed within production 804 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 804 can correspond to the input material of a subsequent production plant of production 804. Input material may include recycled material. The input material may comprise or be any input material entering the production 804. The input material may comprise or be any input material provided at any entry point of the production 804.

[0234] The output product may be produced via one or more process steps from the input material(s) 802 within production 804. 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 802 may enter the system boundary 814 of the production 804 at the entry point, such as a production plant or a material storage associated with the production 804. The amount of input material entering the system boundary 814 of the production 804 may be measured, for example using sensor 808a. Sensors 808a may include sensors configured to measure an amount of input material, such as a weight and / or a volume, and / or sensor(s) configured to detect input material identifier(s) associated with the input material(s). The input material(s) may comprise a physical identifier element associated with the input material identifier(s). The identifier element may encode the input material identifier. The input material identifier may be a digital identifier. The data collected by the sensor(s) 808a may be stored in a database associated with the operation operating systems 816 of the production 804.

[0235] Chemical and / or physical properties of the input material may be measured, for example using sensor 808b, upon passing system boundary 814 of the production 804. 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, luminescence, 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.

[0236] An operating system 816 of the production 804 may monitor and / or control the production 804 based on operating parameters of the different processes. The operating system 816 may receive production demand data associated with the production planning for the production 804. The production demand data may be produced from target production capacities for one or more output product(s) produced by the production 804. The production demand data may be produced from predefined 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 804. The operating system 816 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.

[0237] 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 804. The material demand data may include a bill of materials for one or more production chain(s) of the production 804. The material demand data may include one or more recipe(s) specifying one or more material(s) for production process(es) of the production 804. 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 804. Material supply may be triggered by the supplier system accessing the material demand data.

[0238] The amount of output product(s) resulting from processes performed within production 804 may be measured using a sensor, such as sensor 808b. The measured data may be stored in one or more databases associated with operating system 816. Moreover processes performed within production 804 may be monitored using sensors, such as sensors 808b, and the generated monitoring data may be stored in one or more databases associated with operating system 816. 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 808a. Physical and / or chemical properties may include the properties previously described. The measured and / or determined data of the produced output products may be stored in one or more databases associated with operating system 816. The measured and / or determined data of the produced output products may be interrelated with a digital output product identifier associated with the respective output product. The digital output product identifier may be interrelated with a physical identifier element present on the output product or the packaging unit including the output product.

[0239] The produced output products 806 may be provided at one or more exit points of the production 804. The output product 806 may exit the system boundary 814 of the production 804.

[0240] The operating system 816 may include an asset generation service, such as asset generation service 2 606. The operating system 816 may be associated with such asset generation service (not shown). Asset generation service 2 606 may be configured to generate data set(s) (e.g. asset(s)) associated with output product(s) produced by production 804, for example as described in the context of FIG. 9 and FIG. 10.

[0241] Referring back to FIG. 7A and with continued reference to FIG. 8, the asset generation service 2 606 may generate data sets associated with the output product(s) (e.g. 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 804. The trigger may be generated by trigger generator 812. Trigger generator 812 may be part of a packaging line or may be present within a storage location, such as a warehouse. Trigger generator 812 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 812 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 front-end application may generate the trigger data by collecting digital output product identifier(s) associated with the selected output product(s). The collected digital output product identifier(s) may be used to generate the trigger data.

[0242] The trigger or trigger data may be received by data gathering unit 722 of asset generation service 2 606. Data gathering unit 722 may be connected to a data source layer 720. The data source layer 720 may include one or more databases, such as DB1 616, DB2 618 and DB3 620. 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 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). The one or more distributed data sources may contain output product data associated with produced output products. The output product data may include at least one measured physical and / or chemical property of produced output product(s) and / or at least one physical and / or chemical property determined from collected data associated with the production and / or the use of produced output product(s) as previously described. At least one of the distributed data sources may contain data instances that relate to the output product for which the asset generation service 2 606 is configured to generate the output product data set(s). The data source layer 720 may be owned or controlled by the data owner of the data associated with output product data. The data source layer 720 may be associated with the data owner of the output product data. Data gathering unit 722 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 720, for example as described in the context of FIG. 9.

[0243] The output product data gathered by data gathering unit 722 may be provided to data transforming unit 724. Data transforming unit 724 may be configured to generate output product data set(s) by transforming output product data gathered by data gathering unit 722 based on one or more rule(s) retrieved from rule DB 712, for example as described in the context of FIG. 7B. Transforming may include filtering the gathered output product data, aggregating output product data gathered from multiple data sources into a given format, 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 format 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. 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 output product data sets may include the output product data in tabular form. 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 semantic model, such as an aspect model, associated with the product are contained in the output product data set, hence avoiding missing data point(s) during generation of a battery passport associated with the product using said semantic model. The transformation allows to aggregate the gathered output product into a given data format, such as a tabular format, without the use of complex semantic models, hence facilitating generation and sharing of output product data set(s) within the battery ecosystem. Such sharing may enable more efficient production and / or recycling processes based on the shared output product data, for instance output product composition data. The tabular format can be readily consumed via a decentral network by battery passport service 628 described in the context of FIG. 6.

[0244] Data transforming unit 724 may further be configured to provide the generated output product data set(s) (hereinafter also referred to as asset(s)) to data provider unit 744. Data provider unit 744 may be configured to provide the received output product data set(s) to a database for storage, such as assets DB 704. 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 further include input material identifier(s) of input material(s) used to produce the output product. This way, input material(s) used to produce the output product can be identified. The asset(s) may be persisted by data transforming unit 724 in assets DB 704. Assets DB 704 may be configured to store output product data set(s) generated by data transforming unit 724. Assets DB 704 may be configured to provide output product data set(s) to data transfer service 702.

[0245] Data provider unit 744 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 708.

[0246] Asset publisher service 708 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 708 may further be configured to generate access control data including the digital output product identifier and the group access data identifier. The access control data may hence be associated with the output product data set as well as respective group access data. The access control data may further include access data associated with assets DB 704. The access data may include a locator or pointer to the assets DB 704 storing the respective output product data set. This may allow to access the respective output product data set based on data included in the access control data, e.g. the digital output product identifier and the access data. The group access data and access control data may be generated by asset publisher service 708 per data included in the output product data set, for example per digital output product identifier. The generated group access data and access control data may be provided to decentral data providing node 230 connected to asset generation service 2 606.

[0247] Decentral data providing node 230 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 230 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. 12. Decentral data providing node 230 may be configured to control access to output product data set(s) based on associated group access data and access control data generated by asset publisher service 708, for example as described in the context of FIG. 12. Decentral data providing node 230 may be associated with a participant of the product ecosystem, such as a producer of the output product(s).

[0248] Data transfer service 702 may be configured to gather output product data set(s) from assets DB 704 in response to a request from decentral data providing node 230. Data transfer service 702 may be configured to fetch asset metadata from assets DB 704 based on data received from decentral data providing node 230. 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 702 may be configured to gather respective output product data set(s) from assets DB 704 based on the fetched metadata. Data transfer service 702 may be configured to provide the gathered output product data set(s) to decentral data providing node 230.

[0249] The system may not comprise a decentral registry storing digital representations associated with identifier(s) of the generated output product data set(s) and allowing access to such output product data set(s) via the identifier(s) and endpoint(s) included in the digital representations. Hence, output product data set(s) may not be located by querying the decentral network 134 using the digital output product identifier but may only be accessed directly from decentral data providing node 230 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. The location data may be provided by the entity operating the asset generation service 2 606, to the battery passport service 628, for example as described in the context of FIG. 13.

[0250] FIG. 7B illustrates a diagram showing an example of a system configured to gather output product data and to transform 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. 7A. The system may be configured to perform the methods described in the context of FIG. 9 and FIG. 10.

[0251] Data transforming unit 724 may include rule-based engine 728. The rule-based engine 728 may operate on individual data point(s), multiple data point(s) and / or the gathered output product data. The rule-based engine 728 may operate on data gathered per 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 728 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 726) by data gathering unit 722 from a data source layer 720 as described in the context of FIG. 7A. Rule based engine 728 may be configured to determine output product identifier(s) associated with the output product data. For instance, rule-based engine 728 may parse the received output product data to determine the respective output product identifier(s). The rule-based engine 728 may have access to one or more rule(s). The rule-based engine 728 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 712. The one or more rule(s) or rule template(s) may be provided to rule DB 712 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 728 may generate a request to obtain one or more rule(s) from rule DB 712. The request may contain the respective output product identifier(s).

[0252] 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 728 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 semantic model of the product. Hence, the one or more rule(s) may ensure that data point(s) for such output products required according to the semantic 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 semantic model. The one or more rule(s) may be generated based on the mandatory output product data points present within the semantic model. This may ensure that output product data required by the semantic 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 728 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 712.

[0253] The one or more rule(s) may define aggregation rule(s) for aggregating output product data gathered from multiple data sources into a given format. The given format may be a tabular representation. Aggregation may hence result in filling gathered output product data into a tabular format. 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 model of the product. This may ensure that output product data required by the semantic 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 semantic 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.

[0254] Rule-based engine 728 may be configured to initialize the rule engine (see operation 732). Initialization of the rule engine may include generating rule data executable by a processor included in rule-based engine 728. 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 734) 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 728 may be determined by rule(s) gathered from rule DB 712. For instance, rule(s) gathered from rule DB 712 may determine whether rule-based engine 728 operates on individual data point(s) and / or multiple data point(s) and / or the whole gathered output product data.

[0255] Rule-based engine 728 may be configured to determine whether the gathered output product data can be transformed by one or more applied rule(s) (see operation 736). 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 728 may provide the generated output product data set to assets DB 704 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.

[0256] If at least a part of the gathered output product data could not be transformed, rule based engine 728 may proceed to operation 738. In operation 738, rule-based engine 728 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 728. The display device may comprise a graphical user interface 740. The display device may display the message in response to receiving message data from rule-based engine 728. 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.

[0257] FIG. 9 illustrates a flow chart of an example method for generating data associated with the production of the battery. The battery may be a battery described in the context of FIG. 3A to FIG. 5. The method illustrated in FIG. 9 may be implemented by the systems illustrated in FIG. 7A to FIG. 8. The data associated with the production of the battery may include output product data set(s) associated with output products. The output product(s) may correspond to input material(s) used to product the battery. The output product may be produced by a production, such as illustrated in FIG. 8.

[0258] With reference to FIG. 11, data associated with the output product may be provided. The data may be provided by a computing system connected to the system performing the method of FIG. 9, such as an asset generation service described in the context of FIG. 7A to FIG. 8. The data may be provided by a user via a communication interface to the system performing the method of FIG. 9, such as the asset generation service. The data may be provided to data gathering unit 722 of the asset generation service. The provided data may be generated in response to receiving a trigger, for example as described in the context of FIG. 8. 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, output product ID, serial number, an identification number, LOT number, batch number or a combination thereof.

[0259] With continued reference to FIG. 11, output product data may be gathered based on the provided data. The output product data may be gathered from a data source layer, such as data source layer 720 described in the context of FIG. 7A and FIG. 7B. The output product data may be gathered from data source layer 720 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 722. The output product data may include physical and / or chemical properties of produced output products and / or production data associated with the production of the output product as described in the context of FIG. 7A.

[0260] 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) related to a data model associated with battery passports of the product. The battery may be produced from the output product by using the output product as input material within at least one production step of a production chain used to produce the battery. The production process of the battery may include one or more production steps. The production steps may be performed by one or more entities of the battery ecosystem. The output product may be used as input material within at least one of such production step.

[0261] With reference to FIG. 7B, FIG. 10 and FIG. 11, 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 724, 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. 7B.

[0262] With continued reference to FIG. 7B, FIG. 10 and FIG. 11, executable logic may be generated from the one or more applicable rule(s). The executable logic may be generated by data transforming unit 724. 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 724 may sent a response to data gathering unit 722 indicating finalizing the generation of the executable logic.

[0263] With continued reference to FIG. 7B, FIG. 10 and FIG. 11, 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 722 may sent a request to data transforming unit 724 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 724 to data provider unit 744. 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 712 based on the gathered output product data). Verification may be performed as described in the context of FIG. 7B. 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.

[0264] Otherwise message data may be generated and provided, for example as described in the context of FIG. 7B.

[0265] The generated output product data set may be provided for access via a decentral network, such as decentral network 134 described in the context of FIG. 1 and FIG. 2, under control of the data owner of the output product data set. With reference to FIG. 11 , this may include storing the generated output product data set in a data storage, such as assets DB 704, for example as described in the context of FIG. 7A. With continued reference to FIG. 11, this may further include generating group access data and access control data as described in the context of FIG. 7A. The group access data and access control data may be used to control access to the associated output product data set, for example as described in the context of FIG. 12.

[0266] Use of rule(s) associated with a data model associated with the battery passport allows to ensure that output product data point(s) required according to the data model are contained in the output product data set, hence avoiding missing data point(s) during generating and / or updating the battery passport using the data model. The transformation allows to aggregate the gathered output product data into a given data format, such as a tabular format, 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 output product composition data. The tabular format can be readily consumed via the decentral network by a battery passport service, such as battery passport service 628 described in the context of FIG. 6 and FIG. 13, configured to generate data completeness metrics based on the consumed data and / or configured to generate and / or update battery passports. Verification by the consumer side ensures that the battery passports contain the data defined by the data model associated with the battery 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). 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 the data model associated with the respective battery passport of the battery produced using such output product(s).

[0267] FIG. 12 illustrates an example of a decentral system for accessing data associated with the production of a battery. The battery may be a battery described in the context of FIG. 3A to FIG. 5. The decentral system may be a decentral peer-to- peer network 134 as described in the context of FIG. 1 and FIG. 2. The data associated with the production of the battery may include input material data associated with input material(s) used to produce the battery and battery data associated with the battery. The input material(s) may be used within production step(s) of the production chain used to produce the battery. The input material(s) may include output products described in the context of FIG. 8.

[0268] The input materials may be associated with input material data. The input material data may be generated as described in the context of FIG. 7A to FIG. 8. The battery may be associated with battery data. The battery data may be generated as described in the context of FIG. 7A to FIG. 8. The input material data or battery data may be stored in assets DB 704 associated with data transfer service 702. Assets DB 704 may be associated with a decentral provider node 230. The decentral provider node may be associated with a decentral network participant. The decentral network participant may be the producer of the input material or the battery. The decentral network participant may be the data owner of the input material or battery data stored in assets DB 704. The input material data or battery data may represent at least a part of a digital twin of the physical entity of the input material or battery, respectively. 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 input material or battery in a digital representation of a real-world system.

[0269] The decentral system may be used to gather input material data associated with input material(s) used to produce the battery and battery data as described in the context of FIG. 19A and FIG. 23.

[0270] 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 134 (see for example FIG. 1 and FIG. 2). The data provider may provide data, such as input material data or battery data, to the data consumer. The data consumer may request input material data or battery data from the data provider. The data provider may correspond to an entity producing the respective input material or the battery. The data consumer may correspond to an entity operating the battery passport service as illustrated in FIG. 6 and FIG. 13. The data provider may be associated with a data provider environment 1208. The data consumer may be associated with a data consumer environment 1202. 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 network may include more or less environments than illustrated in FIG. 12.

[0271] 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 input material data and / or battery data can be exchanged in a secure and controlled manner within the decentral network.

[0272] Data consumer environment 1202 may include a consumer node 632 (e.g. decentral data consuming network node 632) and battery passport service 628. Battery passport service 628 may include or correspond to the service illustrated in FIG. 6 and FIG. 13. Consumer node 632 may be configured to communicate with battery passport service 628. Consumer node 632 may be configured to receive data from battery passport service 628 and to provide data to battery passport service 628. Consumer node 632 may be configured to receive data from provider nodes, such as provider node 230. Consumer node 632 may be configured to request data from provider nodes, such as provider node 230. Consumer node 632 may be configured to receive data from battery passport service 628, configured to provide data to battery passport service 628 and configured to receive and / or request data from provider node(s), such as provider node 230. Consumer node 632 may be configured to request input material data or battery data stored in assets DB 704 associated with the respective provider node, such as provider node 230. Battery passport service 628 may be configured to send a request for data to consumer node 632, for example as described in the context of FIG. 19A to FIG. 23. Battery passport service 628 may be configured to process data, such as input material data and battery data, received from consumer node 632, for example as described in the context of FIG. 19A to FIG. 23.

[0273] Data consumer environment 1202 may be associated with a participant of the battery ecosystem, such as battery ecosystem illustrated in FIG. 1 and FIG. 2. For instance, data consumer environment 1202 may be associated with an input material producer, such as chemical product producer 102 or a battery producer, such as chemical product user 106, receiving input material(s) and producing the battery using the input material(s) or a battery user, such as end-product producer 108, producing end-products containing the battery.

[0274] Data consumer environment 1202 may be associated with an entity operating the battery passport service 628. Data consumer environment 1202 may be associated with an entity performing the methods illustrated in FIG. 18 and / or FIG. 20 to FIG. 23 and / or FIG. 25 and FIG. 26. The entity performing such methods may be a participant of the battery ecosystem. The entity performing such methods may not be a participant of the battery ecosystem but may function as a service provider for a participant of the battery ecosystem. The service provider may generate and provide data completeness metrics. The service provider may generate and / or update battery passports based on data gathered from data provider environments associated with input material data and battery data.

[0275] Data provider environment 1208 may include provider node 230, data transfer service 702 and assets DB 704. Data provider environment 1208 may include an asset generation system, such as asset generation service 2 606 illustrated in FIG. 7A, FIG. 7B and FIG. 8. Data provider environment 1208 may be associated with a data owner, such as an input material producer or battery producer. Data provider environment 1208 may include assets DB 704 storing input material data of input material(s) used to produce the battery or battery data associated with the battery. Assets DB 704 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. The data owner may control access to such storage. Provider node 230 may be configured to provide data, such as input material data or battery data stored in assets DB 704. Provider node 230 may be configured to perform authentication and authorization step(s) prior to providing the data, for example as described with reference to FIG. 19A later on. Provider node 230 may be coupled to data transfer service 702 configured to gather input material data or battery data from assets DB 704 in response to a request received from provider node 230 and to provide the gathered data to provider node 230.

[0276] FIG. 13 illustrates an example of a battery passport service configured to validate a completeness of data accessible for generating and / or updating a battery passport associated with a battery. The battery passport service may further be configured to generate and / or update the battery passport associated with the battery. The battery passport service may be configured to perform the methods illustrated in FIG. 18 and FIG. 20 to Fig. 22. The battery passport service may further be configured to perform the methods illustrated in FIG. 25 and FIG. 26. The battery may be a battery described in the context of FIG. 3A to FIG. 5.

[0277] The battery passport service 628 may include different modules or units. In the embodiment illustrated in FIG. 13, battery passport service 628 includes asset registration and linking module 1304, asset validation module 1306, data quality analyzer 1308 and battery passport generator 1310. Battery passport service 628 may further include one or more databases, such as registry 1312. At least a part of the modules or units may be configured to communicate with each other. Use of a modular service allows to flexibly adjust the modules or units, for example by addition, removal or modification of single modules or units.

[0278] The battery passport service 628 and one or more modules included therein may be accessed via a communication interface. Accessing the battery passport service 628 may involve authentication and / or authorization steps. For instance, a user may provide authentication data and access to the battery passport service 628 may only be granted upon successful authentication. Access to module(s) included in the battery passport service 628 may be subject to successful authorization. For instance, some module(s) may only be accessible by a defined user group. For example, battery passport generator 1310 may only be accessible by a user group defined as battery passport generators.

[0279] The asset registration and linking module 1304 may be configured to provide an interface, such as a digital user interface or a computing interface, for providing asset data and associated data source data associated with data sources providing such asset data. The data sources may be provider nodes configured to provide data, such as input material data and battery data, stored in dedicated storages associated with such provider nodes, for example as described in the context of FIG. 12. Data source data may include endpoints associated with such data sources. Data source data may further include a decentral participant identifier related to the data source and / or a participant role associated with the participant of the battery ecosystem and being associated with or controlling the data source. Asset data may include asset identifiers associated with assets (e.g. input material data or battery data) provided by such data sources. The asset data may further include relationship representation(s) specifying relationships between the asset identifier associated with the asset data (e.g. parent identifier) and further asset identifier(s) (e.g. child identifier(s)) associated with asset(s) of input material(s) used to produce the intermediate product or battery the parent identifier is associated with, for example as illustrated in FIG. 14B. Asset registration and linking module 1304 may further be configured to store data received via the interface in registry 1312. Prior to storage, the received data may be processed. For instance, the provided data may be transformed, for example by aggregation, interrelation or the like. With reference to FIG. 14A, the data acquired by the asset registration and linking module 1304 may be stored in registry 1312. Registry 1312 may store asset identifiers associated with assets, such as input material data and battery data, provided by data sources associated with participants of the battery ecosystem. The asset identifiers may be interrelated with a participant role of the participant associated with the data source providing the asset, a decentral participant identifier related to the data source providing the asset and an endpoint of the data source providing the asset. The asset identifier may be further interrelated with child identifiers associated with input material(s) used to produce the output product the asset is associated with. Since interrelation may not be applicable for all input materials used to produce the battery, the line connecting the asset ID with the child I D(s) is illustrated by a dashed line in FIG. 14A. The output product may correspond to an input material used to produce the battery.

[0280] To reliably determine the completeness of data accessible for generating and / or updating of the battery passport, the identifiers associated with input material(s) used to produce the battery may be linked to or related to the output product identifier associated with the output product produced from such input material(s). The output product may be an intermediary product used to produce the battery or the battery. This way asset identifier(s) associated with input material(s) used to produce a given battery may be determined based on the battery identifier associated with such battery. With reference to FIG. 14B, registry 1312 may include a linking of asset identifiers of all input materials used to produce the battery to the battery identifier (see left side of FIG. 14B). In addition or alternatively, registry 1312 may include a linking of asset identifiers to child identifiers in the form of a tree structure, with the battery identifier being the top node of the tree (see right side of FIG. 14B). The linking illustrated in FIG. 14B may be generated from the asset data included in registry 1312 by resolving the relationships between asset identifiers included in such registry.

[0281] With reference to FIG. 14C, the asset data and associated data source data may be provided as entries to a digital user interface, such as graphical user interface 1408. In another embodiment (not shown), the data source data and associated asset data may be provided as entries to a computing interface. The graphical user interface 1408 may include a field for entering the asset ID 1412 and a field for entering data source data 1418 associated with the asset ID. Field 1418 may include a list of data sources and may allow the user to select the appropriate data source providing the asset associated with the asset ID. The graphical user interface 1408 may further include one or more data fields for entering child identifiers of the asset ID entered in field 1412. Graphical user interface 1408 may provide the option to upload such child identifiers using button 1420. Storage of the data entered into graphical user interface 1408 in registry 1312 may be triggered using button 1424. Based on the entries generated in the digital user interface or the data provided to the computing interface, data associated with the data sources may be generated and stored or persisted in registry 1312.

[0282] In an alternative embodiment, the interface may include a communication interface configured to receive data source data and associated asset data. For instance, the data source data and associated asset data may be provided via such interface to asset registration and linking module 1304.

[0283] The asset validation module 1306 may be configured to gather data associated with the production of the battery from one or more data sources, such as provider nodes, and to validate the gathered data, for example as described in the context of FIG. 19A to FIG. 23. Asset validation module 1306 may be configured to persist the validated data in one or more databases. Asset validation module 1306 may be configured to provide the validated data to data quality analyzer 1308 and / or battery passport generator 1310.

[0284] Data quality analyzer 1308 may be configured to validate the amount of data, such as input material data associated with input materials used to produce the battery and / or battery data associated with the battery, accessible for generating and / or updating battery passports. Data quality analyzer 1308 may include a metrics generator 1504 configured to generate data completeness metrics, for example as described in the context of FIG. 15. Data quality analyzer 1308 may be configured to perform the method illustrated in FIG. 18. Data quality analyzer 1308 may be configured to generate a data completeness metric as illustrated in FIG. 17A to FIG. 17C. Data quality analyzer 1308 may be configured to provide generated data completeness metrics to battery passport generator 1310. By validating the quality of the data with respect to a degree of correlation between the data included in a data model associated with the battery passport and the data stored in registry 1312 or the validated data generated by asset validation module 1306, transparency on the number of data points accessible for generating and / or updating battery passports can be achieved. This transparency allows to determine the reliability of the passport data included in the generated and / or updated battery passports and allows to control generation and / or updating of battery passports using defined completeness thresholds. Moreover, this transparency allows to identify input material producers not yet having generated and / or provided access to input material data defined by the data model. This way, missing data can be requested and it can be ensured that the passport data has a sufficient degree of completeness to facilitate efficient further processing of the batteries associated with such battery passports

[0285] Battery passport generator 1310 may be configured to generate battery passports associated with batteries and / or to update existing battery passports based on the data completeness metric received from data quality analyzer 1308 and data associated with the production of the battery. Battery passport generator 1310 may be configured to perform the methods illustrated in FIG. 25 and / or FIG. 26. Battery passport generator 1310 may be configured to persist the generated battery passports in an archive. Battery passport generator 1310 may be configured to provide the generated battery passports for access by data consumers. The generated battery passports may be provided via a decentral network, such as illustrated in FIG. 1 and FIG. 2. The generated battery passports may be provided under control of the data owner of the battery passport.

[0286] FIG. 15 illustrates an example of a data quality analyzer illustrated in FIG. 13. The data quality analyzer 1308 may include metrics generator 1504. The metrics generator 1504 may be communicatively coupled to registry 1312 and asset validation module 1306. In one embodiment, metrics generator 1504 may further be in communication with a rule database 1508 storing one or more validation rule(s) configured to validate completeness of data accessible for generating and / or updating battery passports based on data related to data models associated with the respective battery passports.

[0287] With reference to FIG. 16, metrics generator 1504 may include a rule-based engine 1620. The rule-based engine may be a further rule-based engine. The rule-based engine 1620 may be included in rule-based engine 728 (see FIG. 7B). The rulebased engine 1620 may operate on individual data point(s), multiple data point(s) and / or a whole data set, such as the validated data provided by asset validation module 1306 or the data stored in registry 1312. The rule-based engine 1620 may operate on validated data or data stored in registry 1312 per digital battery identifier individually. This allows to determine the degree of completeness of the data accessible for generating and / or updating a given battery passport, hence allowing transparency on the data accessible for generating and / or updating a given battery passport on a more granular level, e.g. on battery passport level. Rule-based engine 1620 may receive a request to validate the quality of the data accessible for generating and / or updating the battery passport. The request may contain data associated with the battery, such as a battery identifier. The battery identifier may include a unique battery ID. The battery identifier may further include a battery type identifier uniquely identifying the battery type or battery class of the battery. The rule-based engine 1620 may have access to one or more validation rule set(s) including one or more validation rule(s). The rule-based engine 1620 may include one or more validation rule set(s) including one or more validation more rule(s). The one or more validation rule set(s) may be stored in a data storage, such as rule DB 1508. The one or more rule(s) may correspond to unstructured data associated with instructions related to validation operation(s). The validation rule set(s) may correspond to unstructured data associated with instructions related to validation operation(s). The one or more validation rule set(s) and / or validation rule(s) may be associated with a battery type identifier(s) and / or with battery identifier(s). Rule-based engine 1620 may be configured generate a request to obtain at least one validation rule set from rule DB 1508. The request may contain the respective battery identifier(s).

[0288] One or more validation rule set(s) may be provided to rule-based engine 1620 in response to the request. The validation rule set(s) may include rules configured to validate completeness of data accessible for generating and / or updating battery passports based on data related to data models associated with the respective battery passports. The validation rule(s) may relate to data related to the data models. The validation rule(s) may relate to input material producer(s) producing input material(s) associated with input material data defined by the data models. The validation rule(s) may relate to one or more data point(s) defined by the data models. The validation rule(s) may relate to one or more data points associated with input material(s) used to produce the battery and the battery as defined by the data models. The validation rule(s) may relate to one or more data points to be provided for access per participant of the battery ecosystem involved in the production of the battery according to data models. The validation rule(s) may be configured to determine input material identifiers and associated accessible data points based on the data associated with the battery, optionally to determine accessible data points associated with the battery based on the data associated with the battery, and to determine the degree of correlation by comparing target data points defined by the data model with the accessible data points. The validation rule(s) may be configured to determine input material identifiers associated with the battery identifier, to determine validated data associated with the determined input material identifiers and optionally the battery identifier and to determine the degree of correlation by comparing target data points defined by the data model with the data points included in the validated data. The one or more validation rule(s) may be configured to generate the data completeness metric per battery identifier.

[0289] Rule-based engine 1620 may be configured to select at least one validation rule based on the data associated with the battery. The selection may be dynamic and / or static based on the data associated with the battery and validation rule pairs. For example, data associated with the battery, such as the battery type identifier, and validation rule pairs may be predefined. The one or more validation rule(s) may be associated with battery identifier(s) and / or battery type identifier(s). A mapping table may be used to map battery identifier(s) to corresponding battery type identifier(s) associated with the validation rule(s). The battery type identifier(s) may be associated with battery type(s). The mapping table may be stored in a separate database (not shown). This way, the validation rule set may include validation rule(s) associated with different battery type identifier(s), hence avoiding generation of different validation rule set(s) per battery type or per battery and allowing to reduce the number of validation rule set(s) that need to be generated, stored and maintained in rule DB 1508. Rule-based engine 1620 may be configured to initialize the rule engine (see operation 1624). Initialization of the rule engine may include generating rule data executable by a processor included in rule-based engine 1620, for example as described in the context of FIG. 18. The rule data may include or correspond to executable logic. This may allow to transform validation rule(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 data stored in registry 1312 or to the validated data provided by asset validation module 1306 (see operation 1626) to validate the data accessible for generating and / or updating battery passports associated with batteries according to the obtained rule(s). Execution of the logic may result in matching the data stored in registry 1312 or the validated data provided by asset validation module 1306 to condition(s) included in the executable logic, evaluating the condition(s) with matched data and triggering execution of rule actions based on condition evaluation results. Validation of the data may include determining input material identifiers and associated accessible data points based on the data associated with the battery, optionally determining accessible data points associated with the battery based on the data associated with the battery, and determining a degree of correlation by comparing target data points defined by the data model with the accessible data points. The validation rule(s) may be configured to determine input material identifiers associated with the battery identifier, to determine validated data associated with the determined input material identifiers and optionally the battery identifier and to determine the degree of correlation by comparing target data points defined by the data model with the data points included in the validated data. Operations performed by rule-based engine 1620 may be determined by validation rule set(s) and included validation rule(s) gathered from rule DB 1508. For instance, rule(s) gathered from rule DB 1508 may determine whether rule-based engine 1620 operates on individual data point(s) and / or multiple data point(s) and / or the whole data.

[0290] Rule-based engine 1620 may be configured to provide the validation result to metrics generator 1504. Metrics generator 1504 may be configured to generate a data completeness metric from the validation result received from rule based engine 1620. Metrics generator 1504 may be configured to provide the generated data completeness metrics. Providing may include providing the metrics for display. Providing may include providing the metrics to a data storage. Providing may include providing the metrics via a communication interface, for example to another module of battery passport service 628, such as battery passport generator 1310.

[0291] With reference to FIG. 17A, generating the data completeness metric may include determining a total or overall degree of correlation between the accessible data points and the target data points based on the validation result. The degree of correlation may correspond to the fraction of accessible data points matching the target data points with respect to the total number of target data points. The degree of correlation may be determined per battery identifier. The generated data completeness metrics 1710 may include data associated with the battery, such as the battery identifier, and a total degree of correlation of accessible data points associated with such data. The total degree of correlation may be displayed within a graphical user interface as completeness bar 1708. Such metric provides an overview on the total degree of correlation, e.g. the total amount of accessible data points and non-accessible data points (e.g. missing data points) and may allow to provide transparency on the overall quality of the passport data included in a battery passport generated from such accessible data.

[0292] In another embodiment and with reference to FIG. 17B to FIG. 17C, generating the data completeness metric may include determining the degree of correlation of accessible data points and target data points for at least a part of the participants of the battery ecosystem involved in the production of the battery (e.g. for at least a part of the participants of the production chain producing the battery). The degree of completeness may be determined by comparing the target data points per participant role with accessible data points per respective participant role. In one example and with reference to FIG. 17B, the generated data completeness metric 1710 may include the battery identifier(s), available child identifier(s) (e.g. input material identifier(s) associated with input material(s) used to produce the battery) associated with said battery identifier, the participant role associated with such identifier(s) and the degree of completeness per participant role. The generated data completeness metric 1710 illustrated in FIG. 17B may be displayed within a graphical user interface. In another example and with reference to FIG. 17C, the generated data completeness metric may include the data mentioned with respect to FIG.

[0293] 17B and additional data points, such as whether data points associated with input material(s) used to produce the battery are accessible as well as the number of accessible data points and the number of target data points per participant role. Based on the number of accessible data points and target data points, a total degree of correlation between the number of accessible data points and the number of target data points may be determined. The data completeness metric 1710 illustrated in FIG. 17C may be displayed within a graphical user interface. In addition, the total degree of correlation may be displayed as completeness bar 1708 within the graphical user interface.

[0294] The metrics illustrated in FIG. 17B and FIG. 17C do not only provide a transparency on the degree of completeness with respect to data points accessible for generating and / or updating battery passports, but at the same time allow to identify participants of the battery ecosystem who have not yet generated input material data and / or battery data and / or have provided access to such data. Such transparency allows to request data from such participants to improve the quality (e.g. the completeness) of the passport data included in the generated and / or updated battery passport.

[0295] FIG. 18 illustrates a flow chart of an example of a method for validating a completeness of data accessible for generating and / or updating a battery passport associated with a battery. The completeness of the data may be validated with respect to the accessibility of such data for generating the battery passport and / or for updating an existing battery passport. The battery may be a battery as described in the context of FIG. 3A to FIG. 5. The battery may be produced from one or more input material(s) by a production chain. The production chain may include one or more production step(s) as described in the context of FIG. 6. The method illustrated in FIG. 18 may be implemented by the battery passport service 628 described in the context of FIG. 6 and FIG. 13.

[0296] Data associated with the battery may be provided. The data associated with the battery may include at least one digital battery identifier associated with the battery. The digital battery identifier may include a batch number, a LOT number, a serial number, an identification number, a battery name, a battery type identifier or a combination thereof. The battery identifier may be provided from a code reader configured to read a physical code connected to the battery and to determine the digital battery identifier(s) encoded in the code. The battery identifier may be provided from a device configured to acquire image data and to determine the battery identifier(s) based on the acquired image data.

[0297] Data associated with data sources indicating data accessible for generating and / or updating battery passports may be provided. Data associated with the data sources may include asset data provided by data sources and associated data source data associated with such data sources. The data sources may be provider nodes of a decentral network as described in the context of FIG. 6 and FIG. 13. Data source data may include endpoints associated with such data sources. Data source data may further include a decentral participant identifier related to the data source and / or a participant role associated with the participant of the production chain used to produce the battery and being associated with the data source. Asset data may include asset identifiers associated with assets provided by such data sources. The asset data may further include relationship representation(s) specifying relationships between the asset identifier associated with the asset data (e.g. parent identifier) and further asset identifier(s) (e.g. child identifier(s)) associated with asset(s) of input material(s) used to produce the intermediate product or the battery the parent identifier is associated with. Data associated with the data sources may be generated by interrelating the asset identifier associated with a given asset with the endpoint of the data source, the participant role related to the data source, the decentral participant identifier and optionally child identifier(s) associated with asset(s) of input material(s) used to produce the intermediate product or battery associated with the asset identifier, for example as described in the context of FIG. 14A. With reference to FIG. 13, data associated with data sources indicating accessible data may be provided from a storage, such as registry 1312. Registry 1312 may store such data associated with the data sources. Data associated with the data sources may be generated and stored as described in the context of FIG. 13 and FIG. 14C.

[0298] Data related to a data model associated with the battery passport may be gathered based on the provided data associated with battery. The data related to the data model may include participant role(s) of participants associated with the production of the battery and the number of data points to be provided by such participant role(s) according to the data model. The data related to the data model may further include a digital battery identifier, such as a battery type identifier. This way, the data related to the data model may be linked to a battery or a battery type. The participant role(s) may include the role(s) illustrated in FIG. 1 and FIG. 2, such as miner 214, refiner 216, battery cell producer and battery producer 220. Participants associated with the production of the battery may include participants performing at least one production step of the production chain used to produce the battery. The number of data points to be provided by such participant role(s) according to the data model may be determined by assigning a participant role to at least a part of the data points defined by the data model and accumulating the data points per assigned participant role. The data points defined by the data model may be assigned to participant role(s) based on properties of the intermediate product or the battery produced by such participant role. For instance, data points defining the battery properties within the data model may be assigned to the participant role “battery producer”. Likewise, data points defining the composition of the cathode active material may be assigned to the participant role “cathode active material (CAM) producer”. The data related to the data model may be included in one or more rule(s). Hence gathering of the data related to the data model may include gathering one or more rule(s) associated with, being related to or including such data related to the data model.

[0299] A data completeness metric associated with data being accessible for generating and / or updating the battery passport may be determined by determining a degree of correlation between the data associated with the data sources and the data related to the data model. The degree of correlation may indicate the amount of data points being accessible according to the data associated with the data sources with respect to the amount of data points defined by the data model and included in the data related to the data model. The data completeness metric may be a data completeness metric as described in the context of FIG. 17A to FIG. 17C.

[0300] The data completeness metric may be generated by determining a degree of correlation between the data associated with the data sources and the data related to the data model. The degree of correlation may be determined by • determining child identifiers included in the data associated with the data sources based on the provided data associated with the battery,

[0301] • determining the number of accessible data points by matching the determined child identifiers and optionally the battery identifier included in the data associated with the battery with identifiers included in the data associated with the data sources,

[0302] • determining the degree of correlation by comparing the number of accessible data points with the number of data points defined in the data related to the data model.

[0303] The degree of correlation may be determined by executing generated executable logic subject to rule execution criteria on the provided data associated with the data sources. The rule logic may be generated and executed by a rule-based engine, such as rule-based engine 1620 described in the context of FIG. 16. 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 executable logic may be generated from one or more rule(s) configured to validate the completeness of the data accessible for generating and / or updating battery passports (e.g. accessible data). The one or more rule(s) may include one or more validation rule(s) as described in the context of FIG. 16. The one or more rule(s) may be applied to the data associated with the data sources. The one or more rule(s) may be configured to

[0304] • determine child identifiers included in the data associated with the data sources based on the provided data associated with the battery,

[0305] • determine the number of accessible data points by matching the determined child identifiers and optionally the battery identifier included in the data associated with the battery with identifiers included in the data associated with the data sources,

[0306] • determine the degree of correlation by comparing the number of accessible data points with the number of data points defined in the data related to the data model.

[0307] The rule-based engine may operate on individual data points present within the data associated with the data sources. The rule-based engine may operate on a combination of data points present within the data associated with the data sources. The rule-based engine may operate on the complete data associated with the data sources and the complete data related to the data model.

[0308] The generated data completeness metric may include a data completeness metric as illustrated in FIG. 17A to FIG. 17C. The data completeness metric may indicate the degree of correlation between accessible data and data defined by the data model associated with the battery passport. The data completeness metric may indicate the degree of correlation between the data point defined by the data model (e.g. the target data points) and the data points included in the validated data. The higher the degree of correlation, the more data points included in the data associated with data sources match or map to target data points defined by the data model. Hence, the degree of correlation may indicate a degree of completeness of the data provided by data providers for generating and / or updating the battery passport with respect to data points defined by the data model. Turing back to FIG. 18, the generated data completeness metric may be provided. Providing the generated data completeness metric may include providing the generated data completeness metric for display. Providing the generated data completeness metric for display may include generating a graphical interface presentation including instructions configured to allow display of a graphical representation of the generated data completeness metric. The graphical representation may include a completeness bar indicating the degree of completeness (e.g. the amount of accessible data in comparison to the data defined by the data model), such as illustrated in FIG. 17A and FIG. 17C. The graphical representation may include a tabular, such as illustrated in FIG. 17A to FIG. 17C. The graphical representation may include the tabular form and the completeness bar.

[0309] Providing the generated data completeness metric may include providing the generated data completeness metric via a computing interface. The data completeness metric may be provided to a storage for storing the data completeness metric. The data completeness metric may be associated with the battery identifier to allow linking of the data completeness metric to the battery. Data completeness metrics stored in the storage may be updated if a data completeness metric is provided to the storage including a data completeness metric associated with the battery identifier. Storing the generated data completeness metric allows to gather such metric for later use, for example upon initiating generation of the battery passport.

[0310] A request indicating missing data according to the generated data completeness metric may be generated and provided. Data missing according to the data completeness metric may include data points defined according to the data model which are provided by data sources not included in the data associated with the data sources. Hence, missing data may include data point(s) to be provided by data sources not being included in the provided data associated with data sources. Initiating the request may include determining

[0311] • providing the battery identifier and input material identifier(s) associated with input material(s) used to battery,

[0312] • determining data sources associated with the input material identifier(s) based on the provided data associated with data sources,

[0313] • determining data source(s) associated with the input material identifier(s) where no data source data is available for child identifier(s) of such input material identifier(s)

[0314] • generating and providing the request(s) to provide missing data to the determined data source(s).

[0315] The request(s) may contain the child identifier(s) (e.g. identifier(s) of input material(s) used by the participant associated with the determined data source(s) to produce an intermediate battery) and an indication that data of upstream participant(s) of the participant associated with the determined respective data source is required. The request may be provided to such participant using the data source data associated with such participant and included in the data associated with the data sources. In response to receiving such request, the participant may generate a request to provide such missing data to the upstream participant. This allows to request missing data from upstream participants without having to render the production chain, in particular the identity of the participants of the production chain, transparent. This way, it can be ensured that missing data is requested and received without having to disclose confidential information, such the identity of the participants of the production chain, to the entity generating the data completeness metric and / or the entity generating the battery passport.

[0316] By validating the completeness of the data accessible for generating and / or updating battery passports associated with batteries, the degree of completeness of passport data included in the battery passports and hence the reliability of such passport data can be made transparent to battery passport generators and / or to battery passport users. Determining the degree of completeness based on data associated with the data sources allows to efficiently provide transparency on the degree of available data for generating and / or updating battery passports without having to gather any data associated with the production of the battery via a decentral network. Hence, the degree of completeness may be efficiently determined without involving data traffic via the decentral network, hence reducing the overall data transfer rates and improving the stability of the decentral network. This transparency allows to generate or update battery passports based on a given or predefined degree of completeness, hence ensuring that the passport data included in the battery passports has a sufficient degree of completeness and thereof a sufficient degree of reliability. This way, it can be ensured that passport data required to ensure efficient further processing of the battery, such as efficient recycling of an end-of-life battery or a component thereof, is included in the generated and / or updated battery passports. Efficient further processing may enable a reduced environmental impact of the battery ecosystem and / or a higher circularity of materials and products used within the battery ecosystem. The transparency further allows to identify participants of the production chain of the battery not yet having generated and / or provided access to data to be included in the battery passports according to the data model associated with the battery passports. This way, participants can be requested to generate and / or provide access to such data to ensure a high degree of completeness of the generated and / or updated battery passports.

[0317] By generating and providing requests indicating missing data to participants of the production chain, missing data can be requested without requiring full transparency on the production chain. Instead, only transparency on the data sources and associated participants being related to participants not having provided data by relationships of identifier(s) is required without having to know each individual participant of the production chain. This ensures that missing data can be requested in a reliable manner without requiring full knowledge of the production chain, hence increasing the trustworthiness of the entity generating the battery passports based on the data completeness metrics.

[0318] FIG. 19A illustrates a block diagram of an example system for verifying data associated with the production of a battery. The battery may be a battery as described in the context of FIG. 3A to FIG. 5. The battery may be produced from one or more input material(s) by a production chain. The input material(s) may correspond to output product(s) or intermediate product(s) produced by participants of the production chain. The production chain may include one or more production step(s) as described in the context of FIG. 6. Data associated with the production of the battery may include input material data (e.g. input material assets) associated with input materials used to produce the battery. Data associated with the production of the battery may further include battery data (e.g. battery asset) associated with the battery. The system illustrated in FIG. 19A may be configured to perform the methods illustrated in FIG. 20 to FIG. 23.

[0319] Asset validation system 1942 may include data transfer service 1902, stream storage system 1912 and data transforming unit 1904. Various databases, such as rule DB 1906, archive general 1948 and archive DPP product type A 1950 may be connected to data transforming unit 1904.

[0320] Verification of data associated with the production of the battery may be initiated by a request to asset validation system 1942. With reference to FIG. 23, the request may be received at data transfer service 1902. The request may include the asset identifier(s) and associated data source data. With further reference to FIG. 6, the request may be generated in response to receiving an indication of a user to validate the completeness of data accessible for generating and / or updating the battery passport associated with the battery or upon receiving an indication of a user to generate the battery passport for the battery. The user indication may trigger gathering of asset identifier(s) and associated data source data from registry 1312 based on the battery identifier(s) included in the user indication. The gathered data may be used to generate the request to asset validation system 1942.

[0321] The asset validation system 1942 may be connected to a decentral data consuming node, such as consumer node 632. The decentral data consuming node may be part of a decentral network, such as decentral network 134 described in the context of FIG. 1 and FIG. 2. The decentral data consuming node 632 may be associated with a decentral participant. The decentral participant may be a participant of the battery ecosystem associated with the battery. The decentral participant may not be a participant of the battery ecosystem, e.g. may be a service provider generating battery passports on behalf of a participant of the battery ecosystem. With reference to FIG. 12, decentral data consuming node 632 may be configured to request access to data associated with the production of the battery at provider node(s) associated with such data. The request may include the identifier associated with the respective data (e.g. asset) and a decentral participant identifier associated with the decentral participant operating consumer node 632. The request may be generated in response to data received from the system, for example received from data transfer service 1902. The data received from the system may include the asset identifier(s) and associated access data pointing to decentral provider node(s), such as provider node(s) 228 to 232. The access data may include endpoint(s) associated with the decentral provider node(s), such as URI(s). The request may be generated per asset 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 632 and provider node(s), such as nodes 228 to 232. If authentication fails, no output product data set(s) may be provided by respective data provider(s).

[0322] Provider node(s), such as nodes 228 to 232 receiving the request may initiate data transaction(s) according to a transaction protocol with consumer node 632. Provider node(s) may provide a data set include one or more data usage rule(s) associated with the decentral identifier(s). The data set may be provided to asset validation system 1942. The asset validation system 1942 may parse the received data set to determine the data usage rule(s). The determined rule(s) may be provided to a user for consent. The asset validation system 1942 may be configured to automatically accept such data set(s) provided by predefined provider node(s). The asset validation system 1942 may provide data being indicative of the signature, such as a token including the identifier associated with the data set and proof data (e.g. an electronic signature), to consumer node 632. If the rule(s) are not accepted, the asset validation system 1942 may likewise forward data being indicative of declining the data usage rule(s) included in the data set to consumer node 632. Consumer node 632 may forward this data to the provider node(s). Upon declining the data usage rule(s), provider node(s) may terminate the connection and may not provide any assets. Use of the data set including data usage rule(s) ensures that the consumer node 632 and further systems handling the data are complying to at least one data usage rule associated with the provided assets. This may ensure that the assets may be exchanged in a secure and controlled manner, hence avoiding access to assets by unauthorized decentral network participants while allowing to provide the assets to decentral network participants required to use such provided assets, for example to generate battery passports associated with the batteries produced from input materials associated with such assets. With continued reference to FIG. 12, data provider(s) may provide assets associated with identifier(s) included in the request received from consumer node 632 upon acceptance of the usage rule(s). The assets may be gathered from a dedicated storage, such as assets DB 704 as described in the context of FIG. 7A and FIG. 9, by the data provider(s) and provided via the peer-to-peer network to consumer node 632.

[0323] Returning to FIG. 19A and with continued reference to FIG. 23, consumer node 632 may provide the received asset(s) to data transfer service 1902. Data transfer service 1902 may be connected to stream storage system 1912. Stream storage system 1912 may be connected to data transforming unit 1904. Data transforming unit 1904 may be positioned upstream from data transfer service 1902. Asset(s) gathered via the decentral network may flow through data transfer service 1902 and stream storage system 1912 to data transforming unit 1904.

[0324] Data transfer service 1902 may be configured to receive of asset(s) from consumer node 632. The asset(s) may represent a stream of data. Such a stream may be an ordered sequence of records received from consumer node 632 relatively continuously, i.e. not in accumulated batches or chunks. A record may for example comprise input material data (e.g. an asset) 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 1902 may be configured to generate data package(s) including the asset(s) received from consumer node 632. A data package may be generated per received asset. The data package may include further data, such as a time stamp, a date stamp, the input material identifier associated with the asset, the decentral participant identifier associated with the provider node, location data pointing to the dedicated storage storing the asset or a combination thereof. The data package may represent a message or an event. The generated data package(s) may be provided to stream storage system 1912.

[0325] Stream storage system 1912 may be configured to store data packages received (e.g. pushed) from data transfer service 1902. The stream storage system 1912 may be configured to provide the stored data to data transforming unit 1904. The stream storage system 1912 may be configured to provide the stored data to data consuming unit 1908 of data transforming unit 1904. Stream storage system 1912 may comprise one or more persistent or non-persistent logs 1914, 1916. In this embodiment, stream storage system 1912 comprises two persistent or non-persistent logs 1914, 1916 (i.e. log 1 1914 and log 2 1916). 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 1902.

[0326] Stream storage system 1912 may provide a streaming service or stream processing service between one or more streaming sources (e.g. data transfer service 1902) and one or more streaming sinks (e.g. log 1 1914 and log 2 1916). Stream storage system 1912 may act as a persistent or non-persistent stream sink for input material data set(s) received from consumer node 632. For example, open-source software systems such as Apache Kafka ("Kafka") or Azure Event Hubs may act as a persistent stream sink.

[0327] Stream storage system 1912 may be configured to pull data package(s) from data transfer service 1902. For instance, stream storage system 1912 may be configured to request data package(s) from data transfer service 1902 at regular time intervals. Stream storage system 1912 may be configured to determine if the received or pulled data package(s) is / are already contained in the one or more persistent or non-persistent logs. If said data package(s) is / are already contained in the one or more persistent or non-persistent logs, stream storage system 1912 may not store the received or pulled data package(s) in said logs. If said data package(s) is / are not contained in one or more persistent or non-persistent logs or is an update, stream storage system 1912 may be configured to store the received or pulled data package(s) in the one or more persistent or non-persistent logs or to update data package(s) present in the persistent or non-persistent log(s) with the received or pulled updated data package(s). This may avoid that the same input data package(s) is / are stored multiple times in the persistent or non-persistent log(s), hence avoiding redundant validation operations on the data package(s) stored in stream storage system 1912.

[0328] Data transforming unit 1904 may be connected to the stream storage system 1912. Data consuming unit 1908 of data transforming unit 1904 may be connected to stream storage system 1912. Data consuming unit 1908 may be connected to one or more persistent or non-persistent logs (e.g. in this embodiment in log 1 1914 and log 2 1916) of stream storage system 1912 to ingest and process data package(s) stored within the log(s). The stream storage system 1912 may be in a publisher-subscriber relationship with the data consuming unit 1908. For instance, data in one or more the logs(s) may be periodically read (e.g. pulled) by data consuming unit 1908. 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 1912. 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 1908 to re-consume data packages by rewinding the integer to an old offset.

[0329] Data consuming unit 1908 may be connected to data validation unit 1910 of data transforming unit 1904. Data consuming unit 1908 may be configured to provide data packages gathered from stream storage system 1912 to data validation unit 1910 for validation of data included in said data packages. Data consuming unit 1908 may be configured to extract data from the data packages and provide the extracted data including an input material identifier or battery identifier to data validation unit 1910. Data validation unit 1910 may be configured to validate the extracted data based on one or more rule(s) retrieved from rule DB 1906, for example as described in the context of FIG. 19B. Validation may include applying one or more rule(s) retrieved from rule DB 1906 to the extracted data. The extracted data may be validated if at least a part of the applied rules is fulfilled. Applying the rule(s) to the extracted data may include comparing the combination of identifier and location data to a database storing such combinations of identifier(s) and associated location data. Applying the rule(s) to the extracted data may include comparing data point(s) present within one or more rule(s) to individual data point(s) present within the extracted data to be validated. Applying the rule(s) to the extracted data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the extracted data to be validated. Applying the rule(s) to the extracted data may include comparing the data defined in one or more rule(s) to the whole extracted data to be validated. The one or more rule(s) may be related to a data model associated with a battery passport associated with the battery. The data model may define data points to be included in the battery passport. Data type(s) and associated value(s) and / or value range(s) included in the data model may be included in the one or more rule(s). This may allow to verify whether gathered data fulfils the data type(s) and associated value(s) and / or value range(s) defined by the data model. By validating the extracted data against one or more rule(s) generated based on the data model, the number of validated data points (e.g. data points included in the asset and matching data points defined by the data model) included in the gathered asset can be determined. This may allow to determine a data completeness metric by comparing the number of validated data points to the number of data points defined by the data model.

[0330] In an embodiment, data validation unit 1910 may further be configured to determine the archive to which the validated data is to be persisted. The archive may be determined based on mapping data including a mapping between identifier(s) and associated archive data. The archive data may include endpoint(s) associated with said archive(s). The archive(s) may be identified by way of archive identifier(s) included in the archive data. Such identifier(s) may be used to gather endpoint(s) associated with such archive(s). The mapping data may include a first mapping between input material identifiers and input material type identifiers and a second mapping between input material type identifiers and associated archive data. The mapping data may further include a first mapping between battery identifiers and battery type identifiers and a second mapping between battery type identifiers and associated archive data. The mapping data may be stored in a database connected to data validation unit 1910 (not shown). Determining the archive of validated input material data may allow to persist validated data in archives associated with given applications or systems(s). For instance, the validated data associated with a given battery may be persisted in an archive associated with a given application processing such validated data, such as battery passport service 628. Processing may, for example include generation of data completeness metrics, generation of battery passports and / or updating of battery passports using such validated data, for example as described in the context of FIG. 20 to FIG. 25. Validated data which may not be mapped to a given application may be persisted in a general archive, such as archive general 1948.

[0331] Data validation unit 1910 may further be configured to provide the validated data to the determined archive, such as general archive general 1948 or archive DPP product type A 1950, for storage.

[0332] Data validation system may hence allow to validate gathered data associated with the production of the battery with respect to a data model associated with a battery passport of such a battery. This way, it can be determined how many data points included in the gathered data match data points defined by the data model. This allows to determine the degree of completeness of the gathered data associated with the production with respect to data defined by the data model by comparing the number of validated data points to the number of data points defined by the data model. This way, transparency on the degree of correlation between the accessible and validated data points and the data points defined by the data model and hence also transparency on the degree of completeness of the passport data generated by applying the data model to the validated data can be achieved.

[0333] FIG. 19B illustrates a diagram showing an example of validating data associated with the production of a battery using a rule-based engine included in the data validation unit described in the context of FIG. 19A.

[0334] Data validation unit 1920 may include rule based engine 1922. The rule based engine 1922 may operate on individual data point(s), multiple data point(s) and / or the gathered data. The rule based engine 1922 may operate on data gathered per identifier individually. This allows to validate gathered data per input material or per battery, hence allowing a more granular validation of the gathered data. Rule-based engine 1922 may receive a request to validate gathered data. The request may contain at least a part of the gathered data. Data packages (e.g. messages or events) may be consumed from one or more log(s) of stream storage system 1912 (see operation 1938) by data consuming unit 1908 as described in the context of FIG. 19A. The consumed data packages may be extracted by data consuming unit 1908 (see operation 1946). The extracted identifier may be provided to rule-based engine 1922. The rule based engine 1922 may have access to one or more rule(s). The rule-based engine 1922 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 1918. The one or more rule(s) or rule template(s) may be provided to rule DB 1918 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). The one or more rule(s) or the rule template(s) may be associated with battery type identifier(s) and / or battery identifier(s). Rule-based engine 1922 may generate a request to obtain one or more rule(s) from rule DB 1918. The request may contain the respective input material identifier(s) or battery identifier(s).

[0335] One or more rule(s) associated with the data to be validated (e.g. one or more applicable rule(s)) may be provided to rulebased engine 1922 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 data. The one or more rule(s) may be associated with battery / batteries produced from the input material associated with the input material data to be validated. The one or more rule(s) may be associated with or derived from a data model associated with a battery passport of the battery. Hence, the one or more rule(s) may ensure that data point(s) associated with input material(s) and the battery and being defined according to the semantic model may be included in the consumed data. The one or more rule(s) may relate to mandatory data point(s) defined by the data model. The one or more rule(s) may be generated based on the mandatory input material data point(s) present within the semantic model. This may ensure that mandatory data defined by the data model is included in the consumed data. The one or more rule(s) may be associated with input material identifier(s) and / or input material type identifier(s). The one or more rule(s) may be associated with battery identifier(s) and / or battery type identifier(s). A mapping table may be used to map input material identifier(s) to corresponding input material type identifier(s) and / or to map battery identifier(s) to corresponding battery type identifier(s). The input material type identifier(s) may be associated with input material type(s). The battery type identifier(s) may be associated with battery type(s). The mapping table may be stored in a separate database (not shown). Rule-based engine 1922 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). Rulebased engine 1922 may further be configured to gather battery type identifier(s) based on determined battery identifier's) and to request rule(s) based on the gathered battery type identifier(s). This may allow to gather rule(s) associated with input material type identifier(s) and / or battery identifier(s) based on respective input material identifier(s) and / or battery identifier(s), hence avoiding generation of rule(s) per identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1918.

[0336] Rule-based engine 1922 may be configured to initialize the rule engine (see operation 1926). Initialization of the rule engine may include generating rule data executable by a processor included in rule based engine 1922. 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 1928) to validate the consumed data according to the obtained rule(s). Execution of the logic may result in matching consumed data to data point(s) and / or combination(s) of data point(s) included in the executable logic, evaluating the consumed data with such data point(s) or combination(s) of data point(s) and generating validation result data based on the evaluation results. The validation result data may include a classifier and associated validated or non-validated data point(s). The classifier may be a binary classifier discriminating between validated and non-validated data. Consumed data point(s) may be considered validated if one or more rule(s) applied by rule-based engine 1922 are fulfilled. Applying the rule(s) to the consumed data may include comparing individual data point(s) present within the rule(s) to individual data point(s) present within the data to be validated to determine whether the data to be validated includes individual data point(s) required by such rule(s). Applying the rule(s) to the consumed data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the data to be validated to determine whether the data contains data point combinations required by such rule(s). Applying the rule(s) to the consumed data may include comparing the data defined in the rule(s) to the whole data set to be validated to determine whether the data set contains all data required by such rule(s). Operations performed by rule-based engine 1922 may be determined by rule(s) gathered from rule DB 1918. For instance, rule(s) gathered from rule DB 1918 may determine whether rule-based engine 1922 operates on individual data point(s) and / or multiple data point(s) of the consumed data and / or the whole data set(s).

[0337] Rule-based engine 1922 may be configured to determine whether the consumed data fulfils one or more applied rule(s) (see operation 1930). Consumed 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 data) if the consumed data does not include data point(s) required according to one or more obtained rule(s). Rule-based engine 1922 may indicate to data validation unit 1920 successful validation of the consumed data responsive to the determination that the consumed data is successfully validated (e.g. fulfils one or more obtained rule(s)). In response to receiving that indication, data validation unit 1920 may determine the target archive where the validated data is to be persisted (see operation 1940). The target archive may be determined as described in the context of FIG. 19A. If data validation unit 1920 determines that the validated data is not associated with a given application, data validation unit 1920 may provide the validated data to an archive not being associated with any application or service processing the validated data, such as archive general 1948. If data validation unit 1920 determines that the validated data is associated with a given application or service processing such data, for example battery passport service 628, data validation unit 1920 may provide the validated data to a storage being associated with such application or service processing the validated data stored therein, for example by generating data completeness metrics and / or by generating and / or updating battery passports.

[0338] If at least a part of the consumed data could not be validated, rule-based engine 1922 may indicate to data validation unit 1920 that at least a part of the consumed data could not be validated. In response to receiving the indication, data validation unit 1920 may generate message data (operation 1932). The message data may indicate that at least part of the consumed data could not be validated. The message data may include an indication which data point(s) of the consumed data could not be validated. The message data may be provided to a display device configured to display data received from data validation unit 1920. The display device may comprise a graphical user interface 1934. The display device may display the message in response to receiving message data from rule based engine 1922. This allows to trigger correction or updating of nonvalidated data points, for example by generating a request to provide updated data point(s) to the data source having provided the non-validated data points. Rule-based engine 1922 may be configured to provide non-validated data to an archive not being associated with any application processing the validated data, such as archive general 1948. The non-validated data may be provided to such storage along with a classifier classifying such data as non-validated. The non-validated data may be provided to such archive along with the classifier and rule data indicating the applied rule(s) resulting in non-validation of at least a part of such data.

[0339] FIG. 20 illustrates a flow chart of a further example of a method for validating a completeness of data accessible for generating and / or updating a battery passport associated with a battery. The completeness of the data may be validated with respect to the accessibility of such data for the generation of the battery passport and / or for updating an existing battery passport. The battery may be a battery as described in the context of FIG. 3A to FIG. 5. The battery may be produced from one or more input material(s) by a production chain. The input material(s) may correspond to output product(s) or intermediate product(s) produced by participants of the production chain. The production chain may include one or more production step(s) as described in the context of FIG. 6. The method illustrated in FIG. 20 may be implemented by the battery passport service 628 described in the context of FIG. 6 and FIG. 13.

[0340] Data associated with the battery may be provided. The data may be provided as described in the context of FIG. 18. Data associated with the battery may include battery identifier(s) associated with the battery and optionally input material identifier(s) associated with input material(s) used to produce the battery.

[0341] Validated data associated with the production of the battery may be gathered based on provided data associated with the battery. The validated data may be generated by gathering data associated with the production from a decentral network based on the data associated with the battery and by validating such gathered data using a rule-based engine including one or more rule(s) related to a data model associated with the battery passport. The data associated with the production of the battery may be gathered from decentral data providing node(s) based on data associated with data sources indicating data accessible for generating battery passports associated with batteries, for example as described in the context of FIG. 19A. The validated data may be generated as described in the context of FIG. 19A to FIG. 23. Gathering validated data may include determining input material identifier(s) based on the provided data associated with the battery. The input material identifier(s) may be determined from relationship representation(s) indicating relationships between a battery identifier of a battery and input material identifier(s) of input material(s) used to produce the battery. The relationship representation(s) may be included be stored in a database, for example as described in the context of FIG. 13 and FIG. 14B. The validated data may be gathered based on the provided data associated with the battery and the determined input material identifier(s). The validated data may be gathered from a storage storing such data. The storage may be associated with the entity generating the battery passport. The storage may be associated with the system generating the battery passport. The validated data may be gathered from one or more storages storing such validated data, for example as described in the context of FIG. 19A and FIG. 19B.

[0342] With reference to FIG. 21 and FIG. 22, gathering data associated with the production of the battery may include determining decentral data providing node(s) associated with the input material data based on the provided data associated with the battery. Determining such provider node(s) may include providing data associated with data sources indicating data accessible for generation and / or updating of battery passports. The data associated with data sources may include data set identifiers (also denoted as asset identifiers hereinafter) associated with data sets (also denoted as assets hereinafter) including data associated with the production of the battery and data sources data indicating the data sources associated with such data set identifiers. The data sets may include input material data associated with input material(s) used to produce the battery and / or battery data associated with the battery. Data source data may include endpoints associated with such data sources. Data source data may further include a decentral participant identifier related to the data source and / or a participant role associated with the participant of the battery ecosystem being associated with or controlling the data source. Data sources may include network node(s) configured to provide data, such as data accessible for generating and / or updating the battery passports, upon request of a further network node (e.g. a consumer node), for example as described in the context of FIG. 6, FIG. 12 and FIG. 19A. The data sources may be associated with a dedicated storage storing the provided data, for example as described in the context of FIG. 7A and FIG. 8. The data sources may be configured to exchange data based on a transaction protocol including authentication and / or authorization mechanism(s) as described in the context of FIG. 12 and FIG. 19A. The data associated with data sources may further include relationships between battery identifier(s) and associated input material identifier(s). The relationships may indicate the input material identifier(s) associated with a given battery identifier, for example as described in the context of FIG. 14B. Use of such relationship representation(s) allows to efficiently determine provider node(s) associated with the input material data and optionally battery data based on given battery identifier(s), hence resulting in a reduced latency associated with the gathering of the input material data and optionally the battery data. This way, data associated with the production of the battery may be efficiently validated and the validated data may be processed, for example by generating data completeness metrics and by generating and / or updating battery passports.

[0343] The data associated with data sources may be provided by providing a database storing such data associated with data sources indicating data accessible for generating and / or updating battery passports. The database may be a database as described in the context of FIG. 13, FIG. 14A and FIG. 24 (e.g. registry 1312).

[0344] Based on such data associated with data sources indicating data accessible for generating and / or updating battery passports and the provided data associated with the production, target data sources may be determined. Determining target data sources may include determining input material identifier(s) based on the battery identifier(s) included in the provided data associated with the battery. The input material identifier(s) may be determined by querying the data associated with the data sources using the provided data associated with the battery. Target data sources matching the battery identifier included in the data associated with the battery may be determined from such data associated with the data sources. In addition or alternatively target data sources matching the determined input material identifier(s) may be determined from such data associated with the data sources.

[0345] With continued reference to FIG. 21, access data for target data sources may be determined. The data associated with such target data sources data may be parsed to determine access data associated with such target data sources (e.g. provider node(s) associated with dedicated storage(s) storing input material data associated with provided input material identifier(s) or storing battery data associated with the provided battery identifier).

[0346] With continued reference to FIG. 21 , access to the data associated with the production of the battery may be requested from determined target data sources based on the determined access data and the determined and / or provided identifiers. Access to the data associated with the production of the battery may be requested as described in the context of FIG. 12 and FIG. 19A. The respective data may be provided by the target data sources in response to such a request, for example as described in the context of FIG. 12 and FIG. 19A.

[0347] With continued reference to FIG. 22 and with further reference to FIG. 19B, the rule-based engine may be a rule-based engine as described in the context of FIG. 19B. The gathered data may be validated by data validation unit 1910 described in the context of FIG. 19A and FIG. 19B. The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to an identifier included in the extracted data. The identifier associated with each applicable rule may include an identifier matching the identifier included in the extracted input material data. The identifier associated with each applicable rule may include a type identifier related to the identifier included in the extracted data. The type identifier related to the identifier included in the extracted data may be determined based on mapping data as described in the context of FIG. 19B. Executable logic may be generated from the one or more applicable rule(s). The executable logic may be generated by data validation unit 1910. 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 1910 may sent a response to data consuming unit 1908 indicating finalizing the generation of the executable logic.

[0348] Extracted input material data may be provided to data validation unit 1910 by data consuming unit 1908 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 1908 may sent a request to data validation unit 1910 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. By validating the gathered data by a rule-based engine including one or more rule(s) associated with the battery, data completeness metrics may be generated since validation allows to determine which data points defined by the data model are included in the gathered data. By validating the gathered data at the consumer side, the provider side may not be required to generate the gathered data using complex data models.

[0349] With continued reference to FIG. 22, it may be verified whether the extracted data could be validated according to one or more applicable rule(s) (e.g. one or more rule(s) gathered from rule DB 1918). If the extracted 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 2220 or block 2222. If only a part of the extracted data could be validated, message data may be generated, for example as described in the context of FIG. 19B. In block 2218, validation data including the non-validated data may be provided to an archive as previously described. If the extracted data could not be validated, message data may be generated, for example as described in the context of FIG. 19B. The validation data including the non-validated data may be provided to an archive, for example as described in the context of FIG. 19B.

[0350] Validated data may be linked to the battery identifier(s). This may allow to gather the validated data based on at least one of the battery identifiers, for example upon generating the data completeness metrics.

[0351] Validated data may be provided. Providing the validated data may include providing the validated data to an archive for storage (see also FIG. 19A and FIG. 19B). Providing the validated data may include providing the validated data for generation of the data completeness metric.

[0352] Turning back to FIG. 20, data related to data model associated with battery passport may be gathered based on data associated with battery. The data related to the data model may be gathered as described in the context of FIG. 18. The data related to the data model may include participant role(s) of participants associated with the production of the battery and the number of data points to be provided by such participant role(s) according to the data model as described in the context of FIG. 18. The data related to the data model may further include a digital battery identifier, such as a battery type identifier. Data related to the data model may be provided from a database storing such data by querying the database using the provided data associated with the battery.

[0353] A data completeness metric associated with data accessible for generating and / or updating the battery passport may be generated by determining a degree of correlation between the validated data and the data related to the data model based on the provided data associated with the battery. The degree of correlation may indicate the amount of data points included in the validated data with respect to the amount of data points defined by the data model and included in the data related to the data model. The data completeness metric may be a data completeness metric as described in the context of FIG. 17A to FIG. 17C.

[0354] The data completeness metric may be determined by a rule-based engine including one or more validation rule(s) configured to validate the completeness of the data accessible for generating and / or updating battery passports (e.g. accessible data), for example as described in the context of FIG. 18. The validation rule(s) may be configured to determine the degree of completeness by

[0355] • determining child identifiers based on the provided data associated with the battery,

[0356] • determining the number of validated data points based on the determined child identifier(s) and the battery identifier,

[0357] • determining the degree of correlation by comparing the number of validated data points with the number of data points defined in the data related to the data model.

[0358] The generated data completeness metric may be provided. The data completeness metric may be provided as described in the context of FIG. 18.

[0359] By validating the completeness of the data accessible for generating and / or updating battery passports associated with batteries based on gathered data, the degree of completeness of passport data included in the battery passports and hence the reliability of such passport data can be made transparent to battery passport generators and / or battery passport users. Determining the degree of completeness based on validated data allows a more granular transparency on the quality of the data available for passport generation and / or updating of existing battery passports. This transparency allows to generate or update battery passports based on a given or predefined degree of completeness, hence ensuring that the passport data included in the battery passports has a sufficient degree of completeness and thereof a sufficient degree of reliability. This way, it can be ensured that passport data required to ensure efficient further processing of the battery, such as efficient recycling of an end-of-life battery or a component thereof, is included in the generated and / or updated battery passports. Efficient further processing may enable a reduced environmental impact of the battery ecosystem and / or a higher circularity of materials and products used within the battery ecosystem. The transparency further allows to identify participants of the production chain of the battery not yet having generated and / or provided access to data to be included in the battery passports according to the data model associated with the battery passports. This way, participants can be requested to generate and / or provide access to such data to ensure a high degree of completeness of the generated and / or updated battery passports

[0360] FIG. 24 illustrates a system for generating a battery passport associated with a battery. The battery may be a battery as described in the context of FIG. 3A to FIG. 5. The battery may be produced from one or more input material(s) by a production chain. The production chain may include one or more production step(s) as described in the context of FIG. 6. The battery passport generator 1310 may be configured to perform the methods illustrated in FIG. 25 and FIG. 26. The battery passport may include one or more decentral identifier(s) and passport data as described in the context of FIG. 6.

[0361] The system may include an application 2426 and a battery passport generator 1310. The application 2426 may be connected to the battery passport generator 1310 via a communication interface, for example via an API. The application 2426 may include an authentication module 2428. The authentication module may be configured to authenticate a user. The authentication module 2428 may be configured to receive authentication data, such as a username and password, a digital credential indicating the user identity, from the user. The authentication module 2428 may be configured to verify or initiate verification of the received authentication data. Verification may be performed using an authentication protocol, such as OAuth and / or OpenlD Connect. The application 2426 may receive a token containing information about the user and the permissions granted to the user. The token may be passed along with a request to battery passport generator 1310 and may be used by battery passport generator 1310 to authenticate and authorize the request received from application 2426.

[0362] Application 2426 may further include an ID provider 2430. The ID provider 2430 may be configured to determine battery identifier(s) associated with the battery. The battery identifier(s) may uniquely identify the battery. The battery identifiers may include a batch number and / or a LOT number a part number, a serial number, a battery identification number or a vehicle identification number. The ID provider 2430 may include a code reader configured to read the code present on the physical entity of the battery and to determine the battery identifier based on the acquired data. The ID provider 2430 may include a camera configured to acquire image data of an identification number present on the physical entity of the battery and a unit configured to determine the identification number from the acquired image data. The ID provider 2430 may further be configured to provide the determined battery identifier(s) to a database, such as local db 2434, of application 2426 for storage. This way, a list of all batteries and associated battery identifier(s) related to a user may be stored in the database.

[0363] Application 2426 may further include a data refresher 2432 (or data refreshing unit). Data refresher 2432 may be configured to gather data, such as battery passports, stored in local db 2434 of application 2426, for example based on battery identifier(s) received from ID provider 2430. Data refresher 2432 may further be configured to provide the gathered data, for example for display within a user interface of application 2426. Data refresher 2432 may further be configured to generate a request for a battery passport and to provide the generated request to passport archive 630 in response to receiving a battery identifier from ID provider 2430. The request may be generated after determination that local db 2434 does not store a battery passport matching the received battery identifier(s).

[0364] The request may include the battery identifier(s) associated with the battery, the authentication data and optionally a date indicating last access by the application 2426 to the battery passport. The request may be provided directly to passport archive 630. The request may be provided via battery passport generator 1310 to passport archive 630 (not shown). Passport archive 630 or battery passport generator 1310 may be configured to authenticate and optionally authorize the request. Upon successful authentication and optionally authorization, passport archive 630 or battery passport generator 1310 may be configured to determine whether passport archive 630 contains a battery passport matching the data included in the received request, such as matching the battery identifier included in the received request. In addition, passport archive 630 or battery passport generator 1310 may further be configured to determine whether the respective battery passport has been updated with respect to the last time the battery passport was accessed by said application. For example, passport archive 630 or battery passport generator 1310 may be configured to compare the date indicating last access to the battery passport with a date indicating last update of such battery passport in passport archive 630. If such dates are matching or if the passport stored in passport archive 630 has been updated earlier than the data indicating last access, passport archive 630 or battery passport generator 1310 may be configured to provide the battery passport matching the received battery identifier(s) to data refresher 2432 of application 2426.

[0365] Providing the battery passport may include determining access policy data associated with the battery passport and applying the access policy data to the battery passport. The access policy data may be determined by battery passport generator 1310. The access policy data may be determined based on battery identifier(s) associated with the battery included in the received request. The access policy data may identify group access data associated with the battery passport and optionally associated consumer access data. The group access data may define consumer identifier(s) associated with data consumer(s) permitted to access the battery passport. The determined access policy data may be applied to the battery passport, for example by battery passport generator 1310.

[0366] Applying the access policy data may include validating whether the data consumer is permitted to access the battery passport, and responsive to validating access to the battery passport for the data consumer validating whether the data consumer is permitted to perform the requested action(s) on the battery passport.

[0367] In another example, applying access policy data may include validating whether the data consumer is permitted to access the battery passport, and responsive to validating access to the battery passport for the data consumer determining usage data associated with the validated data used to generate the battery passport and apply the determined usage data to the battery passport.

[0368] In yet another example, applying access policy data may include validating whether the data consumer is permitted to access the battery passport. Validating whether the data consumer is permitted to access the battery passport may include determining consumer identifier(s) based on the received authentication data. The consumer identifier(s) may be determined from data stored in registry 1312, for example from relationship representations mapping authentication data to consumer identifier(s) stored in registry 1312. The determined consumer identifier(s) may be mapped to consumer identifier(s) defined by the group access data. In addition, group access data associated with validated input material data associated with input material(s) used to produce the battery may be determined. The determined consumer identifier(s) may be matched with consumer identifier(s) defined by group access data associated with validated input material data. If the determined consumer identifier(s) match a consumer identifier defined by the group access data, the request may be authorized and the battery passport may be provided to data refresher 1520 of application 2426. If no match is found, passport archive 630 or battery passport generator 1310 may be configured to generate message data indicating a lack of authorization to access the battery passport. The message data may be provided to application 2426.

[0369] If the battery passport stored in passport archive 630 has been updated later than the date indicating last access, passport archive 630 or battery passport generator 1310 may be configured to provide the battery passport, to generate message data and to provide such message data to data refresher 2432. The message data may indicate that the battery passport has been updated since the last access. Data refresher 2432 may be configured to store the battery passport(s) received from passport archive 630 or battery passport generator 1310 in local db 2434 or to update battery passports stored in local db 2434 based on the data received from passport archive 630 or battery passport generator 1310.

[0370] If data refresher 2432 receives message data indicating that no battery passport is available for the provided battery identifier(s) from passport archive 630 or battery passport generator 1310, data refresher 2432 may be configured to generate a request for generation of such a battery passport. The request may include the battery identifier(s) associated with the battery, the authentication data, an application identifier, an endpoint of the application 2426 or a combination thereof. The request may be provided to battery passport generator 1310. The request may be provided to stream storage system 2402 of battery passport generator 1310.

[0371] The battery passport generator 1310 may be part of a battery passport service, for example battery passport service 628 as described in the context of FIG. 6. The battery passport generator 1310 may be configured to generate battery passports associated with batteries. The battery passport generator 1310 may be configured to update existing battery passports associated with batteries. The battery passports may be generated and / or updated in response to a request received from applications, such as application 2426.

[0372] The battery passport generator 1310 may be connected to an asset validation system, such as asset validation system 1314 described in the context of FIG. 13, FIG. 19A and FIG. 19B, configured to validate data gathered from data provider via a decentral network, for example as described in the context of FIG. 20 to FIG. 23. The battery passport generator 1310 may be connected to a data quality analyzer, such as data quality analyzer 1308 described in the context of FIG. 13, FIG. 15 and FIG. 16, configured to determine data completeness metrics, for example as described in the context of FIG. 18 to FIG. 18. The battery passport generator 1310 may be connected to the asset validation system and / or the data quality analyzer via a communication interface, such as an API. The battery passport generator may include a stream storage system 2402, a passport archive 630 and a data aggregator 2408. The passport archive 630 may store battery passports associated with batteries. The battery passports stored in passport archive 630 may be generated by battery passport generator 1310. The battery passports stored in passport archive 630 may be updated by battery passport generator 1310. The passport archive 630 may be configured to provide battery passports upon request, for example upon request of application 2426 and / or upon request of battery passport generator 1310.

[0373] Stream storage system 2402 may be configured to receive requests for battery passports from one or more applications, such as application 2426. Requests may be received via a communication interface, such as an API. Stream storage system 2402 may be configured to authenticate such requests, for example based on authentication data contained in such requests. The requests may represent a stream of data. Such a stream may be an ordered sequence of records or data packages received from applications 2426 relatively continuously, i.e. not in accumulated batches or chunks. A record may for example comprise a request for a battery passport for a given battery. 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 refresher 2432 may be configured to generate data package(s) including the battery identifier(s) received from ID provider 2430. A data package may be generated per battery. The data package may include further data, such as a time stamp, a date stamp, authorization data, an application identifier, an application endpoint or a combination thereof. The data package may represent a message or an event. The generated data package(s) may be provided to stream storage system 2402.

[0374] Stream storage system 2402 may be configured to store data packages received (e.g. pushed) from data refresher 2432. Data packages may be stored upon successful authentication. The stream storage system 2402 may be configured to provide the stored data to data aggregator 2408. The stream storage system 2402 may be configured to provide the stored data to data gathering unit 2410 of data aggregator 2408. Stream storage system 2402 may comprise one or more persistent or non-persistent logs 2404, 2406. In this embodiment, stream storage system 2402 comprises two persistent or non- persistent logs 2404, 2406 (i.e. log 1 2404 and log 2 2406). 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 refresher 2432. Stream storage system 2402 may provide a streaming service or stream processing service between one or more streaming sources (e.g. data refresher 2432) and one or more streaming sinks (e.g. log 1 2404 and log 2 2406).

[0375] Stream storage system 2402 may act as a persistent or non-persistent stream sink for requests for battery passports received from applications 2426. For example, open-source software systems such as Apache Kafka ("Kafka") or Azure Event Hubs may act as a persistent stream sink.

[0376] Stream storage system 2402 may be configured to pull data package(s) from the applications 2426. For instance, stream storage system 2402 may be configured to request data package(s) from the applications 2426 at regular time intervals.

[0377] Stream storage system 2402 may be configured to determine if the received or pulled data package(s) is / are already contained in the one or more persistent or non-persistent logs as described in the context of FIG. 19A.

[0378] Data aggregator 2408 may be connected to the stream storage system 2402. Data gathering unit 2410 of data aggregator

[0379] 2408 may be connected to stream storage system 2402. Data gathering unit 2410 may be connected to one or more persistent or non-persistent logs (e.g. in this embodiment in log 1 2404 and log 2 2406) of stream storage system 2402 to ingest and process data package(s) stored within the log(s). The stream storage system 2402 may be in a publishersubscriber relationship with the data gathering unit 2410. For instance, data in one or more the logs(s) may be periodically read (e.g. pulled) by data gathering unit 2410. 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 2402. 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 gathering unit 2410 to re-consume data packages by rewinding the integer to an old offset.

[0380] Data gathering unit 2410 may be configured to gather data associated with the production of the battery based on the data ingested from stream storage system 2402. Data gathering unit 2410 may be configured to determine input material identifier(s) associated with input material(s) used to produce the battery based on the battery identifier included in the ingested data. For example, data gathering unit 2410 may query registry 1312 for input material identifier(s) based on the battery identifier(s) included in the ingested data. In addition or alternatively, data gathering unit 2410 may be configured to initiate determination of input material identifier(s) associated with input material(s) used to produce the battery associated with the battery identifier(s) included in the ingested data. Such determination may be initiated by generating a request including the battery identifier(s) and providing such request to decentral network node 632 associated with battery passport generator 1310. Decentral network node 632 may be configured to generate a request to a further decentral network node configured to determine such input material identifier(s) based on received battery identifier(s). The further network node may be configured to determine decentral input material identifier(s) associated with input material(s) used to produce the battery based on the receive battery identifier(s) by querying the decentral network and to return the determined decentral input material identifiers to network node 632. The determined input material identifier(s) may be returned via node 632 to data gathering unit 2410.

[0381] Data gathering unit 2410 may further be configured to gather validated data associated with the production of the battery from a database associated with asset validation system 1314, such as archive DPP product type A 1950. Asset validation system 1314 may include or be associated with one or more databases storing validated data associated with the production of the battery. The validated data may be generated and stored in such database as described in the context of FIG. 19A to FIG. 23. The validated data may be gathered based on the battery identifier(s) associated with the battery and input material identifier(s) associated with input material(s) used to produce the battery. Alternatively or in addition, data gathering unit 2410 may be configured to request gathering and validation of data associated with the production of the battery by asset validation system 1314. The request may include the battery identifier(s) associated with the respective battery and optionally input material identifier(s) associated with input material(s) used to produce the battery. In response to the request, asset validation system 1314 may be configured to gather and validate data associ...

Claims

CLAIMS1 . A computer-implemented method for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising: providing data associated with the battery including at least one digital battery identifier associated with the battery; providing data associated with data sources indicating data accessible for generating and / or updating battery passports associated with batteries; gathering data related to a data model associated with the battery passport based on at least one of the digital battery identifiers; generating a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the data associated with the data sources and the data related to the data model, providing the generated data completeness metric.

2. The method of claim 1, wherein the data associated with data sources further indicates data sources providing the data accessible for generating and / or updating the battery passports.

3. The method of claims 1 or 2, wherein the data associated with data sources includes data set identifiers associated with data sets including data associated with the production of the battery and data sources data indicating the data sources associated with such data set identifiers.

4. The method of any one of claims 1 to 3, wherein the degree of correlation is determined by determining - based on the digital battery identifier and the data associated with the data sources - data sources data indicating data sources providing data sets associated with the digital battery identifier, determining - based on the digital battery identifier and the data associated with the data sources - input material identifier(s) and associated data sources data indicating data sources providing data sets associated with the input material identifier(s), mapping the determined data source data indicating data sources providing data sets associated with the input material identifier(s) to the data related to the data model associated with the battery passport.

5. A computer-implemented method for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising: providing data associated with the battery including at least one digital battery identifier associated with the battery, providing validated data associated with the production of the battery based on the at least one digital battery identifier, wherein the validated data is generated by gathering - based on the provided digital battery identifier(s) - data associated with the production of the battery from decentral data providing node(s) associated with the data associated with the production by a decentral data consuming node and validating atleast a part of the gathered data using a rule-based engine including one or more rule(s) related to a data model associated with the battery passport, gathering data related to the data model associated with the battery passport based on at least one of the digital battery identifiers; generating a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the validated data and the data related to the data model, providing the generated data completeness metric.

6. The method of any one of claims 1 to 5, wherein the amount of data accessible for generating and / or updating the battery passport includes input material data associated with at least a part of the input material(s) used to produce the battery and / or battery data associated with the battery.

7. The method of any one of claims 1 to 6, wherein the data related to the data model includes participant role(s) of participants of the production chain producing the battery and a number of data points to be provided by such participant role(s) according to the data model.

8. The method of any one of claims 1 to 7, wherein the degree of correlation is determined by a further rule based- engine including one or more validation rules configured to validate a completeness of the data accessible for generating and / or updating the battery passport based on the data related to the data model associated with the battery passport or wherein the degree of correlation is determined by the rule based-engine, wherein the rule-based engine further includes one or more validation rules configured to validate a completeness of the data accessible for generating and / or updating the battery passport based on the data related to the data model associated with the battery passport.

9. The method of any one of claims 5 to 8, wherein the degree of correlation is determined by comparing a number of validated data points with a number of data points included in the data related to the data model associated with the battery passport.

10. An apparatus for validating an amount of data accessible for generating and / or updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the apparatus comprising: a data providing interface configured to provide data associated with the battery including at least one digital battery identifier associated with the battery, a data storage configured to provide data associated with data sources indicating data accessible for generating and / or updating battery passports associated with batteries; a data gathering unit configured to gather data related to a data model associated with the battery passport based on at least one of the digital battery identifiers; a metric generator configured to generate a data completeness metric associated with the data being accessible for generating and / or updating the battery passport by determining a degree of correlation between the data associated with the data sources and the data related to the data model,a data providing interface configured to provide the generated data completeness metric.

11. A computer-implemented method for generating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising: providing data associated with the battery including at least one digital battery identifier associated with the battery, generating a data completeness metric associated with data being accessible for generating the battery passport according to the method of any one of claims 1 to 9 or by the apparatus of claim 10, validating the determined data completeness metric by comparing the data completeness metric to given data completeness threshold(s), based on the validated data completeness metric, gathering data associated with the production of the battery based on the data associated with the battery and / or the generated data completeness metric, generating the battery passport based on the gathered data associated with the production of the battery and providing the generated battery passport and optionally the data completeness metric for access.

12. The method of claim 11, wherein the given completeness threshold(s) define one or more degree(s) of correlation between the data being accessible for generating the battery passport and data points defined by the data model associated with the battery passport.

13. The method of claim 12, wherein a degree of correlation is defined for the total degree of correlation between the data being accessible for generating the battery passport and the data points defined by the data model associated with the battery passport, and / or wherein the degree of correlation is defined for data points to be provided by the one or more participants of the production chain producing the battery according to the data model, and / or wherein the degree of correlation is defined per participant of the production chain producing the battery and required to provide data according to the data model associated with the battery passport.

14. The method of any one of claims 11 to 13, wherein generating the battery passport includes providing a decentral identifier associated with the gathered data and a data model associated with the battery passport, applying the data model to the gathered data to generate passport data and generating the battery passport including the decentral identifier and the passport data.

15. A computer-implemented method for updating a battery passport associated with a battery, wherein the battery is produced from one or more input material(s) by a production chain, the method comprising: providing data associated with the battery including at least one digital battery identifier associated with the battery, providing the battery passport including a decentral identifier and at least one of the digital battery identifiers, generating a data completeness metric associated with data being accessible for updating the battery passport according to the method of any one of claims 1 to 9 or by the apparatus of claim 10, gathering data associated with the production of the battery based on the data associated with the battery and / or the data completeness metric,updating the battery passport based on the gathered data associated with the production of the battery and providing the updated battery passport and optionally the data completeness metric for access.

Images