SaaS Cloud Platform & Deployment

SMEs and fast rollouts: shared SaaS. Enterprises with strict security policies or deep PLC/VPN integration: dedicated single-tenant or on-premise. We advise during the PoC.

On European cloud infrastructure, with dedicated-environment and region options on request.

Yes. Start shared for speed, then migrate to dedicated or on-premise as you scale. The platform is identical.

In a cloud deployment the on-site collector keeps reading the machines and buffers counts and stop records locally, then replays them when the link returns; how long it holds depends on the deployment and is sized during the PoC. Anything served from the platform stops at once: dashboards, new order release, reporting screens. Anything an operator has to type goes to paper until the link is back, so agree a fallback for stop reasons and scrap before go-live. Pull the cable during the PoC.

No. A collector inside the plant network reads the controllers and opens the connection outbound over TLS or a site-to-site VPN, so no firewall port is opened towards the plant. Be clear about what that collector may do, though: it is a trusted bridge, and whatever the platform can ask it to write back is an inbound path by another name. Segmenting the control layer is your own network design, so have your team review destinations, ports and write permissions before the PoC.

You own the servers, the operating systems, the container platform, the database, backups and their restore tests, certificates and their renewal, monitoring and the update windows. That means a named person with Linux and container experience who owns the job, instead of a responsibility spread across a busy team. It is more than most buyers budget for, and if nobody in the building fits that description, on-premise is the wrong choice for you.

They mean the platform is not taken offline for a release. Some interruptions can still happen. During a rolling release a screen may reload and, depending on how the terminal is logged in, may ask for a re-login, and unsaved entries in an open form can be lost. A schema migration, or a version that changes how something is reported, can still need a planned window. Agree who is told before a release and how you roll back.

Hardware and network decided first: servers sized for the modules you are buying, GPU capacity if you are taking vision or AI, a VLAN for the control layer, firewall rules between it and the application, DNS entries, certificates, and a backup target with someone accountable for restore tests. Add named admin accounts and an agreed maintenance window. Missing pieces here delay a go-live far more often than the software does.

The platform we operate, and hosted deployments only; on-premise availability is yours. Your site link, your firewall, the on-site collector and the machines themselves sit outside it, and in practice they cause most of what a plant experiences as an outage. Ask how availability is measured, what counts as planned maintenance, over what window the figure is calculated and what the remedy is when it is missed, and get those definitions into the contract.

Yes. Shop-floor systems record who logged in at which workstation and how long an operation took, so the platform can be operated lawfully but your deployment is not compliant on its own. You need a processing agreement, a retention period, and a decision on who may see individual rather than aggregated performance. Ask whether individual-level reporting can be restricted by role or switched off, and involve your legal or HR side early, since employee representatives are often consulted before go-live.