Product–Process–Resource Asset Knowledge Graph
- Product–Process–Resource Asset Knowledge Graph (PPR-AKG) is an ontology that extends the classical PPR model with explicit asset, capability, and condition semantics for flexible CPPS.
- It employs a structured TBox/ABox separation and typed graph execution that enable dynamic resource allocation and efficient querying via LLM-mediated interfaces.
- The model integrates lifecycle planning, digital twin concepts, and causal reasoning to support capability-centric operations, condition analysis, and end-of-life strategies.
The Product–Process–Resource Asset Knowledge Graph (PPR-AKG) is an OWL ontology and industrial knowledge graph that extends the classic Product–Process–Resource (PPR) model with explicit asset, capability, undesired-condition, causal, and mitigation semantics for flexible cyber-physical production systems (CPPS). It is grounded in VDI 3682, ISA-95, and IEC 62264, and is intended to support capability-based planning, dynamic resource allocation, analysis of undesired conditions, and natural-language interaction with production knowledge. In adjacent work on industrial asset operations, typed knowledge graphs also function as the data layer behind deterministic querying and LLM-mediated query generation, which broadens the significance of PPR-AKG from ontology design to execution architecture (Novak et al., 8 Aug 2025, Mandarapu et al., 26 May 2026).
1. Conceptual lineage and scope
PPR-AKG inherits the triadic backbone of Product, Process, and Resource, but situates it within a broader enterprise-knowledge tradition in which the same enterprise object can play different roles depending on process context. In the FBS-PPR(E) model, product, process, and resource are circumstantial roles rather than intrinsic types, and enterprise knowledge is organized through Function, Behavior, Structure, and External/Environment constraints. That model treats lifecycle phases as a network of business processes, with material products and informational materials acting as both inputs and outputs, and it motivates standardization across product modeling, process modeling, resource modeling, and knowledge engineering for efficient retrieval and capitalization (Labrousse et al., 2010).
Within this lineage, PPR-AKG preserves the PPR backbone while adding three extensions that are central in flexible CPPS: capability-centric matchmaking, explicit representation of undesired conditions and plausible causes, and LLM-based human-in-the-loop access. The stated objective is to address limitations of conventional model-driven engineering and traditional fishbone diagrams under Industry 4.0 conditions, where products may be made on different resources via variant processes, capabilities may be added or removed on the fly, and undesired conditions must be represented at both asset and system scope (Novak et al., 8 Aug 2025).
Closely related variants emphasize lifecycle breadth and product orientation. Bi-Flow Product-Process-Resource Asset Networks (Bi-PAN) extend PAN to encode both forward manufacturing and backward disassembly/remanufacturing/recycling flows within one network, while PoPAN places product structure at the center and embeds the resulting digital shadow in the product’s Asset Administration Shell (AAS). Together, these variants show that PPR-derived knowledge models are not limited to production planning; they also serve persistent product digital twins and end-of-life reasoning (Strakosova et al., 2 Oct 2025, Strakosova et al., 1 Oct 2025).
2. Ontology architecture and formal semantics
The PPR-AKG ontology is organized through a TBox/ABox separation. Its core classes include Product, Process, Resource, Asset, Capability, RequiredCapability, ProvidedCapability, Operation, Task, Plan, UndesiredCondition, DesiredState, Error, QualityCriterion, Sensor, and Workcell. Key object properties include requiresCapability from Process to RequiredCapability, providesCapability from Resource to ProvidedCapability, hasOperation from Capability to Operation, usesResource from ProcessInstance to Resource, hasUndesiredCondition from Process or Resource to UndesiredCondition, hasPlausibleCause from UndesiredCondition to Cause, mitigatedByAction from UndesiredCondition to MitigationAction, and hasPrecondition and hasPostcondition from Operation or Process to State. Disjointness axioms separate core concepts such as Product, Process, and Resource, and the model distinguishes class-level design for Products and Processes from instance-level representation of Resources, enabling multiple concurrent instantiations while keeping actual assets concrete (Novak et al., 8 Aug 2025).
The conformance constraints are explicit. Process is modeled at the class or type level, Resource at the instance level; each Process type must declare at least one RequiredCapability; each Resource instance must declare at least one ProvidedCapability; and undesired conditions and plausible causes may be scoped either to specific resources or globally to the production system. The formal summary given for the model is:
with Product, Process, and Resource pairwise disjoint, and with the property chain
used to derive operational eligibility (Novak et al., 8 Aug 2025).
For graph-database implementations, the same semantics are often rendered as typed nodes and relationships. A PPR-AKG inspired by the industrial asset-operations graph uses labels such as Product, Process, Resource, Asset, Component, Task, Procedure, Sensor, Document, Location, FailureMode, WorkOrder, and Event, together with relationships such as PRODUCES, CONSUMES, REQUIRES, DEPENDS_ON, PART_OF, MAINTAINED_BY, EXECUTED_BY, LOCATED_AT, MEASURES, DESCRIBES, FOR_EQUIPMENT, INVOLVES_FAILURE_MODE, and MONITORS. This property-graph formulation preserves typed topology, audit fields, and embeddings while remaining consistent with the typed, relationship-rich design advocated for industrial operations (Mandarapu et al., 26 May 2026).
3. Capability-centric allocation and condition-aware reasoning
A defining feature of PPR-AKG is that processes are assigned required capabilities rather than fixed resources, while assets and resources provide capabilities. RequiredCapability captures what a process step needs, and ProvidedCapability captures what a resource can do. Matching relies on shared operations and compatibility constraints, allowing dynamic selection of resources and supporting continuous engineering when capabilities are added or removed during operation. This departs from conventional PPR implementations that bind processes directly to fixed resources and thereby reduce reconfiguration flexibility (Novak et al., 8 Aug 2025).
Undesired conditions are represented as first-class knowledge objects. The model admits generic and specific subclasses such as Error, Delay, CollisionRisk, and QualityNonConformance; conditions may be asset-specific or system-level; attributes such as severity, timestamp, affectedProduct, affectedProcessSegment, and affectedResource may be attached; and plausible causes are linked through hasPlausibleCause. Mitigation actions are linked explicitly through mitigatedByAction, and preconditions and postconditions on operations support violation detection. The motivating EV battery remanufacturing scenario illustrates this with late arrival of battery packs, fixture misalignment, sensor drift affecting quality checks, screws not removable due to corrosion, and safety constraints violated when state-of-charge is high (Novak et al., 8 Aug 2025).
The logical layer is intended for inference and actionable decision support. Representative rules consistent with the published model infer a match when a RequiredCapability and a ProvidedCapability share an operation, derive allocation recommendations from those matches, and recommend mitigations when a process is linked to an undesired condition, a plausible cause, and a mitigation for that cause. The corresponding SPARQL pattern retrieves, for each process with an undesired condition, candidate resources that provide matching capabilities and any available mitigation. Because the paper does not publish concrete SWRL rules, these rule forms are best understood as consistent design patterns rather than fixed canonical axioms (Novak et al., 8 Aug 2025).
The same graph is also intended for human-in-the-loop querying. The described LLM interface translates questions such as “Why did the battery not arrive in time?” into graph-grounded retrieval of undesired conditions related to transport, plausible causes such as AGVDelay, and mitigations such as RerouteAGV. The interface is therefore secondary to the ontology: its utility depends on the explicit capability and condition semantics already present in the graph (Novak et al., 8 Aug 2025).
4. Lifecycle integration, digital twins, and product-oriented variants
PPR-AKG has been extended beyond shop-floor planning into lifecycle-oriented product digital twins. In the EV battery end-of-life setting, PAN is extended to Bi-PAN so that both assembly and disassembly/remanufacturing/recycling are represented within one network. The model retains Product, Process, and Resource as core node types, but adds bi-directional flow semantics, resource skills, and staged product states. Product nodes are categorized as Elementary Product, SubProduct, Fastener Product, Final Product, and Product in Stage; Process nodes encode operations; Resource nodes encode equipment, tools, or skills; and arrows encode assembly or disassembly flow (Strakosova et al., 2 Oct 2025).
The EV battery example makes this staging concrete. Stage 1 yields an intermediate state after inserting screws, cooling system, and battery box; Stage 2 adds bolts, BMS cables, and eight modules; Stage 3 adds bolts and five braces; Stage 4 adds an isolation blanket; and the Final Product adds screws and cover. Disassembly reverses those transformations and reverses skill semantics, such as unscrewing instead of screwing and disconnecting instead of connecting cables. When a module’s state-of-health is below threshold, the product digital twin queries the Bi-PAN to extract a case-specific, single-direction module-replacement plan that disassembles to the relevant stage, replaces the target module, and re-assembles to the final state (Strakosova et al., 2 Oct 2025).
Evaluation in that work is qualitative but informative. A Likert-scale comparison reports that a conventional digital twin strongly supports assembling but has weak or absent support for disassembling and remanufacturing, whereas a Bi-PAN-based digital twin supports assembling, supports disassembling, and strongly supports remanufacturing, with approximately 10–20% modeling effort overhead due to the bi-directional representation. This suggests that lifecycle coverage is gained through additional semantic structure rather than through purely algorithmic change (Strakosova et al., 2 Oct 2025).
PoPAN further shifts emphasis toward the product structure itself. It defines product categories such as ElementaryProduct, SubProduct, FastenerProduct, InitialProduct, and LastProduct; links products to processes through LinkingP2P; sequences processes through SequenceProcess; links processes to resources through LinkingP2R; and serializes the network in AutomationML for integration with the Asset Administration Shell. In this formulation, PoPAN functions as a digital shadow encapsulated within the product’s AAS, carrying structure, process applicability, resource linkage, and lifecycle evolution. This suggests a product-oriented route for implementing PPR-AKGs where lifecycle analytics and end-of-life strategies are treated as first-class citizens rather than downstream add-ons (Strakosova et al., 1 Oct 2025).
5. Typed graph execution and LLM-mediated querying
A major architectural development related to PPR-AKG is the treatment of the knowledge graph as the execution substrate for industrial operations. In “Knowledge Graphs as the Missing Data Layer for LLM-Based Industrial Asset Operations,” the key question is not which orchestration paradigm to use, but how much the data model behind the tools affects agent performance. On AssetOpsBench scenarios backed by CouchDB, YAML, and CSV, the original tool-augmented GPT-4 baseline achieves 65% (91/139). Replacing the flat data layer with a typed knowledge graph and inverting LLM usage produces three results on the same scenarios: deterministic graph handlers without an LLM reach 99% (137/139), LLM-generated Cypher over the graph reaches 82–83%, and the original document-based baseline remains at 65%. On the expanded HuggingFace AssetOpsBench release, deterministic handlers achieve 100% (467/467) with average score 0.848, and all 40 graph-native scenarios are solved by deterministic handlers while GPT-4o without a graph fails on PageRank, BFS multi-hop traversal, and vector-similarity tasks (Mandarapu et al., 26 May 2026).
The architectural principle is “inverted LLM usage”: the LLM generates a structured Cypher query from a typed schema, the graph executes the data operations deterministically, and the LLM optionally summarizes the structured results. The paper argues that this constrains the LLM to code generation, avoids free-form reasoning over raw documents, and yields deterministic counts, joins, traversals, vector search, and graph algorithms that are reproducible and auditable in maintenance, compliance, and safety contexts. It also reports that natural-language-to-query accuracy increases from 55% to 78% and then to 83% as the schema prompt is enriched with actual property names and few-shot Cypher, reinforcing the importance of schema exposure rather than opaque tool wrappers (Mandarapu et al., 26 May 2026).
For PPR-AKG design, this result is consequential. A typed schema with explicit relationships, multi-hop dependency structure, embeddings on nodes such as FailureMode or Document, and deterministic execution appears to be the principal lever for operational accuracy in structured industrial domains. The industrial graph described in that work begins with 781 nodes, 955 edges, and 16 relationship types, then expands to approximately 1,360 nodes, approximately 2,500 edges, 14 labels, and 21 relationship types as additional domains and topologies are added. The paper explicitly notes that a PPR-AKG can begin at the smaller scale and expand similarly as PHM, rule logic, and FMSR are added (Mandarapu et al., 26 May 2026).
In adjacent process-engineering research, labeled property graphs are also used as the working model for graph retrieval-augmented code generation and multi-step problem solving. That work treats a PPR-style asset graph as an operational store for deep traversal, vector retrieval, and tool orchestration, while exposing RDF or JSON-LD views for standards alignment. This suggests a dual implementation strategy for PPR-AKG: formal ontology for semantics and interoperability, and traversal-heavy property graph for operational automation (Srinivas et al., 2024).
6. Evaluation status, misconceptions, and open problems
The empirical status of PPR-AKG is uneven across the literature. The EV battery remanufacturing paper validates the approach qualitatively and reports “substantial performance improvements,” but does not provide quantitative metrics, baselines, or ablation studies. By contrast, the industrial asset-operations study provides explicit scenario counts and accuracy numbers, making it the strongest numerical evidence that typed graph structure can dominate LLM orchestration as the main determinant of accuracy in structured operational domains (Novak et al., 8 Aug 2025, Mandarapu et al., 26 May 2026).
Several common misconceptions can therefore be addressed precisely. First, PPR-AKG is not simply a chatbot interface over manufacturing data: the conversational layer depends on prior capability, condition, and topology modeling, and in the strongest quantitative results the decisive gain comes from the graph data layer itself rather than from a stronger LLM (Novak et al., 8 Aug 2025, Mandarapu et al., 26 May 2026). Second, it is not a resource-assignment scheme in the traditional sense: the core planning abstraction is capability-centric, not fixed-resource-centric, and that distinction is what enables dynamic allocation under variability (Novak et al., 8 Aug 2025). Third, it is not yet a full optimization and uncertainty framework: the published emphasis is on logical and semantic rules, while optimization with cost functions for desired and undesired states, temporal reasoning, and uncertainty modeling are identified as future directions rather than completed components (Novak et al., 8 Aug 2025).
The limitations are correspondingly concrete. Typed schemas and explicit relationships require substantial upfront modeling effort; ETL from CSV, YAML, JSON, MES, and other enterprise sources remains necessary; real industrial data may be noisy or unstructured; and LLM-based instantiation and judgment remain difficult to validate efficiently. In the graph-execution setting, LLM nondeterminism persists for natural-language query generation, TSFM scenarios requiring ML inference cannot be expressed as Cypher, and deterministic routing is required for such cases. In lifecycle-oriented variants, data-sharing barriers from manufacturers, the need for deeper AAS integration, and scalability assessment at real-life scale remain open problems (Novak et al., 8 Aug 2025, Mandarapu et al., 26 May 2026, Strakosova et al., 2 Oct 2025, Strakosova et al., 1 Oct 2025).
The research trajectory is accordingly clear. The literature points toward stronger AAS integration, fuller PAN or PoPAN models with industrial partners, scalability analysis, explicit optimization methods with cost functions, temporal and uncertainty extensions, and more systematic LLM division of labor in which one model instantiates and another judges. Across these directions, the unifying idea remains stable: a PPR-AKG is a standards-aligned, capability-centered, condition-aware, and increasingly executable knowledge representation for flexible industrial systems, spanning design, production, maintenance, and end-of-life operations (Novak et al., 8 Aug 2025, Strakosova et al., 2 Oct 2025, Strakosova et al., 1 Oct 2025).