Frequently Asked Questions

We work in three steps: Understanding (on-site meeting, target vision), Validation (proof of concept in your environment), and Rollout. The first visible results appear within weeks. Once the foundation is in place, the total cost of ownership decreases significantly with each additional use case, since integration, permissions, and operations are already set up.

An MES manages orders, a historian stores time series, a BI tool visualizes data, and a cloud suite typically requires data to leave the site. tensoryze bridges the gap: it captures or consolidates data, places it in the production context, and makes it immediately available for various applications—on your infrastructure, with a single authorization model, a single database, and a single audit trail.

Licensing is based on each location, with a clear framework for connected lines and applications in use—not per data point and not per user. We will work with you to define the specific framework, depending on your operating model (on-premises, air-gapped, cloud) and the range of applications you intend to use.

Data is stored in open formats within your infrastructure; export interfaces are a built-in platform feature, and interfaces comply with industry standards (OPC UA, Sparkplug B, MQTT, REST). Open-source components form the foundation—no proprietary lock-in. In the worst-case scenario, you retain your data, models, and structures; you would only need to replace the user interface.

Both approaches work. They work just as well with small IT teams as they do with established DevOps organizations. If desired, our engineers can take full responsibility for operations, updates, and monitoring (managed service option). We always work together with your team to set up the system at your facility—connecting it to your production lines, adapting it to your roles, and training your employees.

On the line terminal, the operator can see the current status of his line, open tickets from the current shift, and alarms that require his attention. They must enter the information that used to be written on a piece of paper: reason for downtime, handoff notes, and quality findings. The interfaces are designed for the shop floor—operable while wearing gloves, on the move, and in noisy environments, with voice input via cell phone or tablet for hands-free situations.

Tickets, downtime, shift notes, and quality incidents are recorded on a timeline for each shift—including the timestamp, machine, order, and people involved. When the shift changes, the information is passed on—not tied to any one individual. Past shifts are searchable; the shift log also serves as the basis for audits and root cause analyses.

OEE and its three components (availability, performance, quality), downtime and root cause analyses, line and shift comparisons. Calculated automatically from the connected data as soon as the line is located in the Unified Namespace. The exact calculation rules can be customized initially. The figures are reliably determined through the link to the job and shift—a downtime between two jobs is evaluated differently than one in the middle of production.

You can define rules not only using thresholds, but also using trends, patterns, and SPC charts—and with escalation chains (e.g., operator → shift supervisor → maintenance) and time windows for each level. In addition, each alarm is designed according to an opt-in model; if a notification is no longer desired, it can be individually suppressed at any time.

Camera-based real-time inspection for surface defects, assembly deviations, and completeness checks—using traditional image processing methods and AI models, often in combination. The inspection system makes decisions for each component in sync with the production line; the results are recorded directly in the shift log and included in the quality report. We’ll test your components to determine whether a particular application is suitable before you make your initial investment.

A hierarchically organized structure (ISA-95: Enterprise → Site → Area → Line → Cell → Equipment) in which each measurement value can be uniquely addressed. Only then does a value become usable information. You don’t need it beforehand: if no structure exists, we’ll build it together; if one exists (e.g., via Sparkplug B), we’ll integrate ourselves as the host application.

OPC UA and MQTT are supported natively. The Unified Namespace and Sparkplug B structure communication between applications. Our engineers can integrate additional protocols as needed.

Sparkplug B makes MQTT ready for production: defined topic structures, creation and deletion messages, and clear state semantics for each edge node and device. This also standardizes communication between various applications. tensoryze integrates existing Sparkplug infrastructure as a host application or provides its own solutions.

No, production continues—each connection per line is a read operation. A connection without write permissions is the norm; manual interventions are the deliberate exception, for example, during visual inspections.

Through integration with ERP/MES and the digital shift log. This means that a measured value not only indicates which machine it comes from, but also which order, which shift, and which operator it is associated with. The system processes time series, process curves, images, documents, bills of materials, shift notes, and maintenance data—all organized according to the same hierarchy.

Yes, because all plants report using the same ISA-95 hierarchy and the same KPI definitions. The migration to this structure is part of the implementation—structural changes are versioned and follow an approval workflow. This results in line- and site-level comparisons that are technically sound, rather than three different interpretations of “OEE.”

Three deployment models: on-premises in your data center, air-gapped without an internet connection, or in the cloud. Hardware requirements depend on the number of lines, the volume of data (especially image data), and the selected applications—we provide specific sizing recommendations for each location before you order hardware.

Updates are versioned via a GitOps workflow. Configuration changes are traceable and auditable as code (GitOps audit trail). Upon request, we can operate a staging environment alongside the production environment, where changes are tested before rollout—and, if desired, our engineers can handle the entire update process.

Data remains with the customer—even when operating in the cloud, in an environment that you control. We coordinate identity integration and the authorization model with your IT team to ensure compliance with your requirements. Authorizations follow a role hierarchy with inheritance across the plant, line, and machine levels; service accounts and API tokens have defined scopes and expiration periods.

Configuration changes, access events, alarm acknowledgments, model approvals, and control interventions can be traced by timestamp, user, and context. This is generally sufficient for typical requirements (e.g., audit trail obligations in regulated industries, NIS2 topics such as access control and incident documentation); we will work with your compliance function to perform a specific comparison against your control catalog.

Each location has its own instance that runs independently—a network outage at Plant A does not affect Plant B. Locations share structures, KPI definitions, and application templates via versioned configurations, but retain local data sovereignty. We coordinate high availability at the component level and backup procedures with your IT department—in line with your existing processes.

Computer vision for optical inspection (surface defects, assembly deviations, completeness), root cause analysis of the relationship between process parameters and quality results, and anomaly detection in sensor and process data as a basis for predictive maintenance. Whether a use case is suitable depends on the available data—we’ll evaluate this together with your team in a proof of concept before you make an investment.

Neither. Typical use cases are available as applications and are tailored to your production lines in collaboration with our engineers—without requiring you to have your own ML team. If you have data science expertise, you can contribute your own models and work with platform data directly from your Python environment using the Tensoryze Python SDK. This eliminates the usually very time-consuming data preparation process.

Training data comes from the Unified Namespace; models are trained and versioned, rolled out to the target machine or line upon approval, and monitored during live operation. Each model has a clearly designated person in charge—rolling back to the last healthy version takes just one click.

Model quality is monitored during live operation—input distributions, predictions, and (if available) labels. If the model’s performance deteriorates compared to its training performance, the platform triggers an alert and flags the model for review. Until a new version is released, the system can be rolled back to the last stable version. Operators can also report incorrect decisions directly at the line terminal—this feedback is incorporated into the next training run.

Assistants answer questions about machines, error messages, and operating procedures in the context of the respective line or shift; they summarize shift reports and assist with the onboarding of temporary workers. You decide which models to use for this—whether operated locally or through an external provider.