Production Knowledge System Overview

• Production Knowledge System is a framework that explicitly represents and reuses production-relevant knowledge to drive planning, control, and continuous improvement.
• It employs integrated architectures—using SCADA, BIM, ontologies, and market-based evaluations—to unify data across collaborative, manufacturing, and cyber-physical settings.
• Its implementation enhances real-time decision-making and adaptive learning by linking quantified performance indicators with operational execution.

Searching arXiv for papers on “production knowledge system” and closely related terms to ground the article in current literature. “Production Knowledge System” denotes a class of socio-technical systems in which knowledge about products, processes, resources, constraints, states, capabilities, evaluations, and decisions is explicitly represented, operationally coupled to work execution, and continuously reused for planning, control, learning, and collective improvement. Across the literature, the term appears both explicitly and implicitly. In collaborative settings, it denotes a wiki–market mechanism in which contributions and peer evaluation are tied to tradable project shares (Maillart et al., 2014). In project-driven production, it appears as a SCADA-enabled, BIM-centered, machine-learning-assisted environment for converting site data into reusable production knowledge (Antunes et al., 2018). In flexible manufacturing, it appears as an ontology-based knowledge base of machine skills learned from logs (Himmelhuber et al., 2021). In cyber-physical production systems, it appears as an ontology-grounded knowledge graph that becomes the authoritative runtime state of the factory (Hoffmann et al., 21 May 2026). In lifecycle engineering, it appears as a generic enterprise reference model integrating product, process, and resource roles with functions, behaviors, states, and performance indicators (Labrousse et al., 2010). These formulations differ in emphasis, but they converge on a common principle: production is not managed only through data storage or workflow automation, but through explicit knowledge structures that shape action, evaluation, and adaptation.

1. Conceptual scope and definitional variants

The literature does not provide a single universal definition of a Production Knowledge System; rather, it provides several technically compatible formulations. In the collaborative-production literature, a production knowledge system is a wiki-like collaboration platform coupled to a course-internal prediction market, where each project is both a wiki page and a tradable stock, contributions generate shares, and final payoffs are anchored in an ex-post evaluation (Maillart et al., 2014). In construction, the term is not used explicitly, but an integrated information system is interpreted as the operational layer of a Production Knowledge System: a SCADA-enabled, BIM-centered, machine-learning-assisted socio-technical system that acquires raw production data from site, structures it against production theory and plans, and converts it into reusable production knowledge for planning, control, and continuous improvement across projects (Antunes et al., 2018).

In flexible manufacturing, the concept narrows toward machine-understandable capability knowledge. A production knowledge system is described as a formal knowledge base that models products, processes, machines, and their skills in a logical form suitable for feasibility checks, module assignment, and reconfiguration (Himmelhuber et al., 2021). In circular cyber-physical production systems, the definition becomes more operational: the factory state is represented as a semantically structured knowledge graph rather than scattered across PLCs, MES tables, and logs, and the knowledge graph is treated as the authoritative write-time state governing runtime decisions (Hoffmann et al., 21 May 2026). In lifecycle-oriented knowledge engineering, the conceptual core is the FBS-PPR(E) model, in which products, processes, and resources are not fixed classes but roles played by enterprise objects, each described through function, behavior, structure, states, and performance indicators (Labrousse et al., 2010).

A plausible implication is that “Production Knowledge System” functions as an umbrella term spanning at least four research lineages: collective knowledge production, production information systems, ontology-based manufacturing knowledge, and knowledge-graph-centered CPPS. What these lineages share is explicit representation of production-relevant knowledge and its direct use in execution or decision-making.

2. Foundational modeling principles

A recurrent foundation is the unification of product, process, and resource knowledge. The FBS-PPR(E) model treats an enterprise object as any entity constitutive of the enterprise and/or manipulated by it and playing a role in its functioning; product, process, and resource are contextual roles rather than permanently distinct entity classes (Labrousse et al., 2010). In that model, behavior is not intrinsic to the object alone but results from interactions between an object and a process in a given environment, and performance indicators compare expected and actual behavior through a dimensionless ratio conceptually expressed as $PI = \frac{\text{réalisé}}{\text{attendu}}$ (Labrousse et al., 2010). This gives a lifecycle-wide semantics for dynamic knowledge management.

A second foundation is the distinction between data, information, and knowledge. In the construction-oriented framework, raw sensor streams, images, point clouds, and time stamps are transformed into contextualized metrics such as progress, cycle times, and defect flags, and then into models, standards, control rules, and best practices reused in later projects (Antunes et al., 2018). In the Data-to-Knowledge pipeline view, Digital Shadows are defined as task- and context-dependent, purpose-driven, aggregated, multi-perspective, and persistent datasets, and D2K/K2D pipelines organize the transformation from raw data to models and actions, and back from knowledge to modified data collection and execution (Gorißen et al., 2024). This suggests that many PKS architectures are best understood as closed-loop systems rather than static repositories.

A third foundation is formal representation. The ontology-based skill-learning literature defines the knowledge base as $K = (I, B)$, where instance data $I$ come from production logs and background knowledge $B$ from industrial ontologies (Himmelhuber et al., 2021). A ground-truth skill description is a set of class expressions $A_{\text{total}}$, and the learned description $A_{\text{learned}} = \{A_1, \dots, A_n\}$ is selected from a larger candidate set $C$ produced by class expression learning (Himmelhuber et al., 2021). In knowledge-graph-centered CPPS, ontologies define products, components, operations, resources, services, workflows, uncertainty objects, and constraints, while RDF/OWL and SHACL turn those definitions into executable structure (Hoffmann et al., 21 May 2026). In a related anomaly-detection setting, timed automata and timing anomalies are also lifted into a knowledge graph through an alignment ontology spanning ISA-88, SSN/SOSA, DIN EN 61360, ECLASS, UML state machines, and ISO 17359 (Westermann et al., 2023).

A fourth foundation is the relation between explicit and tacit knowledge. The ISO 30401-oriented literature frames knowledge development through acquisition, application, retention, and management of obsolete knowledge, and knowledge transformation through human interaction, representation, aggregation, and assimilation/apprentissage, explicitly linking these mechanisms to SECI and PDCA (Belloni et al., 24 Jul 2025). The 2012 theory of the knowledge industry sharpens the macro-level view: the “raw material” of knowledge production is an epistemic heritage composed of concepts, theories, data, techniques, conjectures, problematics, and contradictions recognized by the scientific community as its field of action and thought (Ghassib, 2012). A plausible implication is that PKS research oscillates between two poles: explicit formalization for computation, and structured handling of tacit expertise for organizational continuity.

3. Architectural patterns

Several architectural patterns recur across the literature. One is the layered collaboration–evaluation architecture. In the prediction-market system, the knowledge layer is a wiki in which each project is a page, the market layer is a prediction market in which each project corresponds to a tradable stock, the currency is Entrepreneurial Risks Dollar (ER$), and the outcome signal is the instructor’s ex-post grade [1406.7746]. Each student begins with \(W_0 = \text{ER\$ }10\,000), project creation yields 5 initial shares worth $5 \times \text{ER\%%%%1%%%% }500$, and every 10 words grants a fixed ER\$100 worth of shares, so that the number of shares received depends on market price \(P_i\): \( s_i = \frac{\text{ER\$ }100}{P_i} ) per contribution unit (Maillart et al., 2014). The same mechanism organizes contribution, evaluation, and incentive alignment.

A second pattern is the four-group production architecture. The construction framework explicitly proposes Planning, Monitoring, Controlling, and Executing groups linked through a central SCADA-style control room and a machine learning engine (Antunes et al., 2018). Planning combines BIM, productivity theory, and project plans; Monitoring gathers video, LiDAR, sensor, drone, and worker-tool data; Controlling fuses those with productivity models such as PFPC/APFPC; Executing contains human workers, semi-automated equipment, and IoT-enabled tools (Antunes et al., 2018). The architecture is designed around four pillars of manufacturing knowledge and lean production: production processes, production management, equipment/tool design, and automated systems and control (Antunes et al., 2018).

A third pattern is the ontology–learning–validation pipeline. In the skill-description system, preprocessing converts production logs into ontology individuals, an ILP recommender based on DL-Learner and CELOE generates candidate class expressions ranked by predictive accuracy, and postprocessing lets a domain expert select a subset of the top 20 expressions to form the final skill description (Himmelhuber et al., 2021). Knowledge storage holds both ontologies and instance data, and after learning also stores the approved skill descriptions (Himmelhuber et al., 2021). This pattern is explicitly semi-automatic: log evidence drives candidate generation, but human validation remains necessary.

A fourth pattern is the ontology layer–knowledge base layer–service layer–interface layer architecture of KAPPS (Hoffmann et al., 21 May 2026). Its knowledge base layer uses a triple store such as GraphDB, links to time-series stores and repositories, OWL reasoning, and SHACL validation; the service layer contains planners, controllers, anomaly detectors, learners, and HMIs; the interface layer contains SPARQL access, an object–graph mapper that generates typed Python models, and connectors to protocols such as OPC UA, ProfiNet, and MQTT (Hoffmann et al., 21 May 2026). The architecture enforces a single validated write path to the knowledge graph.

A fifth pattern is the modular ontology-plus-triplestore stack seen in the sustainable wheat knowledge graph. Protégé, OWL 2, RDF, GraphDB, ROBOT, RDFLib, HermiT, and Pellet are used to build modular ontologies for nitrogen management, disease management, sustainability, and environmental context, with KnowWhereGraph, ENVO, WTO, weather ontologies, and Crop Disease Ontology reused where possible (Gelal et al., 26 Feb 2025). The resulting structure is intended as a node in a larger global food systems datahub.

4. Operational mechanisms and reasoning

A Production Knowledge System becomes operational when it ties representation to execution, prediction, or control. In the collaborative-market mechanism, market price $K = (I, B)$0 is treated as approximating the expected final score $K = (I, B)$1, portfolio value is tracked as $K = (I, B)$2, and final grade is linked to the ex-post value of held shares (Maillart et al., 2014). The market thereby acts as distributed peer review: high price means collective belief in high project value, low price the opposite (Maillart et al., 2014). The authors report that despite low liquidity, prices correlate well with ex-post grades, making prices a reliable real-time indicator of project quality (Maillart et al., 2014).

In construction-oriented PKS, the control logic is centered on productivity functions and predictive control. Conceptually, $K = (I, B)$3, where output depends on input/control and system state, and PFPC minimizes deviation from planned output over a horizon subject to capacity constraints (Antunes et al., 2018). APFPC re-estimates productivity functions using back-propagation so that the controller adapts as the system evolves (Antunes et al., 2018). Monitoring also encodes lean-production diagnostics: Muda, Muri, and Mura are represented through chrono-analysis, LiDAR/image comparison against BIM tolerances, worker effort sensing, and variance of cycle times or output (Antunes et al., 2018). This is operational knowledge because it directly triggers alerts, supplier notifications, bin replacement, and control-room interventions.

In ontology-based skill planning, machine capabilities are expressed as OWL restrictions. For example, the manually specified ground truth for AssembleItemByModule1 includes involvesMaterial only (MaterialProductBase or BottomPart), hasPositionParam only (pos1 or pos2), and hasOrientationParam only (hundredeighty or zero) (Himmelhuber et al., 2021). These class expressions support reasoning tasks such as instance checking, subsumption, classification, and SPARQL/DL querying when matching Bill-of-Process requirements to module skill offers (Himmelhuber et al., 2021). Empirically, the evaluation on four skills reports Recall = 1 and Precision = 0.15 for AssembleItemByModule1, Recall = 0.67 and Precision = 0.10 for AssembleItemByModule2, Recall = 1 and Precision = 0.10 for DismantleProductByModule3, and Recall = 1 and Precision = 0.15 for ChargeProductBaseByModule4 (Himmelhuber et al., 2021). The result is high recall with low-to-moderate precision, which the authors interpret as reducing manual effort because experts review a shortlist rather than writing descriptions from scratch (Himmelhuber et al., 2021).

In KAPPS, the operational mechanism is constraint-enforced runtime state transition. OWL reasoning supports integration and inference; SHACL implements closed-world validation and blocks invalid updates (Hoffmann et al., 21 May 2026). A concrete SHACL-SPARQL constraint states that a Box in InTransit must be possessed by exactly one resource, formalized as $K = (I, B)$4 (Hoffmann et al., 21 May 2026). Another constraint limits a FlexConveyorModule to at most one hasPossession value (Hoffmann et al., 21 May 2026). In the conveyor use case, any write violating these constraints is rejected, and the graph remains in a valid state (Hoffmann et al., 21 May 2026). In the anomaly-detection use case, operation instances, referenced time-series data, learned thresholds, and anomaly outcomes are all written back into the graph, making learning and execution operate over the same semantically typed state (Hoffmann et al., 21 May 2026).

In the timed-automata knowledge graph, a learned automaton $K = (I, B)$5 is represented in RDF/OWL, and the ANODA algorithm detects “Unknown Event” and “Wrong Timing” anomalies by checking transition existence and satisfaction of timing intervals (Westermann et al., 2023). The five-tank use case learns 1 initial state plus 6 production states from 5 hours of undisturbed production, then detects a clogging fault when state $K = (I, B)$6 remains active for about 127 seconds, exceeding a learned maximum of 121.8 seconds (Westermann et al., 2023). The anomaly is represented as a Symptom linked to the relevant TransitionTiming, enabling operators to query not only that an anomaly occurred, but also the associated state, physical equipment, expected event, and deviation magnitude (Westermann et al., 2023).

5. Measurement, evaluation, and performance indicators

The PKS literature measures performance in different but structurally related ways. In the collaborative setting, the system records full edit histories, trading data, prices, volumes, and portfolios (Maillart et al., 2014). Contribution matrices $K = (I, B)$7 quantify how much each student contributed to each project, and the relation between total contributions $K = (I, B)$8 and final score $K = (I, B)$9 is modeled as $I$0 (Maillart et al., 2014). Empirically, the scaling exponent is $I$1 with $I$2 in 2011, and $I$3 with $I$4 in 2012, showing superlinear growth of final score with contributions (Maillart et al., 2014). Markets also predict final grades reasonably well, and some students contribute “orders of magnitude” more than average, which the authors interpret as evidence that the mechanism does not crowd out intrinsic motivation (Maillart et al., 2014).

In construction, measurement is oriented toward process control and continuous improvement. The system is designed to compute throughput $I$5, cycle time $I$6, resource utilization $I$7, variability in output or cycle time, and value-adding ratios such as $I$8 (Antunes et al., 2018). It also distinguishes Muda I and Muda II time ratios and uses defect detection through LiDAR/image comparison against BIM tolerances (Antunes et al., 2018). Evidence is reported from four course instances in educational deployment and from conceptual industrial benefits such as increased information flow, reduction of Muda, Mura, and Muri, and reuse and abstraction of project information across endeavors (Antunes et al., 2018).

In flexible manufacturing skill learning, evaluation is explicit and quantitative. Predictive accuracy ranks candidate class expressions, and the top 20 are reviewed by experts (Himmelhuber et al., 2021). Recall and precision are defined from true positives, false negatives, and the fixed candidate list size, giving a measurable picture of how effectively log-derived class expressions cover the manually defined ground truth (Himmelhuber et al., 2021). Although precision is low, the reported recall values indicate that most relevant constraints appear in the expert’s shortlist.

In KAPPS, evaluation is requirement-driven. The architecture is derived from 14 requirements across five perspectives—Perception, Product, Planning/control/execution, Resources, and Learning—and then demonstrated in two implemented use cases: anomaly detection and learning in a robotic disassembly cell, and runtime constraint enforcement in a modular conveyor system (Hoffmann et al., 21 May 2026). The evidence is architectural rather than benchmark-based: the graph supports queryable unified information state, write-time validation of physically feasible transitions, decision provenance, persistence of learned abstractions, and temporal reproducibility via triple-level history (Hoffmann et al., 21 May 2026).

In the sustainable wheat KG, evaluation is competency-question-based. The ontology and knowledge graph are validated through structured and unstructured interviews, expert feedback, SPARQL querying, and reasoner-based consistency checking with HermiT and Pellet (Gelal et al., 26 Feb 2025). The system is still preliminary and schema-focused, so its evaluation emphasizes coverage, logical coherence, and interoperability rather than operational plant metrics (Gelal et al., 26 Feb 2025).

6. Organizational implications, limitations, and research frontiers

A striking claim in the prediction-market paper is that the mechanism “efficiently engages users without further governance structure,” meaning that there are no committees, moderators, role assignments, or explicit hierarchical review layers beyond the wiki, the market, and the exogenous final signal (Maillart et al., 2014). Governance emerges from price dynamics, contribution incentives, and scarcity of ER$, though the paper also notes vulnerabilities such as low liquidity, skill-based limitations, and the fact that the system is little suited for creating self-contained final reports requiring strong central editorial control (Maillart et al., 2014). This provides an important caution: PKS architectures that excel at distributed micro-contributions may underperform when tasks require highly coherent final synthesis.

The construction framework identifies different limitations. It has been tested only in settings with tens of participants or conceptual industrial architectures, not in massive deployments, and it may fail in highly technical domains when evaluation expertise is insufficiently distributed (Antunes et al., 2018). Technical and organizational challenges include mobile instrumentation, fusion of heterogeneous data, real-time performance, conservative company culture, siloed information practices, and the need for skills in data science, SCADA, and BIM integration (Antunes et al., 2018). The ontology-learning literature similarly warns that CELOE optimizes predictive accuracy rather than the completeness and interpretability needed in planning, and that scaling from four toy skills to industrial-scale systems remains open (Himmelhuber et al., 2021).

Knowledge-graph-centered CPPS shift the difficulty toward ontology engineering, schema evolution, and transactional governance. KAPPS assumes that anything critical to coordination can be represented in RDF, does not guarantee physical measurement correctness, delegates identity and fine-grained access control to external systems, and leaves concurrency and isolation to triple-store transaction models (Hoffmann et al., 21 May 2026). Future directions include industrial-grade deployment in a micro Circular Factory, better ontology and SHACL engineering support, ontological evolution during operation, learning SHACL constraints from runtime data, federation across factories, and integration with autonomous AI agents under SHACL guardrails (Hoffmann et al., 21 May 2026).

The broader “knowledge enterprise” perspective suggests another frontier: PKS should not be seen only as technical architectures, but also as perspectives in which empirical, theoretical, modeling, data, methods, and tools co-evolve (Raimbault, 2017). This suggests that production knowledge systems can stagnate if one domain advances without the others—for example, if tooling outpaces methods, or data collection outpaces theory. At a macro level, the theory of the knowledge industry argues that modern knowledge production has become a strategic industry, with universities, research institutes, and corporate R&D acting as “factories of knowledge,” the epistemic heritage as raw material, and evaluation as an integral part of production (Ghassib, 2012). In that view, PKS are not merely software systems; they are industrialized infrastructures of collective cognition.

A plausible implication is that the contemporary research frontier is a convergence of three trajectories. The first is operationalization: turning ontologies and knowledge graphs into runtime substrates rather than archival layers, as in KAPPS (Hoffmann et al., 21 May 2026). The second is closed-loop learning: connecting production data, Digital Shadows, and model updates through D2K/K2D pipelines (Gorißen et al., 2024). The third is human–system co-production: preserving interpretability, tacit knowledge transfer, and collaborative validation while increasing automation, whether through communities of practice, expert selection of learned constraints, or conversational interfaces over production knowledge graphs (Himmelhuber et al., 2021). The production knowledge system, in this convergent sense, is neither only a repository nor only a controller; it is the formal, executable, and revisable knowledge substrate through which production is understood, coordinated, evaluated, and improved.