Modernising a factory floor is generally taken to mean replacing equipment, which is why the subject usually arrives attached to a capital budget and a shutdown plan. However, there are also other routes to modernisation that require neither.

Upgrading a site can mean improving the quality of the production data it collects and the analysis it can run on it, through better monitoring, better record-keeping and better access to both, none of which requires the machinery itself to change.

One way of achieving this is through cloud control; the existing machinery remains in place and continues running the line, while a copy of the data it produces is sent out to servers outside the plant, where it can be held for years and examined in ways a local system has neither the storage nor the processing power to manage.

What improves through this process is the site's view of its own operation, which moves from machines holding a few weeks of records to a central picture of everything that has run through the plant. That brings modernisation within reach of sites that cannot justify a replacement programme, financially or operationally, and of equipment with years of service still left in it.

Below we will be examining what a cloud platform does on an industrial site, what stays on the plant floor, and the route data takes from a controller installed decades ago to a platform built long after it.

What is cloud computing in manufacturing?

The term cloud computing usually refers to a service that stores files on remote servers and makes them accessible from any location or device.

In manufacturing, however, the definition is a little more complex than that. It covers the collection of production data from plant systems and the holding of it centrally, on servers run by a provider, where it can be stored for years, viewed across several sites at once and analysed without the site buying hardware to do it. It also covers the analysis that comes after the data has been received, and the actions the plant takes based on that analysis.

Records from every machine are held together and processed as one set, so the plant can be examined as a whole instead of one machine at a time. Handling that locally would mean buying and maintaining servers with enough capacity to hold years of production history, and enough processing power to work through it, which is a substantial outlay for a capability that is not needed continuously.

Adding visibility with a cloud platform

Once plant data is reaching a cloud platform, a site gains a view of its production that local systems cannot provide on their own.

Production history kept for years

Local systems hold a limited window of data and overwrite the oldest records as the storage fills, which limits how much history a site can keep. A cloud platform keeps the full record, so performance can be benchmarked against any chosen period and any logged instance remains available to investigate.

Performance compared across the operation

Output, downtime and reject rates can be set side by side across lines running the same product, and across the shifts and sites running the same process. Existing differences in performance become measurable, and the question of why one line runs better than another becomes answerable.

Patterns visible across the whole plant

Some patterns only appear once the plant is examined as one operation, including faults that recur across machines of the same type and losses that follow a particular shift pattern or time of year. No individual machine holds enough of the record to reveal any of it, which is why these go unnoticed on sites where each system keeps its own data.

Plant data reaching other systems

Production figures can feed planning, maintenance and reporting systems directly, without requiring manual exports and imports from one system to the other. The delay between a change in output or a fault occurring on the floor and that change becoming noticeable disappears, and so do any errors carried in by transferring records by hand.

Access away from the machine

The data becomes available to everyone, including engineers covering several areas at once, managers reporting on the site, and anyone supporting the plant from another location. Access no longer depends on physical proximity to the machine, which is what limited it on local systems.

Why the control layer stays where it is

The control layer is the part of a plant that issues instructions to the machinery and acts on what the machinery sends back, and it is the one part of the operation that does not move to the cloud.

It stays because the decisions it makes run on timings measured in milliseconds, and sending data to a distant server and waiting for a reply, while still fast in theory, takes longer than that. Granted, the delay itself is small, though the greater problem is that it varies, and a machine expecting an instruction within a fixed window cannot work with a figure that moves.

Equally, availability is another very important consideration; external connections go down periodically, through network faults, provider outages and maintenance at either end, and production cannot be left waiting while one is restored, so anything the line depends on has to keep running whether the link is up or down. Safety functions stay on the plant for the same reason, given that a safety circuit has to work at the moment it is called upon and cannot be left dependent on a service outside the building.

This is also where the term 'cloud control' becomes slightly misleading, because it implies more authority than the platform actually has. Control of the line stays where it has always been, on the machinery and the controllers running it, while the cloud only reads what those systems report.

How data gets from an old controller to the cloud

The data route

Data reaches a cloud platform from an existing controller through a gateway, which is a device that reads values from the PLC and passes them upward. It connects to the controller through whatever port the unit provides, requests the values held in the controller's memory at a set interval, and timestamps each reading as it collects it.

From there, the gateway sends the readings out over the site network and its internet connection, into the platform where they are stored. The connection is normally configured to run outward only, with the gateway pushing data to the platform and nothing reaching back down into the controller. Readings are held locally if the link goes down and sent on once it is restored.

The control programme is not rewritten and the controller is not reconfigured at any stage, so the machine carries on doing exactly what it was doing before the gateway was fitted.

How older equipment complicates the build

Older equipment makes that route harder to build in three ways:

• Controllers of a certain age were designed for serial connections and have no ethernet port, which means there is nothing on the unit for a gateway to plug into directly.
• Many older units communicate in manufacturer-specific formats developed long before the systems now asking for their data, so a protocol converter is needed to read the older format and present it in one the gateway can work with.
• A controller specified only for the job it was given has little processing headroom for answering requests it was never expected to receive, which limits how often it can be asked to report without affecting what it is there to do.

However, none of these constraints rules any piece of equipment out, regardless of its age. What changes is the configuration, since what sits between the controller and the platform depends on what the controller can already do.

A gateway with serial ports connects directly to controllers that have no ethernet of their own, and most will translate the older format as part of the same job, with a separate protocol converter used where the format is beyond what the gateway can read. Where the controller has little capacity to spare, it can be read less often or set to report only when a value changes, which keeps the extra load within what the unit can handle.

The route is longer on older equipment and takes more hardware to complete, though it ends in the same place, with the data reaching the platform and the machine running exactly as it was.

Modernising without replacing

Modernising an operation and replacing its equipment are two different decisions for a site running older machinery, because the control layer is untouched throughout.

Adding a cloud platform changes the visibility a site has over its operation while the machinery itself keeps running as it always has. The work can therefore be done gradually, starting with the lines where better visibility would make the most difference, and once that first stage has proved itself, it can be extended outward.

Industry benefits from this more than most sectors, given how long production equipment stays in service. Machinery bought on a years-long horizon is routinely still running past the point at which it was expected to be replaced, held onto because it works and because replacement means requalifying a process currently producing acceptable parts.

A modernisation route that left all of that equipment out would exclude most of what can be found on a factory floor. Building on top of it instead is what makes the platform available to sites that would otherwise have no route to one.

Cloud connectivity and legacy PLCs

Modernising the factory floor through a cloud platform commits a site to keeping its existing machinery running, since that equipment is not being retired but relied on more heavily than before.

However, older equipment like controllers, drives and modules from earlier generations may frequently be out of production, so availability of replacements becomes the factor that determines how long a machine stays in service, and with it how long the visibility the cloud platform provides can be maintained.

If your modernisation budget is directed toward setting up the cloud rather than toward getting new equipment, it is industrial replacement parts that will keep the machinery underneath the operation running for as long as possible.

Browse our full range of products to find what you need, including parts that are no longer in production, or get in touch, and we will source it for you.

FAQs

What is cloud computing in manufacturing?

It is the collection of production data from plant systems and the holding of it centrally, on servers run by a provider. The site can store, view and analyse that data without buying or maintaining the hardware to do it.

Is cloud control the same as SCADA?

No. SCADA supervises and controls a process in real time from systems on the plant, while a cloud platform sits above that layer, holding and analysing the data without any authority over the line.

What is the difference between edge and cloud computing in a factory?

Edge computing processes data on or beside the machine, so results are immediate and independent of any external connection. Cloud computing holds the data centrally, which suits long histories and comparison across lines or sites.

Can an older PLC connect to a cloud platform?

Yes, through a gateway that reads from it without any change to the control programme. Where the controller has no ethernet port, a protocol converter handles the translation.

Does production stop if the internet connection drops?

No, because control stays on the plant and does not depend on the link. The gateway holds the data it has collected and sends it once the connection is restored.