Bi-PAN: Bidirectional Product Lifecycle Network

• The paper introduces Bi-PAN—a lifecycle-oriented extension of PAN—that supports both forward manufacturing and reverse disassembly through a unified bidirectional graph model.
• Bi-PAN is a graph-based framework that integrates product, process, and resource data with clear bidirectional semantics, enabling automated derivation of assembly and disassembly procedures.
• Bi-PAN’s role in digital twins ensures lifecycle continuity and flexible end-of-life strategies, as demonstrated in the EV battery use case for efficient remanufacturing and recycling.

Searching arXiv for Bi-PAN and closely related PPR/PAN papers. Bi-Flow Product-Process-Resource Asset Network (Bi-PAN) is a lifecycle-oriented extension of the Product-Process-Resource Asset Network (PAN) in which a product digital twin supports not only manufacturing but also end-of-life operations such as disassembly, remanufacturing, repair, and recycling. Its defining property is “Bi-Flow”: a single coherent graph supports both the forward/manufacturing flow and the backward/remanufacturing/disassembly/recycling flow, so that assembly procedures and recovery procedures can be derived from one persistent model rather than from separate engineering representations (Strakosova et al., 2 Oct 2025).

1. Conceptual background and problem setting

Bi-PAN emerges from PAN, which is described as “a graph-based formalism for expressing relationships among products, production processes, and resources.” PAN belongs to the broader Product, Process, Resource (PPR) tradition, but its distinctive role is to make dependencies explicit as a network of engineering assets rather than leaving them distributed across isolated tools or documents. In manufacturing engineering, PAN is intended to capture and share knowledge among engineers and engineering tools, identify changes during engineering, and coordinate multidisciplinary production-system design. The PAN paradigm “virtualiz[es] assets, operations, and resources and especially [maps] and [connects] them together by explicitly specified links,” thereby linking what the product is, how it is assembled, and what resources are required (Strakosova et al., 2 Oct 2025).

The motivation for Bi-PAN is the insufficiency of assembly-centric lifecycle representations in circular-economy settings. The original PAN was effective for “capturing expert knowledge relevant for multi-disciplinary mechatronic production systems,” but it did not provide support for remanufacturing or recycling processes. For electric vehicle batteries, assembly knowledge alone is inadequate: end-of-life handling requires explicit knowledge of safe removal sequences, detachable connectors and fasteners, resource requirements for disassembly, and route selection among repair, reuse, module replacement, and recycling according to the condition of the individual battery (Strakosova et al., 2 Oct 2025).

In a broader modeling lineage, FBS-PPR had already characterized the lifecycle of an industrial product as a network of business processes in which material and informational products are both inputs and outputs, and later system-of-systems lifecycle work described products as nodes in larger technical, organizational, and digital networks rather than as isolated artifacts (Labrousse et al., 2010, Salehi et al., 31 Oct 2025). This suggests that Bi-PAN belongs to a wider transition from linear lifecycle descriptions toward heterogeneous network representations with explicit cross-phase traceability.

2. Model structure and bidirectional semantics

Bi-PAN preserves PAN’s three basic element types—products, processes, and resources—but extends their semantics so that reverse flows and lifecycle-aware product states can be represented in the same graph. In the PAN/Bi-PAN visual language, products are shown as red circles, processes as green rectangles, and resources as blue rounded rectangles. Black arrows connect products and processes to form a production plan, while yellow markers associate process steps with required resources or resource skills. The result is not merely an enriched bill of materials: it is a typed graph linking product structure, transformation logic, and execution capability (Strakosova et al., 2 Oct 2025).

The “Bi-Flow” notion is explicit. The forward direction corresponds to manufacturing, that is, assembly from parts to final product. The backward direction corresponds to remanufacturing, disassembly, and recycling, that is, decomposition of the final product into stages, subassemblies, fasteners, modules, and recoverable elements. The same graph is traversed differently depending on the use case: downward for assembly and upward or backward for disassembly (Strakosova et al., 2 Oct 2025).

A central extension is the introduction of product categories with lifecycle and disassembly semantics:

• Elementary Product: “A product that cannot be further disassembled.”
• SubProduct: “A product that is considered elementary in terms of decomposition within the extended PAN. It is composed of several parts and can be further disassembled.”
• Fastener Product: “This type of product serves as a fastener for other products.”
• Final Product: “The finished product, ready for use or sale.”
• Product in Stage: “An intermediate stage of the final product, representing a partially assembled or processed product within the production or disassembly process.”

These categories do more than refine nomenclature. “Product in Stage” makes intermediate lifecycle states explicit, while “Fastener Product” captures parts that constrain or enable access. The paper notes that the distinction between elementary and composite products improves human readability and is also useful for automated processing of PAN graphs (Strakosova et al., 2 Oct 2025).

Bi-PAN does not introduce a separate mathematical formalism. There are no explicit set-theoretic definitions, graph tuples, adjacency expressions, or optimization equations. The formal content is conveyed through a typed graph model, node taxonomy, and traversal semantics. This absence of closed-form graph algebra is itself a defining feature of the present formulation: Bi-PAN is specified operationally and semantically rather than axiomatically (Strakosova et al., 2 Oct 2025).

3. Role within the product digital twin

Within the paper’s architecture, Bi-PAN is the backbone representation of a Product Digital Twin (PDT). The PDT is defined as a digital twin specifically for product lifecycle management; it stores design data, composition data, maintenance and service data, operational data, and lifecycle-acquired data. For end-of-life decision-making, the PDT must contain not only component information but also dependencies among components and generalized disassembly knowledge. Accordingly, the PDT is structured to represent the product’s components and their relationships rather than one fixed disassembly procedure, because multiple disassembly strategies may exist. Bi-PAN is the representation used to visualize and operationalize this generic disassembly plan (Strakosova et al., 2 Oct 2025).

This allows the PDT to answer lifecycle queries that are structurally difficult in assembly-only models: what sequence of operations is needed to reach a target component, which components must be removed first, what tools or robot skills are required, whether a target state is reachable by combining disassembly and reassembly, and how to generate a procedure for a particular repair or recycling route. The paper links this directly to individualized end-of-life handling, since each battery instance may arrive with a distinct use history and therefore a distinct feasible recovery path (Strakosova et al., 2 Oct 2025).

The operational workflow described in the paper is sequential but graph-backed. Product structure and dependencies are first captured, for example in AutomationML. That structure is then linked to process nodes and resource skills to form the Bi-PAN. During operation and service, the PDT accumulates history. At end of life or upon repair need, the system determines a target state and route, such as full disassembly, module extraction, or staged teardown for material recovery. A specific executable recipe is then extracted from the generic bidirectional network as a directed procedure suitable for manual execution or for a flexible production or disassembly system (Strakosova et al., 2 Oct 2025).

The claimed benefits of the PDT in this setting are design and simulation of remanufacturing or recycling before the physical product arrives, individualized handling of each product, real-time monitoring and adaptation during remanufacturing or recycling, and lifecycle data collection to improve future design and remanufacturing efficiency. A plausible implication is that Bi-PAN gives the PDT its operative lifecycle continuity: it retains manufacturing knowledge in a form that remains actionable during repair, remanufacturing, and recycling rather than becoming archival residue.

4. Electric vehicle battery use case

The paper demonstrates Bi-PAN on a simplified BMW i3 electric vehicle battery. This domain is used because all three end-of-life paths are relevant: recycling for material recovery, repair or remanufacturing by replacing bad parts, and transformation into modular units for second-life stationary energy storage. AutomationML is used in the PDT to capture component hierarchy and dependencies, including positional information in the battery coordinate system; Bi-PAN complements this by linking product structure to processes and required resources (Strakosova et al., 2 Oct 2025).

The assembly path is represented explicitly as a progression through intermediate stages. First, screws, the cooling system, and the battery box are inserted into a single assembly by a process requiring manipulation and screwing skills, producing Stage 1. Second, Stage 1 together with bolts, BMS cables, and eight modules enters a process requiring manipulation, screwing, and connecting cables, producing Stage 2. Third, Stage 2 together with bolts and five braces enters a process requiring manipulation and screwing, producing Stage 3. Fourth, Stage 3 plus the isolation blanket enters a manipulation process, producing Stage 4. Finally, Stage 4 together with screws and a cover enters a process requiring manipulation and screwing, producing the Final Product, the assembled EV battery (Strakosova et al., 2 Oct 2025).

The same sequence is traversed backward for remanufacturing or recycling. The paper states that in reverse flow, individual product types are removed instead of inserted; at the resource-skill level, fasteners are unscrewed instead of screwed, cables and connectors are disconnected instead of connected, and analogous inverse operations are required. This is a crucial semantic point: the reverse direction is not merely topological inversion of graph edges, but inverse operational capability grounded in resource skills (Strakosova et al., 2 Oct 2025).

The selected remanufacturing scenario is replacement of a broken module. The specific recipe begins with the Final Product, follows a disassembly path back to Stage 2, removes the damaged module, inserts a new module, and then follows the assembly path forward to return to the Final Product. The extracted case-specific procedure is represented with single-directional arrows, in contrast to the generic Bi-PAN’s bidirectional arrows. The significance is structural rather than anecdotal: one graph supports hybrid procedures combining disassembly and reassembly in one continuous repair plan (Strakosova et al., 2 Oct 2025).

5. Interoperability and related models

Bi-PAN is presented as compatible with industrial standards such as ISA-95 and AutomationML, and future work is stated explicitly as better integration with the Asset Administration Shell (AAS) for EV batteries. In the current implementation, AutomationML provides the product-structure model inside the PDT, while Bi-PAN functions as the backbone representation connecting product, process, and resource data (Strakosova et al., 2 Oct 2025).

A closely related model is the product-oriented Product-Process-Resource Asset Network (PoPAN), which likewise seeks lifecycle continuity, especially for disassembly, remanufacturing, and upcycling of EV batteries. PoPAN places the product structure graph at the center, assigns processes to product components, links resources to processes, and serializes the representation in AutomationML for AAS-oriented exchange. Its dual arrow semantics—open arrows for assembly direction and full arrows for disassembly direction—show a product-centric route toward a unified assembly/disassembly graph. PoPAN is therefore best understood as a related product-oriented variant rather than as a synonym for Bi-PAN (Strakosova et al., 1 Oct 2025).

Another adjacent line is the Product-Process-Resource Asset Knowledge Graph (PPR-AKG), an OWL ontology that extends PPR with required and provided capabilities, undesired conditions, and plausible causes for flexible cyber-physical production systems. In the electric vehicle battery remanufacturing validation, PPR-AKG supports capability-based resource allocation and diagnosis of undesired conditions, including LLM-mediated natural-language interaction. It does not explicitly define a bi-flow formalism, but it provides a semantic asset-network substrate in which forward execution dependencies and backward causal explanation coexist (Novak et al., 8 Aug 2025).

At a higher systems level, system-of-systems lifecycle management work has argued for MBSE as the semantic backbone, PLM as the governance and configuration layer, CAD/CAE as derived domain realizations, and digital thread and digital twin as continuous lifecycle feedback. That framework does not define Bi-PAN, but it offers a broader architectural context in which a PAN-derived lifecycle graph can be interpreted as one component of a network-centric lifecycle stack (Salehi et al., 31 Oct 2025). An earlier conceptual precursor is FBS-PPR, which already modeled lifecycle stages as a network of business processes and treated enterprise objects as context-dependent products, processes, or resources, with both material and informational products flowing through the network (Labrousse et al., 2010).

6. Assessment, trade-offs, and open issues

Bi-PAN is explicitly compared with conventional digital twin design in an evaluation table that uses a Likert-like notation:

Approach	Capability	Rating
Conventional DT	Product assembling	++
Conventional DT	Product disassembling	----
Conventional DT	Product remanufacturing	----
Bi-PAN DT	Product assembling	+
Bi-PAN DT	Product disassembling	+
Bi-PAN DT	Product remanufacturing	++

The paper explains this as a trade-off. Conventional digital twins are strong for their original scope—assembly and manufacturing—but weak or absent for disassembly and remanufacturing. Bi-PAN is slightly more complex and requires approximately 10–20% more modeling effort and time, which is why assembly support is rated somewhat lower, but it gains the ability to support both directions in a single model and thus to make repair and remanufacturing feasible without maintaining a separate reverse-lifecycle representation (Strakosova et al., 2 Oct 2025).

Several misconceptions are directly addressed by the model’s structure. Bi-PAN is not merely PAN with arrows reversed. It adds lifecycle-aware product categories, explicit intermediate product states, fastener semantics, reverse resource-skill interpretation, and the extraction of case-specific executable recipes from a generic bidirectional graph. Nor is it simply a bill of materials plus routing data: its central purpose is to preserve a persistent lifecycle representation from which both assembly and end-of-life procedures can be derived (Strakosova et al., 2 Oct 2025).

The limitations are equally explicit. The electric vehicle battery example is a simplified BMW i3 model rather than a complete real-world battery ontology. The authors state that a more detailed PAN model for a selected EV battery still needs to be built and discussed with an actual car vendor. They also identify scalability and “potential limitations of this approach in the real-life scale” as open issues. The approach assumes availability and sharing of relevant manufacturer data, even though lack of such sharing is itself part of the original problem statement. Integration with AAS is still future work rather than a completed component of the reported implementation (Strakosova et al., 2 Oct 2025).

Taken together, these constraints position Bi-PAN as a conceptual and demonstrative lifecycle extension rather than a fully industrialized formalism. Its principal significance lies in making the product digital twin genuinely bidirectional: the same representation can encode how a product was built, how it can be safely opened, how a damaged component can be replaced, and how lifecycle knowledge can be retained for recycling or second-life use. In circular-economy settings, especially for electric vehicle batteries, that persistent bidirectional representation is the core contribution of Bi-PAN (Strakosova et al., 2 Oct 2025).