The capabilities describe what VECHR MES does. The platform describes how all of it keeps running, at the scale of a single shop-floor transaction and at the scale of a multi-site deployment, through configuration changes and automation that never stops.
| Foundation | What it means in practice |
|---|---|
| Process Orchestrator | A visual flow canvas connecting equipment events to MES transactions, deployable per plant zone, with automatic failover between pods. |
| Advanced Scheduling | Finite-capacity scheduling with Forward, Backward, Leveling, and Drum-Buffer-Rope strategies, using different constraints for each resource type. |
| AI across the platform | Five AI surfaces working in MES context: Insight, Advisor, Expert Engineer, Orchestrator Assistant, and Routing Designer Assistant. All are advisory, and all require human confirmation. |
| Config Promotion | Configuration changes are promoted through Dev → QA → Prod with a diff before they are applied, rollback, and an audit trail in every environment. |
| Event-Driven Architecture | A change from one transaction can be distributed to services, dashboards, OEE, notifications, and other processes without waiting on a batch or a polling interval. |
| Reliability | Runs on Kubernetes in the cloud or on-premise, with auto-scaling, self-healing, monitoring, and zero-downtime deployment. |
Master data and production configuration are too important to move straight from development into production. VECHR MES brings promotion-pipeline discipline to manufacturing configuration.
Production does not wait for a dashboard to refresh. When something changes, the systems that need to know receive the event and can react in their own context.
An MES is not an application someone opens when they need a report. It sits in the middle of production execution, so availability, recovery, and the ability to change things without stopping operations are part of the platform design.
| Property | What you get |
|---|---|
| Cloud or on-premise | A Kubernetes-based deployment that can run on AWS, Azure, GCP, or in the company's own data center. |
| Auto-scale | Service capacity can follow changes in load without rebuilding the application architecture. |
| Self-healing | Failed components can be recovered or replaced by the orchestration layer without manual intervention for every instance. |
| Zero-downtime updates | New versions can be rolled out progressively, so the platform never has to stop the whole operation. |
| Built-in monitoring | The health of services, resources, and platform processes can be watched without building an observability layer from scratch. |
An MES architecture has to grow sideways as well as upward: more resources, more lines, more plants, and more transactions without changing the underlying model.
AI is not a special layer with a privileged route to production data. It follows the same platform rules: read the context it is permitted to read, produce an insight or a draft, then wait for a person before anything is saved.
What IT, OT, and architecture reviewers usually want settled first.
Yes. The platform is designed to run on Kubernetes, so a deployment can sit in a cloud such as AWS, Azure, or GCP, or in the company's own data center.
No. Multi-plant is part of the platform model. Plants, areas, work centers, resource groups, and resources can all be modelled in the same structure, with access control per site.
No. Event-driven is the communication pattern between capabilities. A production event can be consumed by OEE, dashboards, notifications, workflows, traceability, and other services as needed.
No. AI surfaces produce insight or drafts. Changes have to pass through human confirmation before they are saved.
Through Config Promotion, Dev → QA → Prod. Every move can be compared through a diff, has a rollback, and is recorded in the audit trail.
The platform is designed to deploy progressively, so updates can be applied without stopping the whole production operation.