Limited context after delivery
A service request may arrive without the alarm history, operating state, or configuration details needed for triage.
Build secure remote diagnostics, machine monitoring, and a repeatable service path into new or installed equipment.
Remote service for machine builders combines a machine-side Orenda Box, organization-authorized access to selected resources, and configured operational data. An OEM service engineer can inspect a delivered machine without receiving broad access to the customer’s plant network. Customer approval, change control, operating safety, and PLC logic remain with the customer and the engineered control system.
Use configured machine context: Review the status, alarms, counters, trends, and service screens that the installation has been configured to expose.
Limit the access target: Authorize the service team for selected apps, devices, or services instead of assuming it needs the whole customer network.
Repeat the deployment method: Use the same readiness checklist and handover method for new deliveries and suitable retrofits.
Keep people in control: Engineers interpret the evidence and follow the customer’s approval, safety, and change-control procedures.
Each layer has a narrow job. The access path supports diagnosis and approved service activity; it does not become the machine’s control or safety system.
Separating these modes makes scope, responsibility, and customer expectations easier to document before deployment.
| Mode | Purpose | Typical boundary | Orenda’s role |
|---|---|---|---|
| Monitoring | Observe configured status, alarms, counters, or trends. | Read-only views where the connected app and data path support them. | Provide machine-side data and authorized access to the selected view. |
| Diagnostic access | Inspect a service application, HMI, device, or engineering tool. | Orenda authorization determines reachability; the connected application and control system determine available actions, while customer procedure governs whether they are permitted. | Provide a resource-specific access path; access alone is not approval to change the machine. |
| Machine control | Issue commands, change logic, or alter the physical process. | Owned by the engineered control and safety systems and the site’s operating procedures. | Orenda is not the PLC, safety system, or customer approval workflow. |
A service request may arrive without the alarm history, operating state, or configuration details needed for triage.
Every customer has its own network rules, approval process, safety responsibilities, and maintenance windows.
Different VPNs, credentials, contacts, and handover notes make the installed base difficult to support consistently.
Start with one defined support scenario and one machine. Validate the customer boundary, hardware, power, network, protocols, data points, applications, roles, and handover evidence. When the operating method is accepted, use that checklist—not an assumed universal template—for the next suitable installation.
A useful pilot has a narrow job, named owners, and evidence that the customer can operate the service path safely.
Include the agreed resource scope, local installation, user onboarding, and service handover in the delivery plan.
Review configured alarms, counters, history, and service views before choosing the next diagnostic step.
Support appropriate commissioning tasks when local personnel, safety procedures, test plans, and change control allow.
Add a service path only after validating cabinet, power, network, protocol, data, application, and ownership requirements.
Give service engineers an agreed starting point and the configured machine context available at that installation.
Document resources, roles, limits, contacts, and local responsibilities before remote service starts.
Use consistent readiness and handover checks while preserving each customer’s network and operating authority.
Remote access is one part of an OEM service process. Scope it with the customer and validate every installation rather than treating connectivity as permission or assuming every machine is compatible.
It is an operating model that combines a machine-side data and application layer, authorized access to selected resources, and a documented customer service process. It can support monitoring and diagnosis while the customer retains approval, safety, and control responsibilities.
Orenda provides access to configured resources; it is not the PLC or safety system. Whether a connected application permits a command is governed by that application, the engineered control system, user permissions, and the customer’s operating and change-control procedures.
Orenda can provide a resource-specific path for selected support workflows, so a user does not need broad plant-network access for every task. It does not replace the customer’s request, approval, maintenance-window, or change-control process, and network requirements still need site review.
Check cabinet space, power, environmental conditions, customer network policy, supported protocols, required data points, local applications, resource ownership, user roles, safety procedures, recovery steps, and handover evidence before deployment.
Named organization users can open assigned resources through Orenda Connect. A target-scoped vendor link can be revoked and may have an optional expiry, but it is a bearer credential and should be handled under the customer’s own sharing and approval rules.
No. Better access to configured evidence may help a team triage an issue, but resolution, downtime, travel, and service results depend on the fault, machine design, available data, local personnel, spares, procedures, and customer decisions.
Tell us what machine you build, what the customer permits, which resources and data the service team needs, and which diagnostic workflow should be tested first.
Plan a machine builder pilot