TL;DR
KPIs are most effective when calculated where they can be fully understood. PLCs capture high-speed machine signals and simple calculations at the source, while TrakSYS transforms that data into contextualized, time-based performance metrics. Together, they form a scalable architecture where machines generate trusted data, and MES converts it into actionable intelligence.
Key takeaways:
- PLCs capture real-time signals, states, and high-speed counts at the equipment level.
- TrakSYS contextualizes that data using time, materials, shifts, operators, and production states.
- Duration-based and performance KPIs (OEE, downtime, throughput, trends) belong in MES.
- KPI definitions evolve—centralizing them in MES improves maintainability and governance.
- The strongest architecture is hybrid: PLCs generate accurate machine data; MES contextualizes, aggregates, and operationalizes it.
The Key to KPI Calculation
During solution delivery, we’re often asked a deceptively simple question: where will KPIs actually be calculated—inside the PLC or within TrakSYS?
PLCs excel at capturing high-speed signals and performing simple calculations at the equipment level, but they lack the operational context needed to produce meaningful performance metrics. MES platforms like TrakSYS transform raw machine data into actionable intelligence by incorporating time, materials, shifts, operators, and production states—turning numbers into decisions.
In this Q&A, we address the most common questions about KPI calculations and clarify how, by pulling PLC data into TrakSYS, engineers, operations leaders, and system architects can build smarter, more scalable data strategies.
Framing & Mental Model
Q. What kinds of KPIs or data points should live in PLCs?
PLCs are best suited for capturing and calculating real-time, single-point measurements at the machine level. This includes signals, counts, equipment states, and simple arithmetic derived directly from those inputs—such as part counts, run status, or cycle completion.
Q. How does KPI calculation expand when data moves into TrakSYS?
PLCs generate the raw signals, but TrakSYS transforms them into operational KPIs by adding context—time, materials, shifts, operators, and production states. This is where machine data becomes decision-ready metrics like OEE, downtime, performance trends, and throughput analysis.
PLC-Level Considerations
Q. When is it advantageous to calculate values directly in PLC logic?
When calculations must occur at machine speed or rely on immediate sensor input. For example, high-speed counters, simple rate calculations, or machine-state detection are best handled at the PLC layer, where data originates and response time is critical.
Q. What constraints limit KPI logic in PLCs?
PLCs are optimized for control, not analytics. Memory and limited historical storage make them poorly suited for duration-based or context-driven KPIs. They typically lack built-in data historization, contextual enrichment, and flexible reporting capabilities.
MES-Level Considerations
Q. What capabilities does TrakSYS provide that PLCs fundamentally lack?
TrakSYS is designed to aggregate, contextualize, and historize data across machines, lines, and sites. It supports time-based calculations, scripting, rolling averages, and historical comparisons—enabling KPIs that evolve with operational needs.
Q. How does TrakSYS handle context differently than PLCs?
TrakSYS integrates production context—such as job, material, shift, operator, and downtime reason codes—alongside machine signals. For example, a PLC can indicate that a line stopped, but TrakSYS can help explain when it stopped, why, for how long, and under what production conditions.
Q. What happens when KPI definitions evolve over time?
KPI definitions naturally mature as operations improve. MES platforms make these updates manageable by centralizing logic in a configurable environment, rather than requiring PLC code changes across multiple assets.
Data Quality & Timing
Q. How does calculation location affect data accuracy and traceability?
PLCs ensure accuracy at the signal level, but traceability emerges when that data is historized and contextualized in MES. For example, OEE depends on availability, performance, and quality over time—something only an MES can reliably assemble and audit.
Q. How do late or corrected data points factor into KPI calculation?
Operational context often changes after the fact—downtime reasons are reclassified, production quantities are reconciled, or job data is updated. MES platforms allow this context to be corrected and KPIs recalculated, while PLC logic typically cannot accommodate retrospective changes.
Maintainability & Change
Q. Who should own KPI logic over the life of a system?
PLCs should own signal capture and machine-level logic, while MES should own KPI definitions. This separation ensures machine reliability while allowing KPI logic to evolve without costly PLC reprogramming.
Q. How does calculation placement affect validation and audits?
Centralizing KPI logic in MES improves transparency and auditability. With access to historical data and contextual inputs, MES calculations can be validated, traced, and standardized across sites more easily than distributed PLC-based logic.
Tradeoffs & Boundaries
Q. Are there hybrid approaches to KPI calculation?
Yes—and they represent the most effective architecture. PLCs capture signals and perform immediate calculations; TrakSYS collects, contextualizes, historizes, and aggregates that data into enterprise KPIs.
Q. When does MES-side calculation introduce unnecessary complexity?
If a metric is purely machine-level, real-time, and context-independent, keeping it in the PLC may be appropriate. MES adds the most value when KPIs require time, aggregation, or operational context.
Q. What’s a “small decision” here that becomes very expensive later?
Placing long-term KPI logic in PLCs can create technical debt. Changes require engineering time, testing, and deployment across equipment. Designing a hybrid architecture—signals in PLCs, KPIs in MES—keeps systems scalable and adaptable as operations evolve.
Conclusion
PLCs and TrakSYS are not competing locations for KPI logic—they are complementary layers of a modern manufacturing data strategy. PLCs ensure accurate, real-time signal capture at the machine level, while TrakSYS provides the context, historization, and analytical framework required to turn those signals into meaningful performance insights.
When organizations treat PLCs as the source of truth for equipment data and MES as the system of intelligence for operational KPIs, they create an architecture that is both responsive on the plant floor and adaptable over time. The result is not just better metrics, but better decisions—grounded in context, aligned across teams, and built to evolve with the operation.
FAQs
KPIs should be calculated where they can be fully contextualized. PLCs are best for capturing real-time machine signals and simple calculations at the equipment level, while TrakSYS calculates time-based, contextualized KPIs using production data such as materials, shifts, operators, and downtime events. A hybrid architecture ensures accurate signal capture at the source and meaningful performance analysis within MES.
PLCs are ideal for high-speed, machine-level calculations that rely on immediate sensor inputs, such as part counts, equipment states, and simple rate calculations. These values support real-time control and responsiveness on the plant floor. However, PLCs are not designed for historical analysis, aggregation, or context-driven performance metrics.
TrakSYS is designed for duration-based and contextual KPIs such as OEE, downtime, throughput, performance trends, and cross-line analysis. By incorporating production context—including job, material, shift, and operator data—TrakSYS transforms raw machine signals into decision-ready operational intelligence. Centralizing KPI logic in MES also improves governance and scalability.
A hybrid approach allows PLCs to focus on accurate signal acquisition and real-time control while TrakSYS handles contextualization, historization, and enterprise-level analysis. This separation reduces technical debt, improves maintainability, and enables KPI definitions to evolve without requiring widespread PLC code changes. The result is a scalable architecture that supports both plant-floor responsiveness and long-term performance optimization.
Related Blog Posts


Let’s Build Your Plan
We’ll help you create the right configuration—today and for the future.




