KAPPS: A knowledge-based CPPS Architecture for the Circular Factory

Technical Summary: KAPPS – A Knowledge-Based CPPS Architecture for the Circular Factory

1. Problem Statement

Conventional Manufacturing Execution Systems (MES) and Cyber-Physical Production System (CPPS) architectures are designed for linear manufacturing, characterized by homogeneous materials, predefined process sequences, and deterministic execution. These systems fail in Circular Factory settings, where used products ("cores") enter the production line with heterogeneous conditions, uncertain states, and varying lifecycles.

In a Circular Factory, process sequences, operation types, and part recombinations must be determined at runtime based on the specific condition of each instance. This introduces:

• Uncertainty: Individual components require probabilistic state representations.
• Heterogeneity: Diverse data sources (sensors, human input, legacy systems) must be integrated.
• Dynamic Reconfiguration: Resources must adapt to unforeseen situations without global re-orchestration.
• Traceability & Learning: Decisions must be linked to provenance to enable retrospective analysis and continuous improvement.

Existing approaches (Control-centric, Data-centric, Model-centric, and Digital Twin-centric) address individual facets of these problems but lack a unified substrate that simultaneously supports instance-level traceability, runtime constraint enforcement, and the integration of human and machine knowledge. Specifically, current knowledge graph extensions often serve merely as read-only repositories or planning-time artifacts rather than as the authoritative, write-time state of the system.

2. Methodology

The research follows the Design Science Research Methodology (DSRM) proposed by Peffers et al. The work is structured as a problem-centered initiation, proceeding through six sequential activities:

1. Problem Identification: Analyzing the gap between Circular Factory demands and conventional CPPS capabilities.
2. Objective Definition: Deriving 14 specific design requirements (R1–R14) from five complementary perspectives: Perception, Product, Production Planning/Control, Resource, and Learning.
3. Design & Development: Constructing the KAPPS (Knowledge-based Architecture for Cyber-Physical Production Systems) architecture.
4. Demonstration: Implementing two laboratory-scale use cases (UC1 and UC2).
5. Evaluation: Systematically assessing the architecture against the 14 requirements.
6. Communication: Releasing the architecture and code as open source.

3. Key Contributions

The paper proposes KAPPS, a four-layer CPPS architecture where an ontology-grounded knowledge graph serves as the authoritative write-time state of the factory, rather than a passive data store.

The Four Layers:

1. Ontology Layer: Defines a shared semantic foundation using a core ontology (extending the Product-Process-Resource framework) and modular domain ontologies. It treats uncertainty (e.g., Gaussian Mixture Models) as first-class types and manages version control via Git-based pipelines.
2. Knowledge Base Layer (Unified Knowledge Base - UKB): A central triple store (currently GraphDB) combined with specialized databases (e.g., InfluxDB for time-series, Kadi for research data). It hosts the knowledge graph, performs OWL reasoning for semantic integration, and enforces SHACL constraints for closed-world validation of physical state transitions.
3. Service Layer: Hosts distributed services (planners, controllers, learners) as addressable units. Services expose "workflows" (capabilities) to the graph. Crucially, services interact with the graph via a single validated write path.
4. Interface Layer: Bridges the semantic layer with physical resources and heterogeneous protocols (OPC UA, ProfiNet, MQTT). It includes:
   • Triple Store Access Module: Uniform API for graph operations.
   • Object–Graph Mapper (OGM): Dynamically derives type-safe Python classes (via Pydantic) from the live ontology at runtime, allowing services to read/write validated objects without direct SPARQL manipulation.
   • Semantic Middleware: Handles service orchestration, protocol mediation, and event-driven coordination.

Key Architectural Decisions:

• The knowledge graph is the single source of truth for the factory state.
• SHACL acts as a server-side safety net, rejecting any state transition that violates physical invariants (e.g., a module possessing two boxes simultaneously) before the data is persisted.
• OGM ensures that all services operate on ontology-compliant data objects, decoupling application logic from database technology.

4. Results and Demonstrations

The architecture was validated through two use cases:

• Use Case 1 (Anomaly Detection & Learning): A robotic disassembly cell for angle grinders.

  • Scenario: Detecting screw removal failures using torque, force, and position sensor data.
  • Implementation: A perception service writes sensor time-series URIs to the graph; an anomaly detection service reads type-level parameters and writes anomaly labels; a learning service updates parameters based on historical data.
  • Result: Demonstrated instance-level traceability (R4, R5), decision provenance (R12), and the persistence of learned abstractions (R13) as first-class ontology properties. The system successfully closed the loop between physical execution and knowledge-based learning.

• Use Case 2 (Decentralized Conveyor Network): A network of autonomous FlexConveyor modules.

  • Scenario: Coordinating box transfers between modules without a central controller.
  • Implementation: Modules register capabilities and discover peers via SPARQL. Transfers are coordinated via event-driven workflows.
  • Result: Demonstrated runtime constraint enforcement (R9). When a module attempted to bypass the reservation protocol and transfer a box to an occupied neighbor, the SHACL engine in the triple store rejected the transaction, preventing a physically impossible state. This proved the graph acts as an infrastructure-level safety net independent of application logic correctness.

5. Evaluation Against Requirements

The architecture was evaluated against the 14 requirements derived in Section 2. The evaluation concludes that KAPPS structurally satisfies all requirements:

• R1–R6 (Representation): Satisfied by the RDF knowledge graph and OGM, providing unified, queryable, and traceable representation of heterogeneous data, uncertainty, and provenance.
• R7, R9 (Feasibility & Constraints): Satisfied by SHACL validation at the persistence layer, ensuring only physically feasible state transitions are admitted.
• R8, R10, R11 (Execution & Coordination): Satisfied by the semantic middleware, enabling event-driven execution, distributed coordination over a consistent view, and protocol mediation.
• R12–R14 (Learning & History): Satisfied by the provenance model and the triple store's history tracking, enabling retrospective analysis and the reuse of learned models.

6. Significance and Claims

The paper claims that KAPPS addresses a fundamental gap in manufacturing IT: the inability of current architectures to handle the instance-specific uncertainty and dynamic reconfigurability required for circular production.

• Structural Shift: Unlike previous approaches where knowledge graphs are additive "information layers," KAPPS elevates the semantic layer to the runtime substrate. It transforms the knowledge graph from an integration tool into the factory's authoritative state, where admission of every state change is gated by formal constraint validation.
• Integration of Capabilities: KAPPS combines the service integration and protocol mediation strengths of data-centric paradigms (like AAS) with the semantic expressiveness of knowledge graphs, creating a system capable of both real-time control and retrospective learning.
• Modesty and Scope: The authors explicitly state that KAPPS is functional but not industrially complete. The evaluation holds under specific scope conditions:
  • All exchanged artifacts must be representable in RDF.
  • Structural correctness is guaranteed, but physical data veracity depends on the sensors/resources.
  • Concurrency and access control are delegated to the backend triple store and the enclosing factory ecosystem.
  • The architecture assumes the Circular Factory encompasses all information challenges of linear factories plus additional complexity.

The work concludes by releasing the KAPPS architecture and use case code as open source (MIT License), inviting the research community to reproduce, extend, and move the system toward industrial deployment in the next iteration of the design science cycle.