Manufacturing and cloud compute

Over the past decade, cloud computing has gone from being a promising novelty to a staple good in most industries. Many large organizations, manufacturing included, have made significant progress in shifting meaningful workloads to the cloud, and learned how to calculate the full lifecycle cost of on-premise versus cloud-based software solutions. This shift has mainly been driven by traditional productivity software suites, such as Office 365 and Google Workspace, but is increasingly also driven by running mission critical workloads in the cloud directly.

In manufacturing, however, there is still a lot of opportunity left on the table to unlock the inherent scalability and flexibility cloud-based solutions offer. Both on the shop floor, and within engineering functions. CAD, CAM and most CAE software still run primarily as offline, desktop-based solutions that require significant workstation compute capability to run smoothly. These workstations are very expensive to purchase, and are typically only offered to a handful of individuals at the company. Making matters worse, most existing engineering software offers limited, if any, ability to parallelize compute to help speed up work. This makes investments in powerful desktop workstations less impactful than they could be, even as these solutions remain firmly offline and in single player mode.

When we first started building Encube, we realized that the only way to achieve the scale and speed of compute necessary to make real manufacturing simulation a core part of the product design cycle, would be to make all compute fully distributed. Not just multi-threaded, but truly distributed, with exponentially shorter compute times achieved through horizontal cloud scaling. And at the same time also leverage GPU compute, which is far more suited to linear algebra and 3D graphics related workloads, compared to the CPU.

However, because of the inherent complexity of building distributed compute architectures, very few engineering software companies have actively pursued this approach. Similarly, shifting workloads from CPU to GPU typically requires a fundamental rewrite of critical parts of the tech stack. Most engineering software companies, as a result, have continued to invest their R&D resources in improving the codebase already in place, rather than tapping into the potential distributed compute architectures hold.

We believe that truly scalable engineering compute unlocks a number of highly impactful use cases, including real time collaboration, that will come to define the next generation of engineering software. Many of which are likely to still be discovered.

Human responsiveness to speed of compute

Today, the importance of speed of compute in human-computer interaction is both well-researched and established. But, already back in 1968, Robert Miller of IBM published “Response time in man-computer conversational transactions,” where he described three distinct orders of magnitude for how responsive a user perceives an application to be:

1. A response time of 100 milliseconds or less is perceived as instantaneous
2. Response times of less than 1 second or less are perceived as fast enough for users to feel that they are freely interacting with an application
3. Response times greater than 10 seconds completely lose the user’s attention

Subsequent research has shown that these magnitudes are not written in stone, and depend on context, such as whether we are discussing competitive gaming, live entertainment, auctioning or collaboration in online settings. Nevertheless, the magnitudes defined by Miller work well to help establish why speed of compute is essential for many types of use cases. Including engineering and manufacturing.

Speed of compute in CNC machining

If we consider the case of CNC machining, the market vertical we’re diving deep into at Encube, the only meaningful way to understand manufacturability of a component is to understand what it will cost to produce. And the only way to do this reliably, is to simulate the machining process itself. Crude measures like calculating the amount of material to be removed and dividing by a constant material removal rate (which is the current standard practice) are insufficient to generate an accurate best practice cost estimate.

To produce a viable cost estimate, we need to understand what a competitive set of toolpaths will look like for a given component. There are a number of highly complex geometric computing tasks involved in generating a functional toolpath program from start to finish, including calculating accessibility of surfaces, identifying possible fixturing strategies, orchestrating possible component orientations, generating and orienting stock geometry, as well as generating representations of material removal between machining operations. And these are not exhaustive.

A significant portion of these forms of geometric compute can be designed to run in parallel, but are nevertheless implemented to run sequentially in existing software and without meaningfully leveraging GPU, let alone out-of-core architectures. As a consequence, the time between a user performing an action and being able to interact with the result of a compute, becomes directly prohibitive to collaborative use cases.

In other words, near instant compute is a fundamental requirement to unlock a truly collaborative and agile feedback loop between design intent and understanding production cost drivers. The entire value proposition quickly falls apart if it takes more than a couple of seconds, let alone minutes or hours, to generate the context team members are in need of to drive a product development process forward.

An end to end toolpath benchmark

To understand just how fundamentally different Encube’s compute approach is, and the opportunities it unlocks in terms of novel use cases, we decided to create a benchmark that follows the geometric compute necessary to produce a functional end-to-end toolpath program to produce a CNC machined part.

The target part programmed in the benchmark can be found in figure 1. The benchmark itself was produced using two sets of hardware, with all time consumed from manual input required in a desktop-based CADCAM software, stripped out in order to contain the benchmark to actual compute times (the time spent on manual input averaged well above 30 minutes across our tests for roughing programming alone).

The first setup consisted of CADCAM software Autodesk Fusion 360 (RC 2023, V.2.0.15299), running on an Intel Core i9 13900K with 16 cores and 32 threads, 32 GB DDR4 RAM, and an NVIDIA Quadro P2200 OEM GPU. This would be considered a top of the line desktop setup for CADCAM use at the time of writing.

The second hardware setup uses Encube’s elastic and distributed data center architecture to perform the necessary geometric compute to generate a toolpath program from start to finish. The benchmarks can be found in figure 2.

When compute resources are restricted, neither Encube, nor the traditional paradigm, performs well in our benchmark. With access to only a single CPU, the time it takes to compute a toolpath program from start to finish, including roughing and finishing toolpaths, in-process stock updates, setup orchestration, cutting tool choices and calculating optimal feeds and speeds, is significant and outright prohibitive to real-time use cases, such as collaboration. Both for Encube and existing CADCAM software offerings. As access to compute resources grows, Encube’s distributed approach rapidly reduces the amount of time users need to wait to interact with results.

CADCAM software, by comparison, is capped at 32 threads, as going beyond 16 cores would require an Intel Xeon CPU or equivalent. These processors are commonly found in data centers, but retail well north of 10 KUSD, which makes them prohibitively expensive individual desktop workstations running CADCAM applications.

The collaborative threshold

In our internal work with customers, ranging in size from small enterprises to global multinationals, we continuously find two insights that seem to hold true at scale:

1. Users expect their computers to remain responsive, even as heavy compute might be consuming most of their computers’ resources - especially less technical users
2. Users lose focus when it takes more than 10 seconds from taking an action to receiving feedback - especially in collaborative contexts

At Encube, we call this the collaborative threshold. We think of it as the time frame from when a user takes an action that requires a re-computation, until the results are available for interaction and analysis – under the condition that the application remains fully responsive and interactive while the compute runs. See figure 3 below for where the collaborative threshold sits compared to the benchmarks.

If either of these two conditions fail, the collaborative context falls apart, and users fall back on the manual ways they used to rely on to get the job done. The implication for engineering software is that it isn’t enough to introduce collaborative feature sets. The actual engineering compute must be radically accelerated to fit within the shorter time frame that real-time collaboration demands. You solve for both, or you are left with neither.

The future of engineering work

Time is a finite resource, and heavily undervalued by most organizations. Time well spent acts as a compounding factor on knowledge generation: the more we can do with every unit of time available today, the bigger the impact our efforts will have tomorrow. Wasting time is expensive.

Speed of compute empowers hardware engineers to explore a far larger opportunity set within a given time frame. Either by being able to pursue any one individual idea much farther than previously possible. Or, by exploring many more competing ideas upfront.

This is the true value of the speed of compute for engineering and manufacturing. It simultaneously acts as a lever on productivity growth, cuts time to market by shortening the feedback loop between idea and result, and reduces the cost of experimentation. And this, in turn, fuels and accelerates innovation overall.