Multi-Plant Foundation & Governance

Build a consistent plant structure, from one site to many

This is where the VECHR foundation is built: how plants, areas, work centers, and equipment are modelled, who is allowed to do what, and how master data is governed without losing the trail of any change.

What it covers

  • Secure sign-in and session control Security policy is enforced by the system itself, including lockout after failed sign-in attempts, password expiry, and password resets that only an administrator can perform. An AI Assistant is also available to help find information such as KPIs, orders, and downtime using everyday language.
  • Role-Based Access Control (RBAC) Set permissions by role and scope of work, so each user can only do what they are actually responsible for. Access control is applied consistently across the operation and supports the controls relevant to regulated environments.
  • Centralised, controlled master data Manage master data in one consistent structure, with changes recorded so every piece of data stays traceable and auditable.
  • Plant and infrastructure model Run many plants on one platform, with area hierarchies that can be nested to match each site's structure, and storage locations whose capacity and utilization can be monitored.

The plant structure follows ISA-95

Equipment is more than an asset list. VECHR models it in a hierarchy that follows ISA-95 principles, so scheduling, access control, and performance reporting can all work from the same structure.

LevelWhat lives there
PlantA single manufacturing site or location. You can run many plants on one platform, each with its own address, calendar, and contact details.
AreaAreas can be nested as deeply as needed, from a building down to a production line and a cell. Storage locations can also be modelled, with capacity and utilization you can monitor.
Work CenterA unit of work representing production capacity, usable in planning, scheduling, and costing.
Resource GroupA set of resources that can serve as capacity options in dispatch and scheduling. For example, a job that can run on any one of three available mixers.
ResourceThe actual equipment: a machine, a tank, or a pump, complete with its states, meters, and any IIoT connections.

Because this structure is shared, context stays consistent across the system. The line you scheduled against is the same line you see in OEE and the same line you scope access control to.

Access control ready for audit

  • Enforced server-side Every action is checked against the user's permissions on the server, not merely by hiding a button or a menu in the interface.
  • Access scoped per plant Permissions can be scoped by plant, so a user with supervisor access at one site does not automatically get the same rights at another.
  • Credential policy enforced by the system Password complexity, expiry, lockout after repeated failed attempts, and reset mechanisms can all be applied as system policy.
  • Access activity is recorded Sign-ins, sign-outs, failed attempts, and lockouts are written to the system access log, so access activity can be reviewed later.

Frequently Asked Questions

The questions that usually come up as IT and QA teams start mapping the plant structure.

Is there a limit on how many plants or areas can be modelled?

No limit is set in the model. You can run many plants and nest areas to match each site's structure. Multi-plant is part of the platform structure, not a feature that only arrives after an upgrade.

Can one user work across several plants?

Yes. Permissions can be set per plant, so a user can hold a different role at each site, supervisor at one plant and read-only at another, for instance.

Do we have to change our plant structure to follow ISA-95?

No. VECHR uses ISA-95 as a model for describing the structure your plant already has. The goal is not to force you to reorganise, but to give you a consistent structure so scheduling, OEE, access control, and everything else can share the same context.

Keep reading